From owner-sip-outgoing@lists.research.bell-labs.com Sat Apr 1 05:48:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08141 for ; Sat, 1 Apr 2000 05:48:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 66C7B52B6; Sat, 1 Apr 2000 05:45:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CEC3D52D4; Sat, 1 Apr 2000 05:45:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4667552B6 for ; Sat, 1 Apr 2000 05:45:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Apr 1 05:44:47 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Sat Apr 1 05:44:47 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA27490; Sat, 1 Apr 2000 05:44:41 -0500 (EST) Message-ID: <38E5D319.4901B333@cs.columbia.edu> Date: Sat, 01 Apr 2000 05:44:41 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Wisdom Cc: SIP Mailing List Subject: Re: Availability of RFC2543bis in ASCII References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Mark Wisdom wrote: > > RFC2543bis is available in PDF and PostScript formats, i.e.: > > But I can't find a plain ASCII version anywhere. If an ASCII version > exists, can someone please tell us where we can find it (some of you > have been referring to sip_2543bis_00.txt). If not, can one please be > made available. I like having an ASCII version for quick grep-style > scanning of information. Since conversion of a document of that size takes some of (my) time, it will happen when it is submitted as an Internet draft in a week or two. Your patience is appreciated. > > Thanks, > Mark -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Sun Apr 2 11:36:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24944 for ; Sun, 2 Apr 2000 11:36:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DA6BB52C8; Sun, 2 Apr 2000 11:33:22 -0400 (EDT) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4DCA652D5; Sun, 2 Apr 2000 11:33:22 -0400 (EDT) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B34D152C8 for ; Sun, 2 Apr 2000 11:33:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Apr 2 11:32:33 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Sun Apr 2 11:32:32 EDT 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA14989; Sun, 2 Apr 2000 11:29:06 -0400 (EDT) Message-ID: <38E76742.6BDF3605@cs.columbia.edu> Date: Sun, 02 Apr 2000 11:29:06 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Donovan, Steven R." , "'Anders Kristensen'" , SIP Subject: Re: Session timer comments References: <75C79E507864D3118AFC00805FEAB7D83493A2@ripexch001.mcit.com> <38E15DC6.17EAFEB8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > This is addressed by an addition to 2543bis: > > > > "Note that proxy servers have to add Record-Route headers to each > > request as long as they want to be "visited" by the next request > > for the call leg." > > > > The only way for a proxy to insure that it will be a part of all requests is > > to insert the Record-Route header into all requests, even those that have a > > Route header. > > I think this may cause interop problems. Much as I'd like to add this, > it means any old proxy that doesn't insert REcord-Route is going to get > booted off the signaling path. That seems like a problem. Is this a practical problem? How many proxy servers that implement Route/Record-Route couldn't be trained to do that? Also, I believe this has been discussed since the first bake-off or thereabouts, so most implementors should have seen this. > > Beyond that, the other problem with re-establishing the session at the > crashed and rebooted UA is the CSeq space. It will loose track of the > CSeq number it had been using in the other direction. Thus, any messages > it sends may be rejected by the UA on the other side as being out of > order. This, too, can be fixed if you are careful about choosing CSeq > numbers. The spec recommends, I believe, choosing them based on a local > clock. This would actually mean that a UA that crashes and reboots would > still be able to send requests with the right CSeq. > > However, a more interesting problem is the following. Lets say A and B > are talking, and B crashes and reboots. Now, A sends a re-invite to B. B > rejects the re-INVITE, which it believes is an initial INVITE, and thus > it thinks there is no call. A thinks the rejection is for a re-INVITE, > and thus still believes the call is up. Session timer is meant to deal > with exactly these kinds of things, and it would detect this condition. > But, any other ideas on possible solutions outside of session timer? > > Stepping back a moment, this problem is rooted in the simple fact that > we use INVITE for both initiation and modification. That will work, I > believe, if the rules for handling and responding to INVITE are > absolutely, positively no different if you are in, or not in a call. As > soon as the behavior is different because its a re-INVITE, thats where > oddball problems like this come up. For example, if the response to a > re-INVITE is always 200 OK so long as the session is still up, and a > response of 400 means the session is not active (as it is for a normal > INVITE), this crash and reboot problem above will not happen. One solution is to define a status code in 4xx (or maybe 3xx) that says "modification failed, call remains". I suppose other 4xx conditions could suddenly arise (for example, I somehow turn on authentication in mid-call), but these seem somewhat unlikely. I'm curious how RSVP deals with this, since it also has the problem that state may be modified during a reservation. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Sun Apr 2 18:49:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27222 for ; Sun, 2 Apr 2000 18:49:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5886C52DC; Sun, 2 Apr 2000 18:47:10 -0400 (EDT) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4E0CD52DD; Sun, 2 Apr 2000 18:47:09 -0400 (EDT) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from starling.research.bell-labs.com (starling.research.bell-labs.com [135.104.26.187]) by lists.research.bell-labs.com (Postfix) with ESMTP id AF41852DC for ; Sun, 2 Apr 2000 18:46:36 -0400 (EDT) Received: (from tal@localhost) by starling.research.bell-labs.com (8.9.1/8.9.1) id SAA12879; Sun, 2 Apr 2000 18:46:36 -0400 (EDT) Date: Sun, 2 Apr 2000 18:46:36 -0400 (EDT) From: Tom Limoncelli Message-Id: <200004022246.SAA12879@starling.research.bell-labs.com> To: sip@lists.research.bell-labs.com Subject: The sip list is moving! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The sip mailing list is moving to sip@lists.bell-labs.com. You should receive a message from the new mailing list server notifying you of this. If you don't (or haven't already), please send email to tal@research.bell-labs.com and tell me which list you had been on. The old address will continue to work for a while. There is no need to reply to this message if you get the notification. Your humble servant, Tom Limoncelli Listmaster tal@research.bell-labs.com From sip-admin@lists.bell-labs.com Mon Apr 3 09:28:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17047 for ; Mon, 3 Apr 2000 09:28:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 96E6944337; Mon, 3 Apr 2000 09:26:53 -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 98D6B44336 for ; Mon, 3 Apr 2000 09:26:51 -0400 (EDT) Received: by crash with Internet Mail Service (5.5.2448.0) id ; Mon, 3 Apr 2000 09:26:41 -0400 Message-ID: From: Linden deCarmo To: "'Henning Schulzrinne'" , Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Date: Mon, 3 Apr 2000 09:26:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [SIP] RE: [Fwd: Aurthorization & Proxy-Authorization URIs] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Any updates on your communication with the RFC 2617 authors regarding the use of qoutes with Authorization and Proxy-Authorization headers? Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Henning Schulzrinne [SMTP:hgs@cs.columbia.edu] > Sent: Friday, February 25, 2000 7:55 PM > To: Jonathan Rosenberg; sip@lists.research.bell-labs.com > Cc: john@math.nwu.edu > Subject: Re: [Fwd: Aurthorization & Proxy-Authorization URIs] > > > > Jonathan Rosenberg wrote: > > > > ?? I guess the quotes shouldn't be there according to the current BNF, > > but it might make parsing harder.? > > Since the digest authentication mechanism attempts to follow RFC 2617 > (obviously, 2617 postdates 2543, but it will be the normative reference > in the next round), request-uri is indeed defined without being a quoted > string, even though the uri is not a token. (Unless you put an unescaped > comma into the URI, there shouldn't be delineation problems. But we had > this discussion in another context, where it became clear that URIs can > indeed contain commas.) Some parsers allow all parameters to be either > tokens or quoted strings, since that's easiest and never wrong. > > Unfortunately, RFC 2617 itself is not consistent. In the BNF (3.2.2), > it's without quotes, in the example (Section 3.5), it shows up *with* > quotes. I guess we need to contact the RFC 2617 authors to find out what > people really do and what they intended. Another instance of URIs (in > WWW-Authenticate) is always with quotes. > > Thus, the confusion is more fundamental. > > > > > Subject: Aurthorization & Proxy-Authorization URIs > > Date: Mon, 21 Feb 2000 14:53:22 -0500 > > From: Linden deCarmo > > To: sip@lists.research.bell-labs.com > > > > The BNF for digest-uri defined by "HTTP Authentication: Basic and Digest > > Access Authentication" for use in Aurthorization & Proxy-Authorization > > headers is: > > > > digest-uri = "uri" "=" digest-uri-value > > digest-uri-value = request-uri ; As specified by HTTP/1.1 > > > > RFC2543, updates this definition to be: > > > > 2. The BNF for digest-uri-value is: > > > > digest-uri-value = Request-URI ; a defined in Section 4.3 > > > > Yet, all the sample call flows for the uri parameters for the > Aurthorization > > & Proxy-Authorization headers that I've seen (i.e. SIP Telephony Service > > Examples With Call Flows) > > enclose the uri parameter in quotes (i.e. a quoted string) just like the > > HTTP docs: > > > > uri="sip:xxx.yyyy.com" > > > > Syntacically, I can't see how this is possible. Am I wrong? If so, > could > > someone point out the relevant section that explains how this is > possible? > > > > Thank you. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 09: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 JAA17254 for ; Mon, 3 Apr 2000 09: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 C1DDB44338; Mon, 3 Apr 2000 09:50: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 F06D144336 for ; Mon, 3 Apr 2000 09:50:18 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA23345; Mon, 3 Apr 2000 09:51:34 -0400 (EDT) Message-ID: <38E8A1E6.2EFE7466@cs.columbia.edu> Date: Mon, 03 Apr 2000 09:51:34 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: "'Henning Schulzrinne'" , Jonathan Rosenberg , "'sip@lists.bell-labs.com'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [Fwd: Aurthorization & Proxy-Authorization URIs] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Linden deCarmo wrote: > > Any updates on your communication with the RFC 2617 authors regarding the > use of qoutes with Authorization and Proxy-Authorization headers? No response whatsoever. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > > Since the digest authentication mechanism attempts to follow RFC 2617 > > (obviously, 2617 postdates 2543, but it will be the normative reference > > in the next round), request-uri is indeed defined without being a quoted > > string, even though the uri is not a token. (Unless you put an unescaped > > comma into the URI, there shouldn't be delineation problems. But we had > > this discussion in another context, where it became clear that URIs can > > indeed contain commas.) Some parsers allow all parameters to be either > > tokens or quoted strings, since that's easiest and never wrong. > > > > Unfortunately, RFC 2617 itself is not consistent. In the BNF (3.2.2), > > it's without quotes, in the example (Section 3.5), it shows up *with* > > quotes. I guess we need to contact the RFC 2617 authors to find out what > > people really do and what they intended. Another instance of URIs (in > > WWW-Authenticate) is always with quotes. > > > > Thus, the confusion is more fundamental. > > > > > > > > Subject: Aurthorization & Proxy-Authorization URIs > > > Date: Mon, 21 Feb 2000 14:53:22 -0500 > > > From: Linden deCarmo > > > To: sip@lists.research.bell-labs.com > > > > > > The BNF for digest-uri defined by "HTTP Authentication: Basic and Digest > > > Access Authentication" for use in Aurthorization & Proxy-Authorization > > > headers is: > > > > > > digest-uri = "uri" "=" digest-uri-value > > > digest-uri-value = request-uri ; As specified by HTTP/1.1 > > > > > > RFC2543, updates this definition to be: > > > > > > 2. The BNF for digest-uri-value is: > > > > > > digest-uri-value = Request-URI ; a defined in Section 4.3 > > > > > > Yet, all the sample call flows for the uri parameters for the > > Aurthorization > > > & Proxy-Authorization headers that I've seen (i.e. SIP Telephony Service > > > Examples With Call Flows) > > > enclose the uri parameter in quotes (i.e. a quoted string) just like the > > > HTTP docs: > > > > > > uri="sip:xxx.yyyy.com" -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 09:56: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 JAA17289 for ; Mon, 3 Apr 2000 09:56: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 D64254433E; Mon, 3 Apr 2000 09:55:14 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E827744336 for ; Mon, 3 Apr 2000 05:14:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 05:14:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A45CC44345; Mon, 3 Apr 2000 05:01:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 724C244344 for ; Mon, 3 Apr 2000 05:01:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 31C5052D4; Mon, 3 Apr 2000 05:01:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5DE7152B6 for ; Mon, 3 Apr 2000 05:01:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 3 04:59:24 EDT 2000 Received: from punegate.mahindrabt.com ([203.197.95.162]) by dusty; Mon Apr 3 04:59:21 EDT 2000 Received: (from uucp@localhost) by punegate.mahindrabt.com (8.8.7/8.8.6) id OAA04730 for ; Mon, 3 Apr 2000 14:32:03 +0530 Received: from intranet.pune.mahindrabt.com(202.41.13.243) via SMTP by punegate.mahindrabt.com, id smtpda04681; Mon Apr 3 09:01:56 2000 Received: from mahindrabt.com ([10.4.1.4]) by intranet.pune.mahindrabt.com (8.9.3/8.9.3) with ESMTP id OAA21827 for ; Mon, 3 Apr 2000 14:35:26 +0530 Message-ID: <38E85EBC.4462D5C3@mahindrabt.com> Date: Mon, 03 Apr 2000 14:35:00 +0530 From: ajit kalele X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I want to subscribe to this mail list. Kindly send details. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 09:57: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 JAA17300 for ; Mon, 3 Apr 2000 09:57: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 DD0DB44349; Mon, 3 Apr 2000 09:55:17 -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 45A6D44336; Mon, 3 Apr 2000 05:41:26 -0400 (EDT) Received: from oleane (dyn-1-1-028.Vin.dialup.oleane.fr [195.25.4.28]) by smtp1.cluster.oleane.net with SMTP id KAA30648; Mon, 3 Apr 2000 10:41:52 +0200 (CEST) Message-ID: <003401bf9d50$4ccfe220$0401a8c0@oleane.com> From: "Peter Lewis" To: Date: Mon, 3 Apr 2000 11:37:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01BF9D61.0F33BA20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] SIP 2000 International Conference Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0031_01BF9D61.0F33BA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_0031_01BF9D61.0F33BA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
 
 
------=_NextPart_000_0031_01BF9D61.0F33BA20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 09:58: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 JAA17320 for ; Mon, 3 Apr 2000 09:58: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 DE1394434F; Mon, 3 Apr 2000 09:55:21 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 542B944337 for ; Mon, 3 Apr 2000 03:34:46 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 03:34:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B359F44345; Mon, 3 Apr 2000 03:21:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7F8C144341 for ; Mon, 3 Apr 2000 03:21:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 445DA52D4; Mon, 3 Apr 2000 03:21:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6523C52B6 for ; Mon, 3 Apr 2000 03:21:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 3 03:20:33 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Apr 3 03:20:32 EDT 2000 Received: from dynamicsoft.com (1Cust99.tnt1.freehold.nj.da.uu.net [63.17.113.99]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA25911; Mon, 3 Apr 2000 03:21:42 -0400 (EDT) Message-ID: <38E8481F.4A10F965@dynamicsoft.com> Date: Mon, 03 Apr 2000 03:28:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jimmy Zhang Cc: sip@lists.research.bell-labs.com References: <38E40F9F.3AC5F14F@ipunity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: help on SIP 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit SIP messages can contain any URI wherever a SIP URL can appear. WHilst its not forbidden to put an http URL or a URN in the to and from field (and things will still work, but it might not get routed too far), I'm not sure why you'd want to do that. We have generally discussed using tel URLs in these places, in addition to SIP URLs. I'm curious where you found these messages? -Jonathan R. jimmy Zhang wrote: > > Since I am pretty new to SIP, please forgive me for asking naive > questions, such as > the following one. > > In the specificiation, both "to" and "from" fields require the sip > address to be in > the form of either "sip:agb@bell-telephone.com" or "anonymous > ". > But I just collected some sample messages in which both "to" and > "from" headers were > in different looks, e.g. "to: isbn:2983792873" and "From: > http://www.cs.columbia.edu". Just > wondering if anyone could explain, in the case that they are both > valid, why http URL would > be allowed in the From or To headers? Also, aside from "isbn", what > are other possible > prefixes allowed? > > thanks, > > -- > > Jimmy zhang (jz@ipunity.com) > > Software Engineer > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 09: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 JAA17353 for ; Mon, 3 Apr 2000 09: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 0844644353; Mon, 3 Apr 2000 09:55:25 -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 927A744336 for ; Mon, 3 Apr 2000 03:54:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Apr 3 03:54:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0D26944344; Mon, 3 Apr 2000 03:41:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D7B2B44341 for ; Mon, 3 Apr 2000 03:41:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9386752D4; Mon, 3 Apr 2000 03:41:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A4EB752C8 for ; Mon, 3 Apr 2000 03:41:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 3 03:39:20 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Apr 3 03:39:20 EDT 2000 Received: from dynamicsoft.com (1Cust99.tnt1.freehold.nj.da.uu.net [63.17.113.99]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA25921; Mon, 3 Apr 2000 03:36:25 -0400 (EDT) Message-ID: <38E84B93.F59D20F1@dynamicsoft.com> Date: Mon, 03 Apr 2000 03:43:15 -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: "Donovan, Steven R." , "'Anders Kristensen'" , SIP References: <75C79E507864D3118AFC00805FEAB7D83493A2@ripexch001.mcit.com> <38E15DC6.17EAFEB8@dynamicsoft.com> <38E76742.6BDF3605@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Session timer 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > > The only way for a proxy to insure that it will be a part of all requests is > > > to insert the Record-Route header into all requests, even those that have a > > > Route header. > > > > I think this may cause interop problems. Much as I'd like to add this, > > it means any old proxy that doesn't insert REcord-Route is going to get > > booted off the signaling path. That seems like a problem. > > Is this a practical problem? How many proxy servers that implement > Route/Record-Route couldn't be trained to do that? Also, I believe this > has been discussed since the first bake-off or thereabouts, so most > implementors should have seen this. We can take a poll at the bakeoff, but I'm sure there are implementations that won't be there... > > Stepping back a moment, this problem is rooted in the simple fact that > > we use INVITE for both initiation and modification. That will work, I > > believe, if the rules for handling and responding to INVITE are > > absolutely, positively no different if you are in, or not in a call. As > > soon as the behavior is different because its a re-INVITE, thats where > > oddball problems like this come up. For example, if the response to a > > re-INVITE is always 200 OK so long as the session is still up, and a > > response of 400 means the session is not active (as it is for a normal > > INVITE), this crash and reboot problem above will not happen. > > One solution is to define a status code in 4xx (or maybe 3xx) that says > "modification failed, call remains". Actually, to be consistent with a regular INVITE, it would need to be a 2xx that says "modification failed, call remains", since a 200 OK to initial INVITE means the call is up. I'm not sure we want to do this, though. I think we are pretty far down the road of re-INVITE being different from INVITE. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 10:01: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 KAA17433 for ; Mon, 3 Apr 2000 10:01: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 5496E4435A; Mon, 3 Apr 2000 09:55:28 -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 17B6544337 for ; Mon, 3 Apr 2000 03:32:46 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 03:32:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7AFBD44344; Mon, 3 Apr 2000 03:19:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 534FC44341 for ; Mon, 3 Apr 2000 03:19:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0D67C52D4; Mon, 3 Apr 2000 03:19:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2ECAC52B6 for ; Mon, 3 Apr 2000 03:19:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 3 03:17:08 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Apr 3 03:17:07 EDT 2000 Received: from dynamicsoft.com (1Cust99.tnt1.freehold.nj.da.uu.net [63.17.113.99]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA25907; Mon, 3 Apr 2000 03:18:06 -0400 (EDT) Message-ID: <38E84748.F1B5D9C5@dynamicsoft.com> Date: Mon, 03 Apr 2000 03:24:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cliff.Harris@nokia.com Cc: sip@lists.research.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: SIP INFO: What is "mid-session"; sessions w/o media Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This issue isn't really specific to INFO. In general, the question is whether you can send a request immediately after sending an INVITE, and can the UAS send a request in the reverse direction after receiving the INVITE? We discussed this issue as it relates to BYE. I believe the issues here are similar. If the UAC waits for a provisional or final response, it will have both a Route and a tag, and can thus insure that the request gets to the right place. If the UAC sends a request out before waiting for that response with the tag and route, it might work, but it becomes dependent on the consistency of call processing logic at intermediate proxies. The issue is similar for the called party. If it sends the request before the caller gets a provisional or final response to the initial INVITE with a tag, the caller won't know from whom the new request is. So, its a good idea for the called party to wait for an ACK before sending a new request, but its not mandatory. Do you have a specific need for sending INFO right away? Remember, INFO cannot be used to modify session or call state. Regarding your second question, sure. No m lines in the SDP. -Jonathan R. Cliff.Harris@nokia.com wrote: > > 1. The draft on the INFO method says that the INFO method may be used > "mid-session"; exactly what that means is not clear to me. Does it mean that > the UAC may send an INFO right after sending an INVITE, and the UAS may send > an INFO right after receiving an INVITE? > > 2. Is it possible to create a session without a media stream, solely for the > purpose of sending one or more INFOs, and if so, is there a standard or > preferred way of doing so? > > Thanks, > > Cliff Harris -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Apr 3 10:54:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18185 for ; Mon, 3 Apr 2000 10:54: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 A83ED4433A; Mon, 3 Apr 2000 10:52:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E75E244336 for ; Mon, 3 Apr 2000 10:52:37 -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 KAA26450; Mon, 3 Apr 2000 10:54:46 -0400 (EDT) Message-ID: <38E8B250.B19D3348@dynamicsoft.com> Date: Mon, 03 Apr 2000 11:01:36 -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: Linden deCarmo , "'Henning Schulzrinne'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Re: [Fwd: Aurthorization & Proxy-Authorization URIs] References: <38E8A1E6.2EFE7466@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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Linden deCarmo wrote: > > > > Any updates on your communication with the RFC 2617 authors regarding the > > use of qoutes with Authorization and Proxy-Authorization headers? > > No response whatsoever. I suggest we take a poll at the next bakeoff and see what folks have implemented. If everyone is using quotes, we can go with that... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Apr 3 17:34:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25150 for ; Mon, 3 Apr 2000 17:34:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D72D44342; Mon, 3 Apr 2000 17:32:13 -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 2E17544336 for ; Mon, 3 Apr 2000 17:32:11 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id RAA06194; Mon, 3 Apr 2000 17:33:30 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: Cc: "Jonathan Rosenberg" Date: Mon, 3 Apr 2000 17:34:50 -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) In-Reply-To: <38E8B250.B19D3348@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: [SIP] questions on 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A simple question on the proxy behavior. How the proxy (or the UAC) gets the Request-URI for the INVITE message to be sent out? When the proxy server receives an INVITE, it consults the location server to decide where to proxy this request. Should the proxy server use the Request-URI (or part of it), or should it use the To header to query the location server to identify the next hop? If it uses the Rquest-URI, the host portion of the Request-URI should mostly be one of the host names on the proxy itself. If the proxy uses the To field, possibly the Request-URI has already been changed to be quite different from To. Then he To doesn't make sense here. Or should it be that the proxy first check againt the Request-URI to see if it knows the user. If not, resort to the "To" field? Should section 4.3 in bis be interpreted in this way? If there's a section in the bis that describes this issue, please give me a pointer. Thanks... li li _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 02:25:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21408 for ; Tue, 4 Apr 2000 02:25:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FFF844337; Tue, 4 Apr 2000 02:23:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 921BF44336 for ; Tue, 4 Apr 2000 02:23:20 -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 CAA28521; Tue, 4 Apr 2000 02:25:40 -0400 (EDT) Message-ID: <38E98C81.C060E131@dynamicsoft.com> Date: Tue, 04 Apr 2000 02:32:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Li Cc: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: questions on 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Li Li wrote: > > A simple question on the proxy behavior. How the proxy > (or the UAC) gets the Request-URI for the INVITE message > to be sent out? > When the proxy server receives an INVITE, it consults the > location server to decide where to proxy this request. > Should the proxy server use the Request-URI (or part of it), > or should it use the To header to query the location server to > identify the next hop? Yes, the request URI is what a proxy or redirect server should generally use in order to determine the next hop. If it uses the Rquest-URI, the host portion > of the Request-URI should mostly be one of the host names on > the proxy itself. Except for the case of a local proxy, in which case the host name in the request URI is not one of the host names of the proxy itself. In this case, a proxy should generally forward it to the address in the request URI. If the proxy uses the To field, possibly the > Request-URI has already been changed to be quite different from > To. Then he To doesn't make sense here. Or should it be that > the proxy first check againt the Request-URI to see if it knows the > user. If not, resort to the "To" field? A proxy will not generally need to look at the To field for general message routing. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 10:03: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 KAA03791 for ; Tue, 4 Apr 2000 10:03: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 3179444337; Tue, 4 Apr 2000 10:02:16 -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 0B32244336 for ; Tue, 4 Apr 2000 10:02:14 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id KAA26405; Tue, 4 Apr 2000 10:03:33 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Re: questions on rfc2543bis Date: Tue, 4 Apr 2000 10:04:53 -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) In-Reply-To: <38E98C81.C060E131@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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > A simple question on the proxy behavior. How the proxy > > (or the UAC) gets the Request-URI for the INVITE message > > to be sent out? > > When the proxy server receives an INVITE, it consults the > > location server to decide where to proxy this request. > > Should the proxy server use the Request-URI (or part of it), > > or should it use the To header to query the location server to > > identify the next hop? > > Yes, the request URI is what a proxy or redirect server should generally > use in order to determine the next hop. > > If it uses the Rquest-URI, the host portion > > of the Request-URI should mostly be one of the host names on > > the proxy itself. > > Except for the case of a local proxy, in which case the host name in the > request URI is not one of the host names of the proxy itself. In this > case, a proxy should generally forward it to the address in the request > URI. Say if the Request-URI is somebody@foo.com and foo.com is one of the host names of the receiving proxy itself. So the proxy now takes "somebody" to do the lookup, as the foo.com does not give any information about the destination the INVITE should be going, though in the To header is actually "somebody@BellCanada.com", which is the destination. But "somebody" is not unique without the host name and may not tell much about where he is. I missed something here? li li > > > If the proxy uses the To field, possibly the > > Request-URI has already been changed to be quite different from > > To. Then he To doesn't make sense here. Or should it be that > > the proxy first check againt the Request-URI to see if it knows the > > user. If not, resort to the "To" field? > > A proxy will not generally need to look at the To field for general > message routing. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Apr 4 12:47:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08558 for ; Tue, 4 Apr 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 2C67744339; Tue, 4 Apr 2000 12:45:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 407BB44336 for ; Tue, 4 Apr 2000 12:45: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 MAA29384; Tue, 4 Apr 2000 12:47:50 -0400 (EDT) Message-ID: <38EA1E54.A140F347@dynamicsoft.com> Date: Tue, 04 Apr 2000 12:54:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Li Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Re: questions on rfc2543bis 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Li Li wrote: > > > Except for the case of a local proxy, in which case the host name in the > > request URI is not one of the host names of the proxy itself. In this > > case, a proxy should generally forward it to the address in the request > > URI. > > Say if the Request-URI is somebody@foo.com and foo.com is one of the > host names of the receiving proxy itself. So the proxy now takes > "somebody" to do the lookup, as the foo.com does not give any information > about the destination the INVITE should be going, though in the To > header is actually "somebody@BellCanada.com", which is the destination. > But "somebody" is not unique without the host name and may not tell much > about where he is. I missed something here? As I said, the To field is not used by the proxy. BellCanada.com is not the domain of the proxy; it cannot know anything about this name space, and therefore is not in a position to know anything about somebody@bellcanada.com. The proxy uses the request URI. If you are saying that the problem is that "somebody@foo.com" is not unique within foo.com (in otherwords, there are two somebodys), you have mismanaged your own namespace. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 13:46: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 NAA10326 for ; Tue, 4 Apr 2000 13:46: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 C50044433A; Tue, 4 Apr 2000 13:45:25 -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 85C8144338 for ; Tue, 4 Apr 2000 13:45:23 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id NAA29074; Tue, 4 Apr 2000 13:46:48 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Re: questions on rfc2543bis Date: Tue, 4 Apr 2000 13:48:08 -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) In-Reply-To: <38EA1E54.A140F347@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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > As I said, the To field is not used by the proxy. BellCanada.com is not > the domain of the proxy; it cannot know anything about this name space, > and therefore is not in a position to know anything about > somebody@bellcanada.com. > > The proxy uses the request URI. If you are saying that the problem is > that "somebody@foo.com" is not unique within foo.com (in otherwords, > there are two somebodys), you have mismanaged your own namespace. Thanks for pointing/confirming about the unique name space. Then if there is a "somebody@mciworldcom.com" and a "somebody@bellcanada.com", the proxy server needs to configure two names as somebody1@foo.com and somebody2@foo.com to send the call to different called destinations? So the proxy server should not serve too many different destination domains as this would make the name management impossible to give them all different names in the proxy's domain. Is this right? li li > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 13:50: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 NAA10423 for ; Tue, 4 Apr 2000 13:50: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 40AB54434B; Tue, 4 Apr 2000 13:48:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 78C7E4434A for ; Tue, 4 Apr 2000 13:48:44 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B6A951E041 for ; Tue, 4 Apr 2000 13:50:11 -0400 (EDT) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA27974 for ; Tue, 4 Apr 2000 13:50:11 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id NAA56150 for sip@lists.bell-labs.com; Tue, 4 Apr 2000 13:48:44 -0400 (EDT) Date: Tue, 4 Apr 2000 13:48:44 -0400 (EDT) Message-Id: <200004041748.NAA56150@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] detection of retransmitted request at stateful 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: X-BeenThere: sip@lists.bell-labs.com This question is regarding section 12.3.4 of 2543 (and 2543bis). If the answer is in the mailing list archives, or the notes file, or the faq, I've missed it. If a forking proxy receives an INVITE request, and generates two INVITES from it, according to 12.4 the only difference between them is the branch=x in the via header (and probably the Request-URI too) If it happens that both of those forked requests are sent to the same stateful proxy as the next hop, how does that proxy know that the second isn't a retransmission? To, From (including tags), Call-ID, and CSeq are all identical. Adding a tag on the From header at the forking proxy would seem to be a bad idea, since then the response wouldn't match at the UAC. Also, there may already be a tag on the From header. Does this mean the stateful proxy needs to compare Via headers also, in determining whether the received request is a retransmission? Or, should it compare the Request-URI? Is there some other way it can tell that the second is a real request? Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 14:05:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10847 for ; Tue, 4 Apr 2000 14:05:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3216E44340; Tue, 4 Apr 2000 14:03:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72]) by lists.bell-labs.com (Postfix) with ESMTP id BFABB44338 for ; Tue, 4 Apr 2000 14:03:38 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA21733; Tue, 4 Apr 2000 14:05:01 -0400 (EDT) Message-ID: <38EA2ECD.1A7066D0@cisco.com> Date: Tue, 04 Apr 2000 14:05:01 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] detection of retransmitted request at stateful proxy References: <200004041748.NAA56150@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit William Marshall wrote: > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > If the answer is in the mailing list archives, or the notes file, > or the faq, I've missed it. > > If a forking proxy receives an INVITE request, and generates two > INVITES from it, according to 12.4 the only difference between them > is the branch=x in the via header (and probably the Request-URI too) > > If it happens that both of those forked requests are sent to the same > stateful proxy as the next hop, how does that proxy know that > the second isn't a retransmission? To, From (including tags), > Call-ID, and CSeq are all identical. > > Adding a tag on the From header at the forking proxy would seem to > be a bad idea, since then the response wouldn't match at the UAC. > Also, there may already be a tag on the From header. > > Does this mean the stateful proxy needs to compare Via headers > also, in determining whether the received request is a retransmission? > Or, should it compare the Request-URI? > Is there some other way it can tell that the second is a real request? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Bill, I think you are referring to the problem of request merging in a forking proxy - refer to Jonathan's page - he has a small article and possible solutions. -- 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 Tue Apr 4 14:35: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 OAA11781 for ; Tue, 4 Apr 2000 14:35: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 0A79444338; Tue, 4 Apr 2000 14:34:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1897B44336 for ; Tue, 4 Apr 2000 14:34: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 OAA29941; Tue, 4 Apr 2000 14:36:51 -0400 (EDT) Message-ID: <38EA37E0.56C92255@dynamicsoft.com> Date: Tue, 04 Apr 2000 14:43:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Li Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Re: questions on rfc2543bis 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Li Li wrote: > > > As I said, the To field is not used by the proxy. BellCanada.com is not > > the domain of the proxy; it cannot know anything about this name space, > > and therefore is not in a position to know anything about > > somebody@bellcanada.com. > > > > The proxy uses the request URI. If you are saying that the problem is > > that "somebody@foo.com" is not unique within foo.com (in otherwords, > > there are two somebodys), you have mismanaged your own namespace. > > Thanks for pointing/confirming about the unique name space. Then if > there is a "somebody@mciworldcom.com" and a "somebody@bellcanada.com", > the proxy server needs to configure two names as somebody1@foo.com and > somebody2@foo.com to send the call to different called destinations? You've lost me. If I call somebody@mciworldcom.com and somebody@bellcanada.com, those will go to two different proxies (or possibly the same proxy doing virtual hosting). If those map to different people, then the outgoing URIs will be different. > So > the proxy server should not serve too many different destination domains > as this would make the name management impossible to give them all different > names in the proxy's domain. Is this right? No, of course not. Why is this a problem? The proxy is serving many domains, as you say. To me, this means it handles requests for domain1.com, domain2.com, etc. You also seem to imply that these are mapped into a single namespace in the "proxy's domain". I don't follow that. If it receives a call for user1@domain1.com, it checks its tables for domain1.com, and finds that this is mapped to user_1@foo.com, and sends it out to foo.com. Not all incoming request get mapped to foo.com. For those that do, its up to foo.com to properly manage their namespace. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 14: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 OAA12429 for ; Tue, 4 Apr 2000 14: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 24B9A4433A; Tue, 4 Apr 2000 14:56:33 -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 4718E44336 for ; Mon, 3 Apr 2000 10:36:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 10:36:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C245244344; Mon, 3 Apr 2000 10:23:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 983AE44341 for ; Mon, 3 Apr 2000 10:23:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 59FEA52D4; Mon, 3 Apr 2000 10:23:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 68A3D52C8 for ; Mon, 3 Apr 2000 10:23:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 3 10:21:36 EDT 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Apr 3 10:21:34 EDT 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA14187; Mon, 3 Apr 2000 20:18:08 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568B6.004E95BD ; Mon, 3 Apr 2000 19:48:21 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: jimmy Zhang , sip@lists.research.bell-labs.com Message-ID: <652568B6.004E958E.00@sampark.hss.hns.com> Date: Mon, 3 Apr 2000 19:48:20 +0530 Subject: Re: [SIP] Re: help on SIP headers 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: X-BeenThere: sip@lists.bell-labs.com Its in the latest call-flows draft (Exp: Sep 2000) page 255 INVITE name:John_Smith SIP/2.0 ===> To: isbn:2983792873 ===> From: http://www.cs.columbia.edu Call-ID: 0ha0isndaksdj@10.1.2.3 CSeq: 8 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Contact: Joe Bob Briggs :-) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems jdr> I'm curious where you found these messages? jdr> -Jonathan R. Jonathan Rosenberg on 04/03/2000 12:58:31 PM To: jimmy Zhang cc: sip@lists.research.bell-labs.com Subject: [SIP] Re: help on SIP headers SIP messages can contain any URI wherever a SIP URL can appear. WHilst its not forbidden to put an http URL or a URN in the to and from field (and things will still work, but it might not get routed too far), I'm not sure why you'd want to do that. We have generally discussed using tel URLs in these places, in addition to SIP URLs. I'm curious where you found these messages? -Jonathan R. jimmy Zhang wrote: > > Since I am pretty new to SIP, please forgive me for asking naive > questions, such as > the following one. > > In the specificiation, both "to" and "from" fields require the sip > address to be in > the form of either "sip:agb@bell-telephone.com" or "anonymous > ". > But I just collected some sample messages in which both "to" and > "from" headers were > in different looks, e.g. "to: isbn:2983792873" and "From: > http://www.cs.columbia.edu". Just > wondering if anyone could explain, in the case that they are both > valid, why http URL would > be allowed in the From or To headers? Also, aside from "isbn", what > are other possible > prefixes allowed? > > thanks, > > -- > > Jimmy zhang (jz@ipunity.com) > > Software Engineer > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Apr 4 14:59: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 OAA12466 for ; Tue, 4 Apr 2000 14:59:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83A1E44357; Tue, 4 Apr 2000 14:57:19 -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 EA6C944338 for ; Mon, 3 Apr 2000 17:48:41 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 17:48:32 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C1C2244344; Mon, 3 Apr 2000 17:35:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0B74844341 for ; Mon, 3 Apr 2000 17:35:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 984C152D4; Mon, 3 Apr 2000 17:35:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 98B5152B6 for ; Mon, 3 Apr 2000 17:35:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 3 17:33:53 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Apr 3 17:33:52 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA27873; Mon, 3 Apr 2000 17:34:56 -0400 (EDT) Message-ID: <38E91018.1CA9FD8@dynamicsoft.com> Date: Mon, 03 Apr 2000 17:41:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: jimmy Zhang , sip@lists.research.bell-labs.com Subject: Re: [SIP] Re: help on SIP headers References: <652568B6.004E958E.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Right, I think I actually constructed this example. Its purpose is mainly to test parser and proxy robustness. A proxy which receives an INVITE with a request URI that has a scheme it doesn't understand, can't really route it, so it should probably send a 404. Having these funky URLs in Contact is much more likely. -Jonathan R. archow@hss.hns.com wrote: > > Its in the latest call-flows draft (Exp: Sep 2000) > page 255 > > > INVITE name:John_Smith SIP/2.0 > ===> To: isbn:2983792873 > ===> From: http://www.cs.columbia.edu > Call-ID: 0ha0isndaksdj@10.1.2.3 > CSeq: 8 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Contact: Joe Bob Briggs > > > :-) > Regds > Arjun > -- > Arjun Roychowdhury @ Hughes Software Systems > > jdr> I'm curious where you found these messages? > > jdr> -Jonathan R. > > Jonathan Rosenberg on 04/03/2000 12:58:31 PM > > To: jimmy Zhang > cc: sip@lists.research.bell-labs.com > > Subject: [SIP] Re: help on SIP headers > > SIP messages can contain any URI wherever a SIP URL can appear. WHilst > its not forbidden to put an http URL or a URN in the to and from field > (and things will still work, but it might not get routed too far), I'm > not sure why you'd want to do that. We have generally discussed using > tel URLs in these places, in addition to SIP URLs. > > I'm curious where you found these messages? > > -Jonathan R. > > jimmy Zhang wrote: > > > > Since I am pretty new to SIP, please forgive me for asking naive > > questions, such as > > the following one. > > > > In the specificiation, both "to" and "from" fields require the sip > > address to be in > > the form of either "sip:agb@bell-telephone.com" or "anonymous > > ". > > But I just collected some sample messages in which both "to" and > > "from" headers were > > in different looks, e.g. "to: isbn:2983792873" and "From: > > http://www.cs.columbia.edu". Just > > wondering if anyone could explain, in the case that they are both > > valid, why http URL would > > be allowed in the From or To headers? Also, aside from "isbn", what > > are other possible > > prefixes allowed? > > > > thanks, > > > > -- > > > > Jimmy zhang (jz@ipunity.com) > > > > Software Engineer > > > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > 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: (732) 741-4778 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 Apr 4 15:00: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 PAA12533 for ; Tue, 4 Apr 2000 15:00:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDAC84434F; Tue, 4 Apr 2000 14:57:23 -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 D566A44336 for ; Mon, 3 Apr 2000 12:42:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 3 12:42:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 14C7244344; Mon, 3 Apr 2000 12:29:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E07D844341 for ; Mon, 3 Apr 2000 12:29:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9D1E852D4; Mon, 3 Apr 2000 12:29:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B614352C8 for ; Mon, 3 Apr 2000 12:29:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 3 12:28:23 EDT 2000 Received: from bmailnj.iphighway.com ([63.89.157.130]) by dusty; Mon Apr 3 12:28:21 EDT 2000 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id <2DK7NBP3>; Mon, 3 Apr 2000 11:57:16 -0400 Message-ID: <6399122981E1D211AB490090271E0AA34C538A@BMAILNJ> From: Andrew Rawson - NJ To: Andrew Rawson - NJ Date: Mon, 3 Apr 2000 11:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9D85.45088C24" Subject: [SIP] Quality of Service & Policy-based Networking White Papers from IPHighway Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: 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_01BF9D85.45088C24 Content-Type: text/plain; charset="iso-8859-1" As voice, video, and data continue to converge, policy-based networking allows administrators to easily manage network traffic - dynamically prioritizing the delivery of time-critical and bandwidth-intensive traffic. IPHighway has just released a new series of white papers that highlight the promise of policy-based network management, and how it can improve Quality of Service (QoS) to better support next-generation, business-critical applications. The series includes 4 targeted documents, they offer a comprehensive overview of policy-based networking and its possibilities: * #1 - Introduction to Policy Based Networking & QoS (509KB) * #2 - Policy Standards & IETF Terminology (484KB) * #3 - Policy-based Networking Products, Design & Architecture (535KB) * #4 - IPHighway Target Markets & Case Studies (1,159KB) To receive any or all of these papers, simply respond to this message and indicate which one(s) you would like to receive. You may also visit our web site at http://www.iphighway.com/whitepapers.html and request them online. All requests will be fulfilled via email. Thanks, Andrew _____ If you do not want to receive any further email messages from IPHighway, simply reply with the subject REMOVE in the header. _____ Andrew Rawson Vice President Marketing & Business Development IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone 201-934-4265 Fax 201-934-4439 Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As voice, video, and data continue to converge, = policy-based=20 networking allows administrators to easily manage network traffic - = dynamically=20 prioritizing the delivery of time-critical and bandwidth-intensive=20 traffic.

IPHighway has just released a new series of white = papers that=20 highlight the promise of policy-based network management, and how it = can improve=20 Quality of Service (QoS) to better support next-generation, = business-critical=20 applications.

The series includes 4 targeted documents, they = offer a=20 comprehensive overview of policy-based networking and its=20 possibilities:
  • #1 - Introduction to Policy Based Networking & = = QoS           &nb= sp;        =20 (509KB)
  • #2 - Policy Standards & IETF=20 = Terminology          &= nbsp;           &= nbsp;           &= nbsp;     =20 (484KB)
  • #3 - Policy-based Networking Products, Design = &=20 Architecture     (535KB)
  • #4 - IPHighway Target Markets & Case=20 = Studies           = ;            = ;      =20 (1,159KB)
To receive any or all of these papers, simply = respond to this=20 message and indicate which one(s) you would like to receive. =
You may also visit our web site at http://www.iphighway.= com/whitepapers.html and=20 request them online.
All requests will be fulfilled via = email.
 
Thanks,
Andrew
 
If you do not want to receive any further email = messages from=20 IPHighway, simply reply with the subject REMOVE in the = header.
 
Andrew Rawson
Vice President
Marketing & Business Development
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone 201-934-4265 Fax 201-934-4439
Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 15: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 PAA12637 for ; Tue, 4 Apr 2000 15:01: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 6940644366; Tue, 4 Apr 2000 14:57:28 -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 BAA4044338 for ; Tue, 4 Apr 2000 13:20:35 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 4 13:20:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 180F344344; Tue, 4 Apr 2000 13:07:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E26AB44341 for ; Tue, 4 Apr 2000 13:07:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AB4B352BB; Tue, 4 Apr 2000 13:07:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DFEF952AB for ; Tue, 4 Apr 2000 13:07:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Apr 4 13:05:12 EDT 2000 Received: from bmailnj.iphighway.com ([63.89.157.130]) by dusty; Tue Apr 4 13:05:11 EDT 2000 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id <2DK7NBP3>; Mon, 3 Apr 2000 11:57:16 -0400 Message-ID: <6399122981E1D211AB490090271E0AA34C538A@BMAILNJ> From: Andrew Rawson - NJ To: Andrew Rawson - NJ Date: Mon, 3 Apr 2000 11:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9D85.45088C24" Subject: [SIP] Quality of Service & Policy-based Networking White Papers from IPHighway Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: 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_01BF9D85.45088C24 Content-Type: text/plain; charset="iso-8859-1" As voice, video, and data continue to converge, policy-based networking allows administrators to easily manage network traffic - dynamically prioritizing the delivery of time-critical and bandwidth-intensive traffic. IPHighway has just released a new series of white papers that highlight the promise of policy-based network management, and how it can improve Quality of Service (QoS) to better support next-generation, business-critical applications. The series includes 4 targeted documents, they offer a comprehensive overview of policy-based networking and its possibilities: * #1 - Introduction to Policy Based Networking & QoS (509KB) * #2 - Policy Standards & IETF Terminology (484KB) * #3 - Policy-based Networking Products, Design & Architecture (535KB) * #4 - IPHighway Target Markets & Case Studies (1,159KB) To receive any or all of these papers, simply respond to this message and indicate which one(s) you would like to receive. You may also visit our web site at http://www.iphighway.com/whitepapers.html and request them online. All requests will be fulfilled via email. Thanks, Andrew _____ If you do not want to receive any further email messages from IPHighway, simply reply with the subject REMOVE in the header. _____ Andrew Rawson Vice President Marketing & Business Development IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone 201-934-4265 Fax 201-934-4439 Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As voice, video, and data continue to converge, = policy-based=20 networking allows administrators to easily manage network traffic - = dynamically=20 prioritizing the delivery of time-critical and bandwidth-intensive=20 traffic.

IPHighway has just released a new series of white = papers that=20 highlight the promise of policy-based network management, and how it = can improve=20 Quality of Service (QoS) to better support next-generation, = business-critical=20 applications.

The series includes 4 targeted documents, they = offer a=20 comprehensive overview of policy-based networking and its=20 possibilities:
  • #1 - Introduction to Policy Based Networking & = = QoS           &nb= sp;        =20 (509KB)
  • #2 - Policy Standards & IETF=20 = Terminology          &= nbsp;           &= nbsp;           &= nbsp;     =20 (484KB)
  • #3 - Policy-based Networking Products, Design = &=20 Architecture     (535KB)
  • #4 - IPHighway Target Markets & Case=20 = Studies           = ;            = ;      =20 (1,159KB)
To receive any or all of these papers, simply = respond to this=20 message and indicate which one(s) you would like to receive. =
You may also visit our web site at http://www.iphighway.= com/whitepapers.html and=20 request them online.
All requests will be fulfilled via = email.
 
Thanks,
Andrew
 
If you do not want to receive any further email = messages from=20 IPHighway, simply reply with the subject REMOVE in the = header.
 
Andrew Rawson
Vice President
Marketing & Business Development
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone 201-934-4265 Fax 201-934-4439
Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 15: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 PAA13292 for ; Tue, 4 Apr 2000 15:22:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 46EEE443A1; Tue, 4 Apr 2000 15:07:01 -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 4B4A64439E for ; Tue, 4 Apr 2000 15:06:58 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id PAA19410; Tue, 4 Apr 2000 15:08:17 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Re: questions on rfc2543bis Date: Tue, 4 Apr 2000 15:09:37 -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) In-Reply-To: <38EA37E0.56C92255@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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > > Thanks for pointing/confirming about the unique name space. Then if > > there is a "somebody@mciworldcom.com" and a "somebody@bellcanada.com", > > the proxy server needs to configure two names as somebody1@foo.com and > > somebody2@foo.com to send the call to different called destinations? > > You've lost me. If I call somebody@mciworldcom.com and > somebody@bellcanada.com, those will go to two different proxies (or > possibly the same proxy doing virtual hosting). If those map to > different people, then the outgoing URIs will be different. I see the problem I have is thst from all the call flow examples in the call flow draft, the INVITE message always have user@proxydomain in the Request-URI and the Request-URI changes all the time from proxy to proxy. For example, if the INVITE goes through proxy ss1.mciworld.com and ss2.mciworld.com. The Request-URI in the INVITE message is shown as bigguy@ss1.mciworldcom.com and then changed to bigguy@ss2.mciworldcom.com. Should the caller UAC just send in Request-URI bigguy@mciworldcom.com to SS1 proxy. The SS1 does a look up and know that SS2 handles bigguy@mciworldcom.com and proxy it to SS2? Otherwise, as in the draft, it implies to me that everyone in the mciworld.com also should have a unique name in the ss1.mciworldcom.com so that SS1 can handle it. That leads me to think that when an INVITE is sent to a proxy, it should use the proxy's host name in the host part of the Request-URI. But as what you pointed out here, really the Request-URI should be the destination user@host and is sent to the proxy of the destination domain. Thanks for your help. Very much apprecaited. li li > > > So > > the proxy server should not serve too many different destination domains > > as this would make the name management impossible to give them > all different > > names in the proxy's domain. Is this right? > > No, of course not. Why is this a problem? The proxy is serving many > domains, as you say. To me, this means it handles requests for > domain1.com, domain2.com, etc. You also seem to imply that these are > mapped into a single namespace in the "proxy's domain". I don't follow > that. If it receives a call for user1@domain1.com, it checks its tables > for domain1.com, and finds that this is mapped to user_1@foo.com, and > sends it out to foo.com. Not all incoming request get mapped to foo.com. > For those that do, its up to foo.com to properly manage their namespace. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Apr 4 15:24: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 PAA13380 for ; Tue, 4 Apr 2000 15:24: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 C99A744359; Tue, 4 Apr 2000 15:20:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id C70DF44336 for ; Tue, 4 Apr 2000 15:20:43 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8C5C91E046 for ; Tue, 4 Apr 2000 15:22:11 -0400 (EDT) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA04576 for ; Tue, 4 Apr 2000 15:22:11 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id PAA63923 for sip@lists.bell-labs.com; Tue, 4 Apr 2000 15:21:30 -0400 (EDT) Date: Tue, 4 Apr 2000 15:21:30 -0400 (EDT) Message-Id: <200004041921.PAA63923@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] detection of retransmitted request at stateful 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: X-BeenThere: sip@lists.bell-labs.com > > Bill, I think you are referring to the problem of request merging in a > forking proxy - refer to Jonathan's page - he has a small article and > possible solutions. > > -- > Best regards, > Shail Found that article, but I think the problem I'm describing is a little different. Jonathan's diagram is: ---- /---| B |-\ / ---- \ ---- ---- / \ ---- ---- ---- | C1 |-----| A | -| D |-------| E |-----| C2 | ---- ---- \ / ---- ---- ---- \ ---- / \---| C |-/ ---- and the key item is that both forked requests are to go to C2. I would instead draw the diagram as: ---- ---- /---| B |-\ /--| C2 | / ---- \ / ---- ---- ---- / \ ---- / | C1 |-----| A | -| D | ---- ---- \ / ---- \ \ ---- / \ ---- \---| C |-/ \--| C3 | ---- ---- where the key item is that the two forked requests from A are intended to get to different endpoints; they just happen to cross at another proxy on the way. (Or, perhaps the translation done at A says the next proxy for both C2 and C3 is D; then we avoid B and C completely.) Jonathan's mechanisms to toss the secondary requests believing them to be duplicates isn't right for this case. I think the problem still is that proxy-D believes the second request it receives is a duplicate, even if the Request-URI for the first says C2 and the second says C3. Bill Marshall wtm@research.att.com -----original message----- Date: Tue, 04 Apr 2000 14:05:01 -0400 From: Shail Bhatnagar Subject: Re: [SIP] detection of retransmitted request at stateful proxy William Marshall wrote: > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > If the answer is in the mailing list archives, or the notes file, > or the faq, I've missed it. > > If a forking proxy receives an INVITE request, and generates two > INVITES from it, according to 12.4 the only difference between them > is the branch=x in the via header (and probably the Request-URI too) > > If it happens that both of those forked requests are sent to the same > stateful proxy as the next hop, how does that proxy know that > the second isn't a retransmission? To, From (including tags), > Call-ID, and CSeq are all identical. > > Adding a tag on the From header at the forking proxy would seem to > be a bad idea, since then the response wouldn't match at the UAC. > Also, there may already be a tag on the From header. > > Does this mean the stateful proxy needs to compare Via headers > also, in determining whether the received request is a retransmission? > Or, should it compare the Request-URI? > Is there some other way it can tell that the second is a real request? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Bill, I think you are referring to the problem of request merging in a forking proxy - refer to Jonathan's page - he has a small article and possible solutions. -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Apr 4 15:43: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 PAA13955 for ; Tue, 4 Apr 2000 15:43: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 57A9144337; Tue, 4 Apr 2000 15:41:46 -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 4EAC944336 for ; Tue, 4 Apr 2000 15:41:44 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FSI0043NC3UZ6@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 4 Apr 2000 19:43:06 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FSI00A01C3TA7@dgismtp02.wcomnet.com>; Tue, 04 Apr 2000 19:43:06 +0000 (GMT) Received: from omta3.mcit.com ([166.37.204.5]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FSI008JBC3S4N@dgismtp02.wcomnet.com>; Tue, 04 Apr 2000 19:43:05 +0000 (GMT) Received: from wcom.com ([166.33.132.111]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with ESMTP id <20000404194322.ZWWG6091@wcom.com>; Tue, 04 Apr 2000 19:43:22 +0000 Date: Tue, 04 Apr 2000 14:43:50 -0500 From: Alan Johnston Subject: Re: [SIP] Re: questions on rfc2543bis To: Li Li Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Message-id: <38EA45F6.59F31D2@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Li, I thought your question might have been based on the use of Request-URI in the Call Flows draft. I think the Request-URIs in the draft were formulated based on the (mistaken?) idea that the host portion of the Request-URI should map to the IP address of the proxy or server (the entity to which the request was sent). For example, in 3.1.2 on page 25 of draft-ietf-sip-call-flows-00.txt, message F4 has the INVITE Request-URI of UserB@ss1.wcom.com but the To header contains UserB@there.com where ss1.wcom.com is the Proxy Server. Should the Request-URI instead match the To header in this case? Alan Johnston MCI WorldCom Li Li wrote: > > > > > > > Thanks for pointing/confirming about the unique name space. Then if > > > there is a "somebody@mciworldcom.com" and a "somebody@bellcanada.com", > > > the proxy server needs to configure two names as somebody1@foo.com and > > > somebody2@foo.com to send the call to different called destinations? > > > > You've lost me. If I call somebody@mciworldcom.com and > > somebody@bellcanada.com, those will go to two different proxies (or > > possibly the same proxy doing virtual hosting). If those map to > > different people, then the outgoing URIs will be different. > > I see the problem I have is thst from all the call flow examples in the > call flow draft, the INVITE message always have user@proxydomain in the > Request-URI and the Request-URI changes all the time from proxy to proxy. > For example, if the INVITE goes through proxy ss1.mciworld.com and > ss2.mciworld.com. The Request-URI in the INVITE message is shown as > bigguy@ss1.mciworldcom.com and then changed to bigguy@ss2.mciworldcom.com. > Should the caller UAC just send in Request-URI bigguy@mciworldcom.com to > SS1 proxy. The SS1 does a look up and know that SS2 handles > bigguy@mciworldcom.com > and proxy it to SS2? Otherwise, as in the draft, it implies to me > that everyone in the mciworld.com also should have a unique name in the > ss1.mciworldcom.com so that SS1 can handle it. > That leads me to think that when an INVITE is sent to a proxy, it should use > the proxy's host name in the host part of the Request-URI. But as what you > pointed out here, really the Request-URI should be the destination > user@host > and is sent to the proxy of the destination domain. > Thanks for your help. Very much apprecaited. > > li li > > > > > > So > > > the proxy server should not serve too many different destination domains > > > as this would make the name management impossible to give them > > all different > > > names in the proxy's domain. Is this right? > > > > No, of course not. Why is this a problem? The proxy is serving many > > domains, as you say. To me, this means it handles requests for > > domain1.com, domain2.com, etc. You also seem to imply that these are > > mapped into a single namespace in the "proxy's domain". I don't follow > > that. If it receives a call for user1@domain1.com, it checks its tables > > for domain1.com, and finds that this is mapped to user_1@foo.com, and > > sends it out to foo.com. Not all incoming request get mapped to foo.com. > > For those that do, its up to foo.com to properly manage their namespace. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Apr 4 22:06: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 WAA22412 for ; Tue, 4 Apr 2000 22:06: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 9DB0044337; Tue, 4 Apr 2000 22:05:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by lists.bell-labs.com (Postfix) with ESMTP id 516FF44336 for ; Tue, 4 Apr 2000 22:05:02 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by valiant.cnchost.com id WAA06442; Tue, 4 Apr 2000 22:06:24 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: "Alan Johnston" Cc: "Jonathan Rosenberg" , Subject: RE: [SIP] Re: questions on rfc2543bis Date: Tue, 4 Apr 2000 22:07:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38EA45F6.59F31D2@wcom.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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > I thought your question might have been based on the use of > Request-URI in the > Call Flows draft. Yes. Alan, my misunderstanding was exactly resulted from there. > > I think the Request-URIs in the draft were formulated based on > the (mistaken?) > idea that the host portion of the Request-URI should map to the > IP address of > the proxy or server (the entity to which the request was sent). > > For example, in 3.1.2 on page 25 of > draft-ietf-sip-call-flows-00.txt, message F4 > has the INVITE Request-URI of UserB@ss1.wcom.com but the To > header contains > UserB@there.com where ss1.wcom.com is the Proxy Server. > > Should the Request-URI instead match the To header in this case? Always have the host portion of the Request-URI mapped to the IP address of the proxy or server may have a problem when there is a local proxy that handles many (or all) outgoing calls for a caller. Put Request-URI as UserB@wcom.com in this example may be better, my own take. Clearer to me. If proxy ss1 only handles calls to users in wcom.com, things may not be too bad if the INVITE message has Request-URI with ss1.wcom.com in the host portion. But say if the caller also wants to call somebody outside of wcom.com but should access through the wcom's ss1 proxy for all his services. If in this case the caller UAC gets all the destinations in the world mapped to a unique name@ss1.wcom.com in the Request-URI in the INVITE message, we'd have problems of too many mappings to handle for ss1.wcom.com. Of course, probably user A can send his different calls directly to different proxy servers of the destination carrier's network, which I don't know if it is the case. li li > > Alan Johnston > MCI WorldCom > > Li Li wrote: > > > > > > > > > > Thanks for pointing/confirming about the unique name space. Then if > > > > there is a "somebody@mciworldcom.com" and a > "somebody@bellcanada.com", > > > > the proxy server needs to configure two names as > somebody1@foo.com and > > > > somebody2@foo.com to send the call to different called destinations? > > > > > > You've lost me. If I call somebody@mciworldcom.com and > > > somebody@bellcanada.com, those will go to two different proxies (or > > > possibly the same proxy doing virtual hosting). If those map to > > > different people, then the outgoing URIs will be different. > > > > I see the problem I have is thst from all the call flow examples in the > > call flow draft, the INVITE message always have user@proxydomain in the > > Request-URI and the Request-URI changes all the time from proxy > to proxy. > > For example, if the INVITE goes through proxy ss1.mciworld.com and > > ss2.mciworld.com. The Request-URI in the INVITE message is shown as > > bigguy@ss1.mciworldcom.com and then changed to > bigguy@ss2.mciworldcom.com. > > Should the caller UAC just send in Request-URI bigguy@mciworldcom.com to > > SS1 proxy. The SS1 does a look up and know that SS2 handles > > bigguy@mciworldcom.com > > and proxy it to SS2? Otherwise, as in the draft, it implies to me > > that everyone in the mciworld.com also should have a unique name in the > > ss1.mciworldcom.com so that SS1 can handle it. > > That leads me to think that when an INVITE is sent to a proxy, > it should use > > the proxy's host name in the host part of the Request-URI. But > as what you > > pointed out here, really the Request-URI should be the destination > > user@host > > and is sent to the proxy of the destination domain. > > Thanks for your help. Very much apprecaited. > > > > li li > > > > > > > > > So > > > > the proxy server should not serve too many different > destination domains > > > > as this would make the name management impossible to give them > > > all different > > > > names in the proxy's domain. Is this right? > > > > > > No, of course not. Why is this a problem? The proxy is serving many > > > domains, as you say. To me, this means it handles requests for > > > domain1.com, domain2.com, etc. You also seem to imply that these are > > > mapped into a single namespace in the "proxy's domain". I don't follow > > > that. If it receives a call for user1@domain1.com, it checks > its tables > > > for domain1.com, and finds that this is mapped to user_1@foo.com, and > > > sends it out to foo.com. Not all incoming request get mapped > to foo.com. > > > For those that do, its up to foo.com to properly manage their > namespace. > > > > > > -Jonathan R. > > > > > > -- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/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 Apr 5 04:29:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07174 for ; Wed, 5 Apr 2000 04:29:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 482F144339; Wed, 5 Apr 2000 04:27: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 08FEF44336 for ; Wed, 5 Apr 2000 04:27:19 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FSJ00J36BK2U4@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Apr 2000 08:28:50 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00N01BK209@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 08:28:50 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00M20BK1C7@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 08:28:50 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id ; Wed, 05 Apr 2000 08:28:49 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 08:28:47 +0000 From: "Donovan, Steven R." Subject: RE: [SIP] Re: questions on rfc2543bis To: "'Li Li'" , "Johnston, Alan" Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D83493C7@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Li Li, Just to be clear, it is certainly legal for the request uri received at a proxy to contain a host portion that does not point to the proxy. For instance, it is perfectly valid for a customer using an MCI Worldcom proxy with a host name of sip.wcom.com to call someone with a request uri of sip:lili@ss8networks.com. Thus, if I wanted to call you, using my proxy server for the first hop (maybe because that is the only way I can get the call to go through the MCI Worldcom firewall) I can send the following INVITE request to my proxy. Note that my user agent may be configured to send all requests to the sip.wcom.com proxy, or I may on a call-by-call basis decide where to send the request. Calling UA ---------------------> Proxy srd@srd.wcom.com sip.wcom.com INVITE sip:lili@ss8networks.com SIP/2.0 Via: SIP/2.0/UDP srd.wcom.com From: sip:srd@srd.wcom.com To: sip:lili@ss8networks.com callid: 1234@srd.wcom.com Cseq: 1 INVITE In this case the proxy is providing the service to the calling user. If the proxy doesn't know anything about lili@ss8networks.com then it would proxy the request to the ss8networks.com host, in this case assumed to be a proxy, but it could be your end device. Proxy ---------------------> Proxy sip.wcom.com ss8networks.com INVITE sip:lili@ss8networks.com SIP/2.0 Via: SIP/2.0/UDP sip.wcom.com;branch=xyz Via: SIP/2.0/UDP srd.wcom.com From: sip:srd@srd.wcom.com To: sip:lili@ss8networks.com callid: 1234@srd.wcom.com Cseq: 1 INVITE Note that the request uri doesn't change, just the destination for the message. It is also possible that the proxy is also providing a service to the called user, in which case it may change the request uri before sending it to the next hop. It would probably be helpful to add a scenario like this to the call flow document. Steve > -----Original Message----- > From: Li Li [mailto:lili@ss8networks.com] > Sent: Tuesday, April 04, 2000 9:08 PM > To: Johnston, Alan > Cc: Jonathan Rosenberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Re: questions on rfc2543bis > > > > > > > > I thought your question might have been based on the use of > > Request-URI in the > > Call Flows draft. > > Yes. Alan, my misunderstanding was exactly resulted from there. > > > > I think the Request-URIs in the draft were formulated based on > > the (mistaken?) > > idea that the host portion of the Request-URI should map to the > > IP address of > > the proxy or server (the entity to which the request was sent). > > > > For example, in 3.1.2 on page 25 of > > draft-ietf-sip-call-flows-00.txt, message F4 > > has the INVITE Request-URI of UserB@ss1.wcom.com but the To > > header contains > > UserB@there.com where ss1.wcom.com is the Proxy Server. > > > > Should the Request-URI instead match the To header in this case? > > Always have the host portion of the Request-URI mapped to the > IP address of the proxy or server may have a problem when there is > a local proxy that handles many (or all) outgoing calls for a caller. > Put Request-URI as UserB@wcom.com in this example may be better, > my own take. Clearer to me. If proxy ss1 only handles calls to users > in wcom.com, things may not be too bad if the INVITE message has > Request-URI with ss1.wcom.com in the host portion. But say if > the caller > also wants to call somebody outside of wcom.com but should > access through > the > wcom's ss1 proxy for all his services. If in this case the > caller UAC gets > all the destinations in the world mapped to a unique name@ss1.wcom.com > in the Request-URI in the INVITE message, we'd have problems > of too many > mappings to handle for ss1.wcom.com. Of course, probably user > A can send his > different calls directly to different proxy servers of the destination > carrier's > network, which I don't know if it is the case. > > li li > > > > Alan Johnston > > MCI WorldCom > > > > Li Li wrote: > > > > > > > > > > > > > Thanks for pointing/confirming about the unique name > space. Then if > > > > > there is a "somebody@mciworldcom.com" and a > > "somebody@bellcanada.com", > > > > > the proxy server needs to configure two names as > > somebody1@foo.com and > > > > > somebody2@foo.com to send the call to different > called destinations? > > > > > > > > You've lost me. If I call somebody@mciworldcom.com and > > > > somebody@bellcanada.com, those will go to two different > proxies (or > > > > possibly the same proxy doing virtual hosting). If those map to > > > > different people, then the outgoing URIs will be different. > > > > > > I see the problem I have is thst from all the call flow > examples in the > > > call flow draft, the INVITE message always have > user@proxydomain in the > > > Request-URI and the Request-URI changes all the time from proxy > > to proxy. > > > For example, if the INVITE goes through proxy ss1.mciworld.com and > > > ss2.mciworld.com. The Request-URI in the INVITE message > is shown as > > > bigguy@ss1.mciworldcom.com and then changed to > > bigguy@ss2.mciworldcom.com. > > > Should the caller UAC just send in Request-URI > bigguy@mciworldcom.com to > > > SS1 proxy. The SS1 does a look up and know that SS2 handles > > > bigguy@mciworldcom.com > > > and proxy it to SS2? Otherwise, as in the draft, it implies to me > > > that everyone in the mciworld.com also should have a > unique name in the > > > ss1.mciworldcom.com so that SS1 can handle it. > > > That leads me to think that when an INVITE is sent to a proxy, > > it should use > > > the proxy's host name in the host part of the Request-URI. But > > as what you > > > pointed out here, really the Request-URI should be the > destination > > > user@host > > > and is sent to the proxy of the destination domain. > > > Thanks for your help. Very much apprecaited. > > > > > > li li > > > > > > > > > > > > So > > > > > the proxy server should not serve too many different > > destination domains > > > > > as this would make the name management impossible to give them > > > > all different > > > > > names in the proxy's domain. Is this right? > > > > > > > > No, of course not. Why is this a problem? The proxy is > serving many > > > > domains, as you say. To me, this means it handles requests for > > > > domain1.com, domain2.com, etc. You also seem to imply > that these are > > > > mapped into a single namespace in the "proxy's domain". > I don't follow > > > > that. If it receives a call for user1@domain1.com, it checks > > its tables > > > > for domain1.com, and finds that this is mapped to > user_1@foo.com, and > > > > sends it out to foo.com. Not all incoming request get mapped > > to foo.com. > > > > For those that do, its up to foo.com to properly manage their > > namespace. > > > > > > > > -Jonathan R. > > > > > > > > -- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East > Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: > (732) 741-4778 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (732) 741-7244 > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Apr 5 04: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 EAA07349 for ; Wed, 5 Apr 2000 04: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 D7E6444337; Wed, 5 Apr 2000 04:06:57 -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 61B7444336 for ; Wed, 5 Apr 2000 04:06:55 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FSJ00E9XAM2LL@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Apr 2000 08:08:26 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00K01AM2QT@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 08:08:26 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00J4WAM14P@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 08:08:26 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id ; Wed, 05 Apr 2000 08:08:25 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 08:08:23 +0000 From: "Donovan, Steven R." Subject: RE: [SIP] detection of retransmitted request at stateful proxy To: "'William Marshall'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D83493C6@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Bill, The proxy needs to use the request URI to differentiate between requests received. Consider the following scenario discussed earlier on the list: C1--->A--->B--->C--->A--->C2 This is a "legal" request loop when the same request (as defined by to, from, callid and cseq) gets to A the second time with a different request uri. As such, it should not be dropped or rejected as a via loop. Note that in this scenario, proxy A needs to use the branch tag in the first Via it adds to the request to point to (or contain) the original request uri. If the request uri indicated in the branch tag is the same as the request uri in the request the second time the request is received by A, then it is a via loop. If not, then it is a legal loop. I'm sorry if the wording is a little convoluted, I'm still a little sleep deprived from flying over the pacific ocean... Steve > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Tuesday, April 04, 2000 2:22 PM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] detection of retransmitted request at > stateful proxy > > > > > > Bill, I think you are referring to the problem of request > merging in a > > forking proxy - refer to Jonathan's page - he has a small > article and > > possible solutions. > > > > -- > > Best regards, > > Shail > > Found that article, but I think the problem I'm describing is a little > different. Jonathan's diagram is: > > > ---- > /---| B |-\ > / ---- \ > ---- ---- / \ ---- ---- ---- > | C1 |-----| A | -| D |-------| E |-----| C2 | > ---- ---- \ / ---- ---- ---- > \ ---- / > \---| C |-/ > ---- > > and the key item is that both forked requests are to go to C2. > > I would instead draw the diagram as: > > ---- ---- > /---| B |-\ /--| C2 | > / ---- \ / ---- > ---- ---- / \ ---- / > | C1 |-----| A | -| D | > ---- ---- \ / ---- \ > \ ---- / \ ---- > \---| C |-/ \--| C3 | > ---- ---- > where the key item is that the two forked requests from A are intended > to get to different endpoints; they just happen to cross at another > proxy on the way. (Or, perhaps the translation done at A > says the next > proxy for both C2 and C3 is D; then we avoid B and C completely.) > > Jonathan's mechanisms to toss the secondary requests believing them > to be duplicates isn't right for this case. > > I think the problem still is that proxy-D believes the second > request it > receives is a duplicate, even if the Request-URI for the first > says C2 and the second says C3. > > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Tue, 04 Apr 2000 14:05:01 -0400 > From: Shail Bhatnagar > Subject: Re: [SIP] detection of retransmitted request at > stateful proxy > > William Marshall wrote: > > > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > > If the answer is in the mailing list archives, or the notes file, > > or the faq, I've missed it. > > > > If a forking proxy receives an INVITE request, and generates two > > INVITES from it, according to 12.4 the only difference between them > > is the branch=x in the via header (and probably the Request-URI too) > > > > If it happens that both of those forked requests are sent > to the same > > stateful proxy as the next hop, how does that proxy know that > > the second isn't a retransmission? To, From (including tags), > > Call-ID, and CSeq are all identical. > > > > Adding a tag on the From header at the forking proxy would seem to > > be a bad idea, since then the response wouldn't match at the UAC. > > Also, there may already be a tag on the From header. > > > > Does this mean the stateful proxy needs to compare Via headers > > also, in determining whether the received request is a > retransmission? > > Or, should it compare the Request-URI? > > Is there some other way it can tell that the second is a > real request? > > > > Bill Marshall > > wtm@research.att.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > Bill, I think you are referring to the problem of request > merging in a > forking proxy - refer to Jonathan's page - he has a small article and > possible solutions. > > -- > Best regards, > Shail > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Apr 5 08:17: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 IAA08705 for ; Wed, 5 Apr 2000 08:17: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 5094344343; Wed, 5 Apr 2000 08:16:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 4FEEC44336 for ; Wed, 5 Apr 2000 08:16:02 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D66781E017; Wed, 5 Apr 2000 08:17:35 -0400 (EDT) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA06333; Wed, 5 Apr 2000 08:17:35 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id IAA37846; Wed, 5 Apr 2000 08:16:17 -0400 (EDT) Date: Wed, 5 Apr 2000 08:16:17 -0400 (EDT) Message-Id: <200004051216.IAA37846@fish-ha.research.att.com> Subject: RE: [SIP] detection of retransmitted request at stateful proxy To: Steven.R.Donovan@wcom.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: X-BeenThere: sip@lists.bell-labs.com Steve, Thanks for the response. I had thought loop detection was a completely separable issue. It obviously isn't. From your response, I take it the proxy needs to use the Request-URI as part of the loop detection, and somehow encodes the Request-URI into the 'x' of branch=x in the via header. Does that also imply the proxy needs to use the Request-URI for retransmission detection as well? So that it compares From, To, Call-ID, CSeq, and Request-URI to determine whether the received request is a retransmission of a previous request? It seems it would have to; otherwise proxy A in your example would consider the second request it received (the one with the modified Request-URI) a retransmission of the initial request from C1, and ignore it. Bill Marshall wtm@research.att.com ----- original message ----- > Date: Wed, 05 Apr 2000 08:08:23 +0000 > From: "Donovan, Steven R." > Subject: RE: [SIP] detection of retransmitted request at stateful proxy > To: "'William Marshall'" , sip@lists.bell-labs.com > > Bill, > > The proxy needs to use the request URI to differentiate between requests > received. Consider the following scenario discussed earlier on the list: > > C1--->A--->B--->C--->A--->C2 > > This is a "legal" request loop when the same request (as defined by to, > from, callid and cseq) gets to A the second time with a different request > uri. As such, it should not be dropped or rejected as a via loop. > > Note that in this scenario, proxy A needs to use the branch tag in the first > Via it adds to the request to point to (or contain) the original request > uri. If the request uri indicated in the branch tag is the same as the > request uri in the request the second time the request is received by A, > then it is a via loop. If not, then it is a legal loop. > > I'm sorry if the wording is a little convoluted, I'm still a little sleep > deprived from flying over the pacific ocean... > > Steve > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Tuesday, April 04, 2000 2:22 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] detection of retransmitted request at > > stateful proxy > > > > > > > > > > Bill, I think you are referring to the problem of request > > merging in a > > > forking proxy - refer to Jonathan's page - he has a small > > article and > > > possible solutions. > > > > > > -- > > > Best regards, > > > Shail > > > > Found that article, but I think the problem I'm describing is a little > > different. Jonathan's diagram is: > > > > > > ---- > > /---| B |-\ > > / ---- \ > > ---- ---- / \ ---- ---- ---- > > | C1 |-----| A | -| D |-------| E |-----| C2 | > > ---- ---- \ / ---- ---- ---- > > \ ---- / > > \---| C |-/ > > ---- > > > > and the key item is that both forked requests are to go to C2. > > > > I would instead draw the diagram as: > > > > ---- ---- > > /---| B |-\ /--| C2 | > > / ---- \ / ---- > > ---- ---- / \ ---- / > > | C1 |-----| A | -| D | > > ---- ---- \ / ---- \ > > \ ---- / \ ---- > > \---| C |-/ \--| C3 | > > ---- ---- > > where the key item is that the two forked requests from A are intended > > to get to different endpoints; they just happen to cross at another > > proxy on the way. (Or, perhaps the translation done at A > > says the next > > proxy for both C2 and C3 is D; then we avoid B and C completely.) > > > > Jonathan's mechanisms to toss the secondary requests believing them > > to be duplicates isn't right for this case. > > > > I think the problem still is that proxy-D believes the second > > request it > > receives is a duplicate, even if the Request-URI for the first > > says C2 and the second says C3. > > > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > Date: Tue, 04 Apr 2000 14:05:01 -0400 > > From: Shail Bhatnagar > > Subject: Re: [SIP] detection of retransmitted request at > > stateful proxy > > > > William Marshall wrote: > > > > > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > > > If the answer is in the mailing list archives, or the notes file, > > > or the faq, I've missed it. > > > > > > If a forking proxy receives an INVITE request, and generates two > > > INVITES from it, according to 12.4 the only difference between them > > > is the branch=x in the via header (and probably the Request-URI too) > > > > > > If it happens that both of those forked requests are sent > > to the same > > > stateful proxy as the next hop, how does that proxy know that > > > the second isn't a retransmission? To, From (including tags), > > > Call-ID, and CSeq are all identical. > > > > > > Adding a tag on the From header at the forking proxy would seem to > > > be a bad idea, since then the response wouldn't match at the UAC. > > > Also, there may already be a tag on the From header. > > > > > > Does this mean the stateful proxy needs to compare Via headers > > > also, in determining whether the received request is a > > retransmission? > > > Or, should it compare the Request-URI? > > > Is there some other way it can tell that the second is a > > real request? > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > Bill, I think you are referring to the problem of request > > merging in a > > forking proxy - refer to Jonathan's page - he has a small article and > > possible solutions. > > > > -- > > Best regards, > > Shail > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/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 Apr 5 09:08:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09585 for ; Wed, 5 Apr 2000 09: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 DDA7144340; Wed, 5 Apr 2000 09:06:31 -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 0C89744336 for ; Wed, 5 Apr 2000 09:06:30 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id CBAC64CE03 for ; Wed, 5 Apr 2000 09:08:03 -0400 (EDT) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA09242 for ; Wed, 5 Apr 2000 09:08:02 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id JAA45596 for sip@lists.bell-labs.com; Wed, 5 Apr 2000 09:07:45 -0400 (EDT) Date: Wed, 5 Apr 2000 09:07:45 -0400 (EDT) Message-Id: <200004051307.JAA45596@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and others Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com At the Adelaide meeting, I believe there was general consensus on the method described in draft-manyfolks-sip-resource-00 for qos and security preconditions. Two remaining issues were identified (1) the method needs a new name (2) whether the UAS can specify preconditions if the UAC doesn't PRECONDITION-MET is clearly a bad choice of a method name. However with one vote each for PRE-INFO, ASSERT, CONFIRM, QUACK, PROGRESS, ADMITTED, PRDONE, PRMET, PREMET, and PREDONE, there was clearly no consensus among the authors. Plenty of nominations. Need votes. If the UAC does not put a precondition line into the SDP, and the UAS does, the main question is how the UAS knows that it will be honored. (If it inserts the line and doesn't ask for a confirmation, then it clearly won't know if it is honored or not. sharp stick.) If the UAC supports reliable provisional responses, then the UAS can ask for a PRACK, and get a PRACK with SDP with a precondition line. UAS then knows to expect a FOOBAR message (or whatever it gets called). If the UAC doesn't include an SDP with the PRACK, or includes an SDP without the precondition line, then the UAS knows to not expect a FOOBAR. So the case left open is if there is no support indicated for 100rel. I'd consider that to mean no support for preconditions either. Comments? Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 09:19: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 JAA09773 for ; Wed, 5 Apr 2000 09:19: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 75C184434E; Wed, 5 Apr 2000 09:18:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 65CBB44349 for ; Wed, 5 Apr 2000 09:17:59 -0400 (EDT) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA01843; Wed, 5 Apr 2000 09:19:30 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA18258; Wed, 5 Apr 2000 09:19:31 -0400 (EDT) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <22M6M1W5>; Wed, 5 Apr 2000 09:14:40 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF678109@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and others Date: Wed, 5 Apr 2000 09:19:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Always ready with an opinion, while QUACK is a winner name :), I'll vote for PRMET. I think your suggestion that 100rel support is required for UAS asserting PRMET is just fine. Brian > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Wednesday, April 05, 2000 9:08 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and > others > > > At the Adelaide meeting, I believe there was general consensus on the > method described in draft-manyfolks-sip-resource-00 for qos and > security preconditions. > > Two remaining issues were identified > (1) the method needs a new name > (2) whether the UAS can specify preconditions if the UAC doesn't > > PRECONDITION-MET is clearly a bad choice of a method name. However > with one vote each for PRE-INFO, ASSERT, CONFIRM, QUACK, PROGRESS, > ADMITTED, PRDONE, PRMET, PREMET, and PREDONE, there was clearly > no consensus among the authors. Plenty of nominations. Need votes. > > If the UAC does not put a precondition line into the SDP, and the UAS > does, the main question is how the UAS knows that it will be honored. > (If it inserts the line and doesn't ask for a confirmation, then it > clearly won't know if it is honored or not. sharp stick.) > > If the UAC supports reliable provisional responses, then the UAS can > ask for a PRACK, and get a PRACK with SDP with a precondition line. > UAS then knows to expect a FOOBAR message (or whatever it > gets called). > > If the UAC doesn't include an SDP with the PRACK, or includes an SDP > without the precondition line, then the UAS knows to not > expect a FOOBAR. > > So the case left open is if there is no support indicated for 100rel. > I'd consider that to mean no support for preconditions either. > > Comments? > > Bill Marshall > wtm@research.att.com > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 10:50: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 KAA10956 for ; Wed, 5 Apr 2000 10:50: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 0D00C44339; Wed, 5 Apr 2000 10:48:50 -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 C0F3744336 for ; Wed, 5 Apr 2000 10:48:47 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FSJ00DP6T7MLF@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Apr 2000 14:50:10 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00C01T7LE0@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 14:50:10 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00B4CT7LE8@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 14:50:09 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2571.0) id <2294KKSZ>; Wed, 05 Apr 2000 14:50:09 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 14:50:07 +0000 From: "Donovan, Steven R." Subject: RE: [SIP] detection of retransmitted request at stateful proxy To: "'William Marshall'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D83493C8@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=ISO-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Bill, Yes, you are correct, the proxy needs to use the request uri to determine retransmissions as well. And yes, the proxy needs to be able to determine the original request uri based on the content of the branch tag. Steve > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Wednesday, April 05, 2000 7:16 AM > To: Donovan, Steven R.; sip@lists.bell-labs.com > Subject: RE: [SIP] detection of retransmitted request at > stateful proxy > > > Steve, > > Thanks for the response. > > I had thought loop detection was a completely separable issue. It > obviously isn't. > > From your response, I take it the proxy needs to use the Request-URI > as part of the loop detection, and somehow encodes the Request-URI > into the 'x' of branch=x in the via header. > > Does that also imply the proxy needs to use the Request-URI for > retransmission detection as well? So that it compares From, > To, Call-ID, > CSeq, and Request-URI to determine whether the received request is > a retransmission of a previous request? > > It seems it would have to; otherwise proxy A in your example would > consider the second request it received (the one with the modified > Request-URI) a retransmission of the initial request from C1, > and ignore it. > > Bill Marshall > wtm@research.att.com > > ----- original message ----- > > Date: Wed, 05 Apr 2000 08:08:23 +0000 > > From: "Donovan, Steven R." > > Subject: RE: [SIP] detection of retransmitted request at > stateful proxy > > To: "'William Marshall'" , > sip@lists.bell-labs.com > > > > Bill, > > > > The proxy needs to use the request URI to differentiate > between requests > > received. Consider the following scenario discussed > earlier on the list: > > > > C1--->A--->B--->C--->A--->C2 > > > > This is a "legal" request loop when the same request (as > defined by to, > > from, callid and cseq) gets to A the second time with a > different request > > uri. As such, it should not be dropped or rejected as a via loop. > > > > Note that in this scenario, proxy A needs to use the branch > tag in the first > > Via it adds to the request to point to (or contain) the > original request > > uri. If the request uri indicated in the branch tag is the > same as the > > request uri in the request the second time the request is > received by A, > > then it is a via loop. If not, then it is a legal loop. > > > > I'm sorry if the wording is a little convoluted, I'm still > a little sleep > > deprived from flying over the pacific ocean... > > > > Steve > > > > > -----Original Message----- > > > From: William Marshall [mailto:wtm@research.att.com] > > > Sent: Tuesday, April 04, 2000 2:22 PM > > > To: sip@lists.bell-labs.com > > > Subject: Re: [SIP] detection of retransmitted request at > > > stateful proxy > > > > > > > > > > > > > > Bill, I think you are referring to the problem of request > > > merging in a > > > > forking proxy - refer to Jonathan's page - he has a small > > > article and > > > > possible solutions. > > > > > > > > -- > > > > Best regards, > > > > Shail > > > > > > Found that article, but I think the problem I'm > describing is a little > > > different. Jonathan's diagram is: > > > > > > > > > ---- > > > /---| B |-\ > > > / ---- \ > > > ---- ---- / \ ---- ---- > ---- > > > | C1 |-----| A | -| D |-------| E > |-----| C2 | > > > ---- ---- \ / ---- ---- > ---- > > > \ ---- / > > > \---| C |-/ > > > ---- > > > > > > and the key item is that both forked requests are to go to C2. > > > > > > I would instead draw the diagram as: > > > > > > ---- ---- > > > /---| B |-\ /--| C2 | > > > / ---- \ / ---- > > > ---- ---- / \ ---- / > > > | C1 |-----| A | -| D | > > > ---- ---- \ / ---- \ > > > \ ---- / \ ---- > > > \---| C |-/ \--| C3 | > > > ---- ---- > > > where the key item is that the two forked requests from A > are intended > > > to get to different endpoints; they just happen to cross > at another > > > proxy on the way. (Or, perhaps the translation done at A > > > says the next > > > proxy for both C2 and C3 is D; then we avoid B and C completely.) > > > > > > Jonathan's mechanisms to toss the secondary requests > believing them > > > to be duplicates isn't right for this case. > > > > > > I think the problem still is that proxy-D believes the second > > > request it > > > receives is a duplicate, even if the Request-URI for the first > > > says C2 and the second says C3. > > > > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > -----original message----- > > > Date: Tue, 04 Apr 2000 14:05:01 -0400 > > > From: Shail Bhatnagar > > > Subject: Re: [SIP] detection of retransmitted request at > > > stateful proxy > > > > > > William Marshall wrote: > > > > > > > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > > > > If the answer is in the mailing list archives, or the > notes file, > > > > or the faq, I've missed it. > > > > > > > > If a forking proxy receives an INVITE request, and generates two > > > > INVITES from it, according to 12.4 the only difference > between them > > > > is the branch=x in the via header (and probably the > Request-URI too) > > > > > > > > If it happens that both of those forked requests are sent > > > to the same > > > > stateful proxy as the next hop, how does that proxy know that > > > > the second isn't a retransmission? To, From (including tags), > > > > Call-ID, and CSeq are all identical. > > > > > > > > Adding a tag on the From header at the forking proxy > would seem to > > > > be a bad idea, since then the response wouldn't match > at the UAC. > > > > Also, there may already be a tag on the From header. > > > > > > > > Does this mean the stateful proxy needs to compare Via headers > > > > also, in determining whether the received request is a > > > retransmission? > > > > Or, should it compare the Request-URI? > > > > Is there some other way it can tell that the second is a > > > real request? > > > > > > > > Bill Marshall > > > > wtm@research.att.com > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > Bill, I think you are referring to the problem of request > > > merging in a > > > forking proxy - refer to Jonathan's page - he has a small > article and > > > possible solutions. > > > > > > -- > > > Best regards, > > > Shail > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/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 Apr 5 11:22: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 LAA11508 for ; Wed, 5 Apr 2000 11:22: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 29D9C44338; Wed, 5 Apr 2000 11:20: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 EAD1544336 for ; Wed, 5 Apr 2000 11:20:54 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA07030; Wed, 5 Apr 2000 11:22:28 -0400 (EDT) Message-ID: <38EB5A34.DB2DA87E@cs.columbia.edu> Date: Wed, 05 Apr 2000 11:22:28 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and others References: <200004051307.JAA45596@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit William Marshall wrote: > > At the Adelaide meeting, I believe there was general consensus on the > method described in draft-manyfolks-sip-resource-00 for qos and > security preconditions. > > Two remaining issues were identified > (1) the method needs a new name > (2) whether the UAS can specify preconditions if the UAC doesn't > > PRECONDITION-MET is clearly a bad choice of a method name. However Why is that? At least it reflects what's going on... > with one vote each for PRE-INFO, ASSERT, CONFIRM, QUACK, PROGRESS, > ADMITTED, PRDONE, PRMET, PREMET, and PREDONE, there was clearly > no consensus among the authors. Plenty of nominations. Need votes. SATISFIED? > > If the UAC does not put a precondition line into the SDP, and the UAS > does, the main question is how the UAS knows that it will be honored. > (If it inserts the line and doesn't ask for a confirmation, then it > clearly won't know if it is honored or not. sharp stick.) > > If the UAC supports reliable provisional responses, then the UAS can > ask for a PRACK, and get a PRACK with SDP with a precondition line. > UAS then knows to expect a FOOBAR message (or whatever it gets called). > > If the UAC doesn't include an SDP with the PRACK, or includes an SDP > without the precondition line, then the UAS knows to not expect a FOOBAR. > > So the case left open is if there is no support indicated for 100rel. > I'd consider that to mean no support for preconditions either. Yes, or we could use Supported to make it more explicit. > > Comments? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 11:24:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11523 for ; Wed, 5 Apr 2000 11: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 BF69244349; Wed, 5 Apr 2000 11:21:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 3F9FC44346 for ; Wed, 5 Apr 2000 11:21:28 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id VAA12948; Wed, 5 Apr 2000 21:24:00 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568B8.0054934F ; Wed, 5 Apr 2000 20:53:47 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: William Marshall Cc: Steven.R.Donovan@wcom.com, sip@lists.bell-labs.com Message-ID: <652568B8.0054923D.00@sampark.hss.hns.com> Date: Wed, 5 Apr 2000 20:53:43 +0530 Subject: RE: [SIP] detection of retransmitted request at stateful proxy Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=S9f5gn3833EEW5G4PEyguhHF5j6Yun3GPS49G4pMQGhlXWW1dAk4CxIv" 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: X-BeenThere: sip@lists.bell-labs.com --0__=S9f5gn3833EEW5G4PEyguhHF5j6Yun3GPS49G4pMQGhlXWW1dAk4CxIv Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The bis draft (latest copy) does suggest that while generating branch-ids one should use a crypto hash of to,from,callid,cseq &Request-URI suggesting MD5 as an algorithm. Infact section 12.3.1 mentions the use of branch in loop detection "A request has been looped if the server finds its own address in the Via header field and the hash computation over the fields enumerated in Section 6.45.5 yields the same value as the --0__=S9f5gn3833EEW5G4PEyguhHF5j6Yun3GPS49G4pMQGhlXWW1dAk4CxIv Content-type: text/plain; charset=windows-1257 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =93branch=94 parameter in the Via entry containing the proxy server=92s address. The To, From, Call-ID,andContact tags are copied exactly from the origi= nal request. The proxy SHOULD change the Request-URI to indicate the server where it intends t= o send the request. A proxy server always inserts a Via header field containing its own add= ress into those requests that are caused by an incoming request. Each proxy MUST insert a =93branch=94 pa= rameter (Section 6.45). " However, 12.3,4 does not mention veryfying from the branch id for a retransmission. Should ths not be added ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems steve> From your response, I take it the proxy needs to use the Request= -URI steve> as part of the loop detection, and somehow encodes the Request-= URI steve> into the 'x' of branch=3Dx in the via header. William Marshall on 04/05/2000 05:46:17 PM To: Steven.R.Donovan@wcom.com, sip@lists.bell-labs.com cc: Subject: RE: [SIP] detection of retransmitted request at stateful prox= y = --0__=S9f5gn3833EEW5G4PEyguhHF5j6Yun3GPS49G4pMQGhlXWW1dAk4CxIv Content-type: text/plain; charset=us-ascii Content-Disposition: inline Steve, Thanks for the response. I had thought loop detection was a completely separable issue. It obviously isn't. From your response, I take it the proxy needs to use the Request-URI as part of the loop detection, and somehow encodes the Request-URI into the 'x' of branch=x in the via header. Does that also imply the proxy needs to use the Request-URI for retransmission detection as well? So that it compares From, To, Call-ID, CSeq, and Request-URI to determine whether the received request is a retransmission of a previous request? It seems it would have to; otherwise proxy A in your example would consider the second request it received (the one with the modified Request-URI) a retransmission of the initial request from C1, and ignore it. Bill Marshall wtm@research.att.com ----- original message ----- > Date: Wed, 05 Apr 2000 08:08:23 +0000 > From: "Donovan, Steven R." > Subject: RE: [SIP] detection of retransmitted request at stateful proxy > To: "'William Marshall'" , sip@lists.bell-labs.com > > Bill, > > The proxy needs to use the request URI to differentiate between requests > received. Consider the following scenario discussed earlier on the list: > > C1--->A--->B--->C--->A--->C2 > > This is a "legal" request loop when the same request (as defined by to, > from, callid and cseq) gets to A the second time with a different request > uri. As such, it should not be dropped or rejected as a via loop. > > Note that in this scenario, proxy A needs to use the branch tag in the first > Via it adds to the request to point to (or contain) the original request > uri. If the request uri indicated in the branch tag is the same as the > request uri in the request the second time the request is received by A, > then it is a via loop. If not, then it is a legal loop. > > I'm sorry if the wording is a little convoluted, I'm still a little sleep > deprived from flying over the pacific ocean... > > Steve > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Tuesday, April 04, 2000 2:22 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] detection of retransmitted request at > > stateful proxy > > > > > > > > > > Bill, I think you are referring to the problem of request > > merging in a > > > forking proxy - refer to Jonathan's page - he has a small > > article and > > > possible solutions. > > > > > > -- > > > Best regards, > > > Shail > > > > Found that article, but I think the problem I'm describing is a little > > different. Jonathan's diagram is: > > > > > > ---- > > /---| B |-\ > > / ---- \ > > ---- ---- / \ ---- ---- ---- > > | C1 |-----| A | -| D |-------| E |-----| C2 | > > ---- ---- \ / ---- ---- ---- > > \ ---- / > > \---| C |-/ > > ---- > > > > and the key item is that both forked requests are to go to C2. > > > > I would instead draw the diagram as: > > > > ---- ---- > > /---| B |-\ /--| C2 | > > / ---- \ / ---- > > ---- ---- / \ ---- / > > | C1 |-----| A | -| D | > > ---- ---- \ / ---- \ > > \ ---- / \ ---- > > \---| C |-/ \--| C3 | > > ---- ---- > > where the key item is that the two forked requests from A are intended > > to get to different endpoints; they just happen to cross at another > > proxy on the way. (Or, perhaps the translation done at A > > says the next > > proxy for both C2 and C3 is D; then we avoid B and C completely.) > > > > Jonathan's mechanisms to toss the secondary requests believing them > > to be duplicates isn't right for this case. > > > > I think the problem still is that proxy-D believes the second > > request it > > receives is a duplicate, even if the Request-URI for the first > > says C2 and the second says C3. > > > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > Date: Tue, 04 Apr 2000 14:05:01 -0400 > > From: Shail Bhatnagar > > Subject: Re: [SIP] detection of retransmitted request at > > stateful proxy > > > > William Marshall wrote: > > > > > > This question is regarding section 12.3.4 of 2543 (and 2543bis). > > > If the answer is in the mailing list archives, or the notes file, > > > or the faq, I've missed it. > > > > > > If a forking proxy receives an INVITE request, and generates two > > > INVITES from it, according to 12.4 the only difference between them > > > is the branch=x in the via header (and probably the Request-URI too) > > > > > > If it happens that both of those forked requests are sent > > to the same > > > stateful proxy as the next hop, how does that proxy know that > > > the second isn't a retransmission? To, From (including tags), > > > Call-ID, and CSeq are all identical. > > > > > > Adding a tag on the From header at the forking proxy would seem to > > > be a bad idea, since then the response wouldn't match at the UAC. > > > Also, there may already be a tag on the From header. > > > > > > Does this mean the stateful proxy needs to compare Via headers > > > also, in determining whether the received request is a > > retransmission? > > > Or, should it compare the Request-URI? > > > Is there some other way it can tell that the second is a > > real request? > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > Bill, I think you are referring to the problem of request > > merging in a > > forking proxy - refer to Jonathan's page - he has a small article and > > possible solutions. > > > > -- > > Best regards, > > Shail > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip --0__=S9f5gn3833EEW5G4PEyguhHF5j6Yun3GPS49G4pMQGhlXWW1dAk4CxIv-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 11:35:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11727 for ; Wed, 5 Apr 2000 11:35: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 427C844346; Wed, 5 Apr 2000 11:33: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 2DAA94433C for ; Wed, 5 Apr 2000 11:33:21 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FSJ0015PVA1IG@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Apr 2000 15:34:49 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00C01VA0TC@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 15:34:48 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00C4BV9X7Q@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 15:34:47 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2571.0) id <2294KM02>; Wed, 05 Apr 2000 15:34:45 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 15:34:41 +0000 From: "Donovan, Steven R." Subject: RE: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and others To: "'Rosen, Brian'" , "'William Marshall'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D83493C9@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=ISO-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com I agree with Brian that QUACK has a nice ring to it, however, given that the UAC is telling the UAS that it is free to advance in the call setup, how about one of CONTINUE RESUME PROCEED Steve > -----Original Message----- > From: Rosen, Brian [mailto:brosen@fore.com] > Sent: Wednesday, April 05, 2000 8:19 AM > To: 'William Marshall'; sip@lists.bell-labs.com > Subject: RE: [SIP] Open issues from manyfolks draft: PRECONDITION-MET > and others > > > Always ready with an opinion, while QUACK is a winner name :), > I'll vote for PRMET. I think your suggestion that 100rel support > is required for UAS asserting PRMET is just fine. > > Brian > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Wednesday, April 05, 2000 9:08 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Open issues from manyfolks draft: > PRECONDITION-MET and > > others > > > > > > At the Adelaide meeting, I believe there was general > consensus on the > > method described in draft-manyfolks-sip-resource-00 for qos and > > security preconditions. > > > > Two remaining issues were identified > > (1) the method needs a new name > > (2) whether the UAS can specify preconditions if the UAC doesn't > > > > PRECONDITION-MET is clearly a bad choice of a method name. However > > with one vote each for PRE-INFO, ASSERT, CONFIRM, QUACK, PROGRESS, > > ADMITTED, PRDONE, PRMET, PREMET, and PREDONE, there was clearly > > no consensus among the authors. Plenty of nominations. Need votes. > > > > If the UAC does not put a precondition line into the SDP, > and the UAS > > does, the main question is how the UAS knows that it will > be honored. > > (If it inserts the line and doesn't ask for a confirmation, then it > > clearly won't know if it is honored or not. sharp stick.) > > > > If the UAC supports reliable provisional responses, then the UAS can > > ask for a PRACK, and get a PRACK with SDP with a precondition line. > > UAS then knows to expect a FOOBAR message (or whatever it > > gets called). > > > > If the UAC doesn't include an SDP with the PRACK, or includes an SDP > > without the precondition line, then the UAS knows to not > > expect a FOOBAR. > > > > So the case left open is if there is no support indicated > for 100rel. > > I'd consider that to mean no support for preconditions either. > > > > Comments? > > > > Bill Marshall > > wtm@research.att.com > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 11: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 LAA11887 for ; Wed, 5 Apr 2000 11: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 8D3E94434F; Wed, 5 Apr 2000 11:49:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4610144336 for ; Wed, 5 Apr 2000 11:49: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 LAA01878; Wed, 5 Apr 2000 11:52:02 -0400 (EDT) Message-ID: <38EB62C6.98DB8900@dynamicsoft.com> Date: Wed, 05 Apr 2000 11:59:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Donovan, Steven R." Cc: "'Li Li'" , "Johnston, Alan" , sip@lists.bell-labs.com Subject: Re: [SIP] Re: questions on rfc2543bis References: <75C79E507864D3118AFC00805FEAB7D83493C7@ripexch001.mcit.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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit What Steve is saying is exactly correct. -Jonathan R. "Donovan, Steven R." wrote: > > Li Li, > > Just to be clear, it is certainly legal for the request uri received at a > proxy to contain a host portion that does not point to the proxy. > > For instance, it is perfectly valid for a customer using an MCI Worldcom > proxy with a host name of sip.wcom.com to call someone with a request uri of > sip:lili@ss8networks.com. > > Thus, if I wanted to call you, using my proxy server for the first hop > (maybe because that is the only way I can get the call to go through the MCI > Worldcom firewall) I can send the following INVITE request to my proxy. > Note that my user agent may be configured to send all requests to the > sip.wcom.com proxy, or I may on a call-by-call basis decide where to send > the request. > > Calling UA ---------------------> Proxy > srd@srd.wcom.com sip.wcom.com > > INVITE sip:lili@ss8networks.com SIP/2.0 > Via: SIP/2.0/UDP srd.wcom.com > From: sip:srd@srd.wcom.com > To: sip:lili@ss8networks.com > callid: 1234@srd.wcom.com > Cseq: 1 INVITE > > In this case the proxy is providing the service to the calling user. If the > proxy doesn't know anything about lili@ss8networks.com then it would proxy > the request to the ss8networks.com host, in this case assumed to be a proxy, > but it could be your end device. > > Proxy ---------------------> Proxy > sip.wcom.com ss8networks.com > > INVITE sip:lili@ss8networks.com SIP/2.0 > Via: SIP/2.0/UDP sip.wcom.com;branch=xyz > Via: SIP/2.0/UDP srd.wcom.com > From: sip:srd@srd.wcom.com > To: sip:lili@ss8networks.com > callid: 1234@srd.wcom.com > Cseq: 1 INVITE > > Note that the request uri doesn't change, just the destination for the > message. > > It is also possible that the proxy is also providing a service to the called > user, in which case it may change the request uri before sending it to the > next hop. > > It would probably be helpful to add a scenario like this to the call flow > document. > > Steve > > -----Original Message----- > > From: Li Li [mailto:lili@ss8networks.com] > > Sent: Tuesday, April 04, 2000 9:08 PM > > To: Johnston, Alan > > Cc: Jonathan Rosenberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: questions on rfc2543bis > > > > > > > > > > > > > > I thought your question might have been based on the use of > > > Request-URI in the > > > Call Flows draft. > > > > Yes. Alan, my misunderstanding was exactly resulted from there. > > > > > > I think the Request-URIs in the draft were formulated based on > > > the (mistaken?) > > > idea that the host portion of the Request-URI should map to the > > > IP address of > > > the proxy or server (the entity to which the request was sent). > > > > > > For example, in 3.1.2 on page 25 of > > > draft-ietf-sip-call-flows-00.txt, message F4 > > > has the INVITE Request-URI of UserB@ss1.wcom.com but the To > > > header contains > > > UserB@there.com where ss1.wcom.com is the Proxy Server. > > > > > > Should the Request-URI instead match the To header in this case? > > > > Always have the host portion of the Request-URI mapped to the > > IP address of the proxy or server may have a problem when there is > > a local proxy that handles many (or all) outgoing calls for a caller. > > Put Request-URI as UserB@wcom.com in this example may be better, > > my own take. Clearer to me. If proxy ss1 only handles calls to users > > in wcom.com, things may not be too bad if the INVITE message has > > Request-URI with ss1.wcom.com in the host portion. But say if > > the caller > > also wants to call somebody outside of wcom.com but should > > access through > > the > > wcom's ss1 proxy for all his services. If in this case the > > caller UAC gets > > all the destinations in the world mapped to a unique name@ss1.wcom.com > > in the Request-URI in the INVITE message, we'd have problems > > of too many > > mappings to handle for ss1.wcom.com. Of course, probably user > > A can send his > > different calls directly to different proxy servers of the destination > > carrier's > > network, which I don't know if it is the case. > > > > li li > > > > > > Alan Johnston > > > MCI WorldCom > > > > > > Li Li wrote: > > > > > > > > > > > > > > > > Thanks for pointing/confirming about the unique name > > space. Then if > > > > > > there is a "somebody@mciworldcom.com" and a > > > "somebody@bellcanada.com", > > > > > > the proxy server needs to configure two names as > > > somebody1@foo.com and > > > > > > somebody2@foo.com to send the call to different > > called destinations? > > > > > > > > > > You've lost me. If I call somebody@mciworldcom.com and > > > > > somebody@bellcanada.com, those will go to two different > > proxies (or > > > > > possibly the same proxy doing virtual hosting). If those map to > > > > > different people, then the outgoing URIs will be different. > > > > > > > > I see the problem I have is thst from all the call flow > > examples in the > > > > call flow draft, the INVITE message always have > > user@proxydomain in the > > > > Request-URI and the Request-URI changes all the time from proxy > > > to proxy. > > > > For example, if the INVITE goes through proxy ss1.mciworld.com and > > > > ss2.mciworld.com. The Request-URI in the INVITE message > > is shown as > > > > bigguy@ss1.mciworldcom.com and then changed to > > > bigguy@ss2.mciworldcom.com. > > > > Should the caller UAC just send in Request-URI > > bigguy@mciworldcom.com to > > > > SS1 proxy. The SS1 does a look up and know that SS2 handles > > > > bigguy@mciworldcom.com > > > > and proxy it to SS2? Otherwise, as in the draft, it implies to me > > > > that everyone in the mciworld.com also should have a > > unique name in the > > > > ss1.mciworldcom.com so that SS1 can handle it. > > > > That leads me to think that when an INVITE is sent to a proxy, > > > it should use > > > > the proxy's host name in the host part of the Request-URI. But > > > as what you > > > > pointed out here, really the Request-URI should be the > > destination > > > > user@host > > > > and is sent to the proxy of the destination domain. > > > > Thanks for your help. Very much apprecaited. > > > > > > > > li li > > > > > > > > > > > > > > > So > > > > > > the proxy server should not serve too many different > > > destination domains > > > > > > as this would make the name management impossible to give them > > > > > all different > > > > > > names in the proxy's domain. Is this right? > > > > > > > > > > No, of course not. Why is this a problem? The proxy is > > serving many > > > > > domains, as you say. To me, this means it handles requests for > > > > > domain1.com, domain2.com, etc. You also seem to imply > > that these are > > > > > mapped into a single namespace in the "proxy's domain". > > I don't follow > > > > > that. If it receives a call for user1@domain1.com, it checks > > > its tables > > > > > for domain1.com, and finds that this is mapped to > > user_1@foo.com, and > > > > > sends it out to foo.com. Not all incoming request get mapped > > > to foo.com. > > > > > For those that do, its up to foo.com to properly manage their > > > namespace. > > > > > > > > > > -Jonathan R. > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > > (732) 741-4778 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (732) 741-7244 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > 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: (732) 741-4778 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 Apr 5 12:14:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12311 for ; Wed, 5 Apr 2000 12:14: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 4274044339; Wed, 5 Apr 2000 12:13:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 21ECC44338 for ; Wed, 5 Apr 2000 12:13:04 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA11992 for ; Wed, 5 Apr 2000 12:14:38 -0400 (EDT) Message-ID: <38EB666E.617106E8@cs.columbia.edu> Date: Wed, 05 Apr 2000 12:14:38 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] 4th SIP bake-off status update Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit We expect about 150 participants from 46 groups at the 4th SIP bake-off (http://www.sipbakeoff.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 Wed Apr 5 12:25: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 MAA12465 for ; Wed, 5 Apr 2000 12: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 D035544337; Wed, 5 Apr 2000 12:24:01 -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 D887044336 for ; Wed, 5 Apr 2000 12:23:59 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FSJ00GDGXMJ2E@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Apr 2000 16:25:31 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00G01XMJR3@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 16:25:31 +0000 (GMT) Received: from omzmta04.mcit.com ([166.37.214.10]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSJ00G1SXMHH1@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 16:25:30 +0000 (GMT) Received: from C25776A ([166.35.225.166]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000405162528.XUAU1695@C25776A>; Wed, 05 Apr 2000 16:25:28 +0000 Date: Wed, 05 Apr 2000 11:25:33 -0500 From: Henry Sinnreich Subject: RE: [SIP] Open issues from manyfolks draft: PRECONDITION-MET and others In-reply-to: <4FBEA8857476D311A03300204840E1CF678109@whq-msgusr-02.fore.com> To: "Rosen, Brian" , "'William Marshall'" , sip@lists.bell-labs.com Reply-To: henry.sinnreich@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit We have identified in another SIP WG draft "QoS Assured" which is basically the same as discussed here, and "QoS Enabled". Am wondering if we should not have some foresight and chose a naming system that will make sense later on. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rosen, Brian >Sent: Wednesday, April 05, 2000 8:19 AM >To: 'William Marshall'; sip@lists.bell-labs.com >Subject: RE: [SIP] Open issues from manyfolks draft: >PRECONDITION-MET >and others > > >Always ready with an opinion, while QUACK is a winner name :), >I'll vote for PRMET. I think your suggestion that >100rel support >is required for UAS asserting PRMET is just fine. > >Brian > >> -----Original Message----- >> From: William Marshall [mailto:wtm@research.att.com] >> Sent: Wednesday, April 05, 2000 9:08 AM >> To: sip@lists.bell-labs.com >> Subject: [SIP] Open issues from manyfolks draft: >PRECONDITION-MET and >> others >> >> >> At the Adelaide meeting, I believe there was general >consensus on the >> method described in draft-manyfolks-sip-resource-00 >for qos and >> security preconditions. >> >> Two remaining issues were identified >> (1) the method needs a new name >> (2) whether the UAS can specify preconditions if >the UAC doesn't >> >> PRECONDITION-MET is clearly a bad choice of a method >name. However >> with one vote each for PRE-INFO, ASSERT, CONFIRM, >QUACK, PROGRESS, >> ADMITTED, PRDONE, PRMET, PREMET, and PREDONE, there >was clearly >> no consensus among the authors. Plenty of >nominations. Need votes. >> >> If the UAC does not put a precondition line into the >SDP, and the UAS >> does, the main question is how the UAS knows that it >will be honored. >> (If it inserts the line and doesn't ask for a >confirmation, then it >> clearly won't know if it is honored or not. sharp stick.) >> >> If the UAC supports reliable provisional responses, >then the UAS can >> ask for a PRACK, and get a PRACK with SDP with a >precondition line. >> UAS then knows to expect a FOOBAR message (or whatever it >> gets called). >> >> If the UAC doesn't include an SDP with the PRACK, or >includes an SDP >> without the precondition line, then the UAS knows to not >> expect a FOOBAR. >> >> So the case left open is if there is no support >indicated for 100rel. >> I'd consider that to mean no support for >preconditions either. >> >> Comments? >> >> Bill Marshall >> wtm@research.att.com >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Apr 5 12:48: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 MAA12745 for ; Wed, 5 Apr 2000 12:48: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 398FE44342; Wed, 5 Apr 2000 12:46:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thunderer.cnchost.com (thunderer.concentric.net [207.155.252.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7964E44337 for ; Wed, 5 Apr 2000 12:46:39 -0400 (EDT) Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122]) by thunderer.cnchost.com id MAA07470; Wed, 5 Apr 2000 12:48:02 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: "Donovan, Steven R." , "Johnston, Alan" Cc: "Jonathan Rosenberg" , Subject: RE: [SIP] Re: questions on rfc2543bis Date: Wed, 5 Apr 2000 12:49:21 -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) In-Reply-To: <75C79E507864D3118AFC00805FEAB7D83493C7@ripexch001.mcit.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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Fully agree with what you've explained. Adding a different scenario to the flow chart is good. li li > Just to be clear, it is certainly legal for the request uri received at a > proxy to contain a host portion that does not point to the proxy. > > For instance, it is perfectly valid for a customer using an MCI Worldcom > proxy with a host name of sip.wcom.com to call someone with a > request uri of > sip:lili@ss8networks.com. > > Thus, if I wanted to call you, using my proxy server for the first hop > (maybe because that is the only way I can get the call to go > through the MCI > Worldcom firewall) I can send the following INVITE request to my proxy. > Note that my user agent may be configured to send all requests to the > sip.wcom.com proxy, or I may on a call-by-call basis decide where to send > the request. > > Calling UA ---------------------> Proxy > srd@srd.wcom.com sip.wcom.com > > INVITE sip:lili@ss8networks.com SIP/2.0 > Via: SIP/2.0/UDP srd.wcom.com > From: sip:srd@srd.wcom.com > To: sip:lili@ss8networks.com > callid: 1234@srd.wcom.com > Cseq: 1 INVITE > > In this case the proxy is providing the service to the calling > user. If the > proxy doesn't know anything about lili@ss8networks.com then it would proxy > the request to the ss8networks.com host, in this case assumed to > be a proxy, > but it could be your end device. > > Proxy ---------------------> Proxy > sip.wcom.com ss8networks.com > > INVITE sip:lili@ss8networks.com SIP/2.0 > Via: SIP/2.0/UDP sip.wcom.com;branch=xyz > Via: SIP/2.0/UDP srd.wcom.com > From: sip:srd@srd.wcom.com > To: sip:lili@ss8networks.com > callid: 1234@srd.wcom.com > Cseq: 1 INVITE > > Note that the request uri doesn't change, just the destination for the > message. > > It is also possible that the proxy is also providing a service to > the called > user, in which case it may change the request uri before sending it to the > next hop. > > It would probably be helpful to add a scenario like this to the call flow > document. > > Steve > > -----Original Message----- > > From: Li Li [mailto:lili@ss8networks.com] > > Sent: Tuesday, April 04, 2000 9:08 PM > > To: Johnston, Alan > > Cc: Jonathan Rosenberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: questions on rfc2543bis > > > > > > > > > > > > > > I thought your question might have been based on the use of > > > Request-URI in the > > > Call Flows draft. > > > > Yes. Alan, my misunderstanding was exactly resulted from there. > > > > > > I think the Request-URIs in the draft were formulated based on > > > the (mistaken?) > > > idea that the host portion of the Request-URI should map to the > > > IP address of > > > the proxy or server (the entity to which the request was sent). > > > > > > For example, in 3.1.2 on page 25 of > > > draft-ietf-sip-call-flows-00.txt, message F4 > > > has the INVITE Request-URI of UserB@ss1.wcom.com but the To > > > header contains > > > UserB@there.com where ss1.wcom.com is the Proxy Server. > > > > > > Should the Request-URI instead match the To header in this case? > > > > Always have the host portion of the Request-URI mapped to the > > IP address of the proxy or server may have a problem when there is > > a local proxy that handles many (or all) outgoing calls for a caller. > > Put Request-URI as UserB@wcom.com in this example may be better, > > my own take. Clearer to me. If proxy ss1 only handles calls to users > > in wcom.com, things may not be too bad if the INVITE message has > > Request-URI with ss1.wcom.com in the host portion. But say if > > the caller > > also wants to call somebody outside of wcom.com but should > > access through > > the > > wcom's ss1 proxy for all his services. If in this case the > > caller UAC gets > > all the destinations in the world mapped to a unique name@ss1.wcom.com > > in the Request-URI in the INVITE message, we'd have problems > > of too many > > mappings to handle for ss1.wcom.com. Of course, probably user > > A can send his > > different calls directly to different proxy servers of the destination > > carrier's > > network, which I don't know if it is the case. > > > > li li > > > > > > Alan Johnston > > > MCI WorldCom > > > > > > Li Li wrote: > > > > > > > > > > > > > > > > Thanks for pointing/confirming about the unique name > > space. Then if > > > > > > there is a "somebody@mciworldcom.com" and a > > > "somebody@bellcanada.com", > > > > > > the proxy server needs to configure two names as > > > somebody1@foo.com and > > > > > > somebody2@foo.com to send the call to different > > called destinations? > > > > > > > > > > You've lost me. If I call somebody@mciworldcom.com and > > > > > somebody@bellcanada.com, those will go to two different > > proxies (or > > > > > possibly the same proxy doing virtual hosting). If those map to > > > > > different people, then the outgoing URIs will be different. > > > > > > > > I see the problem I have is thst from all the call flow > > examples in the > > > > call flow draft, the INVITE message always have > > user@proxydomain in the > > > > Request-URI and the Request-URI changes all the time from proxy > > > to proxy. > > > > For example, if the INVITE goes through proxy ss1.mciworld.com and > > > > ss2.mciworld.com. The Request-URI in the INVITE message > > is shown as > > > > bigguy@ss1.mciworldcom.com and then changed to > > > bigguy@ss2.mciworldcom.com. > > > > Should the caller UAC just send in Request-URI > > bigguy@mciworldcom.com to > > > > SS1 proxy. The SS1 does a look up and know that SS2 handles > > > > bigguy@mciworldcom.com > > > > and proxy it to SS2? Otherwise, as in the draft, it implies to me > > > > that everyone in the mciworld.com also should have a > > unique name in the > > > > ss1.mciworldcom.com so that SS1 can handle it. > > > > That leads me to think that when an INVITE is sent to a proxy, > > > it should use > > > > the proxy's host name in the host part of the Request-URI. But > > > as what you > > > > pointed out here, really the Request-URI should be the > > destination > > > > user@host > > > > and is sent to the proxy of the destination domain. > > > > Thanks for your help. Very much apprecaited. > > > > > > > > li li > > > > > > > > > > > > > > > So > > > > > > the proxy server should not serve too many different > > > destination domains > > > > > > as this would make the name management impossible to give them > > > > > all different > > > > > > names in the proxy's domain. Is this right? > > > > > > > > > > No, of course not. Why is this a problem? The proxy is > > serving many > > > > > domains, as you say. To me, this means it handles requests for > > > > > domain1.com, domain2.com, etc. You also seem to imply > > that these are > > > > > mapped into a single namespace in the "proxy's domain". > > I don't follow > > > > > that. If it receives a call for user1@domain1.com, it checks > > > its tables > > > > > for domain1.com, and finds that this is mapped to > > user_1@foo.com, and > > > > > sends it out to foo.com. Not all incoming request get mapped > > > to foo.com. > > > > > For those that do, its up to foo.com to properly manage their > > > namespace. > > > > > > > > > > -Jonathan R. > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > > (732) 741-4778 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (732) 741-7244 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/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 Apr 6 10:39: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 KAA09143 for ; Thu, 6 Apr 2000 10:39: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 A099944337; Thu, 6 Apr 2000 10:37:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.mera.ru (FireWall.mera.ru [195.98.50.58]) by lists.bell-labs.com (Postfix) with ESMTP id 803DD44336 for ; Thu, 6 Apr 2000 10:37:34 -0400 (EDT) Received: from abc (abc.mera.ru [195.98.57.251]) by mail.mera.ru (8.9.3/8.9.3) with SMTP id SAA91370 for ; Thu, 6 Apr 2000 18:39:11 +0400 (MSD) Message-ID: <019c01bf9fd7$9aa51b80$fb3962c3@mera.ru> From: "Alexei Prokofiev" To: References: <75C79E507864D3118AFC00805FEAB7D83493C7@ripexch001.mcit.com> <38EB62C6.98DB8900@dynamicsoft.com> Date: Thu, 6 Apr 2000 18:51:30 +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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: [SIP] Re: Several TCP connections for the same SIP transaction Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, in case replies are sent by a server UA via several TCP connections (for example, a new connection is created for each message) close out of which of the connetions must be treated by a client UA as CANCEL in case the transaction is not complete? Thanks a lot! ----------- Alexei Prokofiev, mailto:palx@null.net Software Engeneer, Mera Labs. ----- Original Message ----- From: Jonathan Rosenberg To: Alexei Prokofiev Cc: sip ; ; Sent: Tuesday, March 07, 2000 9:06 PM Subject: Re: Several TCP connections for the same SIP transaction > It depends on how forgiving your client is. A server is supposed to send > responses on the same connection the requests came from, if that > connection is still open. If the client closes the connection before the > response comes, the server should CANCEL. If, by chance, the CANCEL and > the actual final response pass on the wire, the server is supposed to > open a connection to the client to send the response. Sooo, a client > will already need to handle incoming connections for responses, but only > in this specific case. If a server opens a new connection to send a > response, and the initial one is still open, the server has erred. What > the client does (handle this or not) is at its discretion. Handling this > may be easy since it already needs to deal with a similar case. > > -Jonathan R. > > > Alexei Prokofiev wrote: > > > > Hi, > > > > should a client UA accept replies of a transaction in case they are > > sent > > by a server UA via several TCP connections different from the one used > > to send the request of the transaction? > > > > Thanks a lot! > > > > ----------- > > Alexei Prokofiev, mailto:palx@null.net > > Software Engeneer, > > Mera Labs. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Apr 6 11:35: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 LAA09982 for ; Thu, 6 Apr 2000 11:35: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 8CD0544336; Thu, 6 Apr 2000 11:33:25 -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 1A99D44336 for ; Wed, 5 Apr 2000 17:58:25 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Apr 5 17:58:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 20E3A44344; Wed, 5 Apr 2000 17:45:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E9F9E44341 for ; Wed, 5 Apr 2000 17:45:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AD8C152BB; Wed, 5 Apr 2000 17:45:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BEEAB52B6 for ; Wed, 5 Apr 2000 17:45:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Apr 5 17:44:27 EDT 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Apr 5 17:44:27 EDT 2000 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FSK007BICDWRY@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 5 Apr 2000 21:44:20 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSK00001CDV4Q@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 21:44:19 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FSK00L9ACDVP1@dgismtp01.wcomnet.com>; Wed, 05 Apr 2000 21:44:19 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id <2LSFSPLC>; Wed, 05 Apr 2000 21:44:19 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 21:44:15 +0000 From: "Donovan, Steven R." To: "'Jonathan Rosenberg'" Cc: sip@lists.research.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D83493D3@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=ISO-8859-1 Subject: [SIP] RE: Comment on draft-ietf-sip-isup-mime-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: X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote: > > > "Donovan, Steven R." wrote: > > > > One quick comment on the security section of this draft. I > agree that it is > > true that the security section in SIP that discusses > end-to-end encryption > > of the SIP message body should be sufficient to meet the > security concerns > > associated with carrying ISUP and QSIG message bodies. > > > > I would, however, suggest that the following be added to the spec: > > > > "Due to the potentially sensitive nature of the information > contained in > > ISUP and QSIG message bodies, the UAC SHOULD perform > end-to-end encryption > > on ISUP and QSIG message bodies." > > Lets be careful here. It depends on the application of SIP-T. > For single > provider networks among a set of softswitches, its easy to > manage keys > in such a way that e2e encryption is possible. For > multi-provider, wide > area operation, e2e encryption is harder, and I'm reluctant to make it > SHOULD. It requires the originator to know the key of the ultimate > recipient before sending the request. Since the entity the > request will > terminate on can't always be known ahead of time (due to forwarding or > routing to a remote gateway), this requirement is overly strong. > I don't know, there are some pretty serious regulatory issues involved. I'm almost inclined to say that SHOULD is to weak and that if the encryption key information is not available then the ISUP information SHOULD NOT be included in the SIP message. This doesn't break the call, it just weakens the interoperability between the SIP and PSTN networks. All of the information necessary for the call to be re-originated from the SIP network to the PSTN exists in the SIP headers. The only loss is some of the information carried in the ISUP message (caller id, reason codes, etc.). This is analogous to interoperability between an SS7 ISUP network and a CAS network, where information is lost when the call is handed off to the CAS network. The calls still work, just with a limited set of features. If it is absolutely necessary to include the ISUP for all call related features to work then the calling gateway can insist on use of the security pre-condition mechanism defined in the manyfolks draft. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Apr 6 11:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10000 for ; Thu, 6 Apr 2000 11:36:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9937D4433D; Thu, 6 Apr 2000 11:33:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 62A9C44336 for ; Wed, 5 Apr 2000 12:58:57 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA23895; Wed, 5 Apr 2000 17:58:36 +0100 (BST) Message-ID: <38EB7016.60A50D85@ubiquity.net> Date: Wed, 05 Apr 2000 17:55:50 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP Digest Authentication 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: X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, rfc2617.txt HTTP Authentication : Basic & Digest Access Authentication, section 3.2.2.3, refers to H(entity-body), when calculating A2 if the QOP value is "auth-int". 3.2.2.4 goes on to describe H(entity-body) as the hash of the entity body, not the message body..... rfc2543 doesn't appear to elaborate on this! Can someone please describe or point me towards some information describing what constitutes the entity-body of a SIP message? An example would also be useful! Thanks In Advance Phil Hoffer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Apr 6 11:37:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10033 for ; Thu, 6 Apr 2000 11:37:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E948244344; Thu, 6 Apr 2000 11:33:32 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id BEE7444336 for ; Wed, 5 Apr 2000 03:50:29 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 5 03:50:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2965844344; Wed, 5 Apr 2000 03:37:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 013C844341 for ; Wed, 5 Apr 2000 03:37:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B7FE552BB; Wed, 5 Apr 2000 03:37:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EC9A852B6 for ; Wed, 5 Apr 2000 03:37:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Apr 5 03:35:39 EDT 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Apr 5 03:35:38 EDT 2000 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FSJ00CFR93D8D@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 5 Apr 2000 07:35:37 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00H0193D2A@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 07:35:37 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FSJ00F3S93CQS@pmismtp01.wcomnet.com>; Wed, 05 Apr 2000 07:35:37 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id ; Wed, 05 Apr 2000 07:35:36 +0000 Content-return: allowed Date: Wed, 05 Apr 2000 07:35:35 +0000 From: "Donovan, Steven R." To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: "'Anders Kristensen'" , SIP Message-id: <75C79E507864D3118AFC00805FEAB7D83493C5@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset=iso-8859-1 Subject: [SIP] RE: Session timer 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: X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > > > > > > The only way for a proxy to insure that it will be a > part of all requests is > > > > to insert the Record-Route header into all requests, > even those that have a > > > > Route header. > > > > > > I think this may cause interop problems. Much as I'd like > to add this, > > > it means any old proxy that doesn't insert REcord-Route > is going to get > > > booted off the signaling path. That seems like a problem. > > > > Is this a practical problem? How many proxy servers that implement > > Route/Record-Route couldn't be trained to do that? Also, I > believe this > > has been discussed since the first bake-off or thereabouts, so most > > implementors should have seen this. > > We can take a poll at the bakeoff, but I'm sure there are > implementations that won't be there... > There was a practical reason that this was added that I can't reconstruct at the moment (I know I've had white board discussions with Robert Sparks on this one). I'll dig through my notes and the list archive to see if I can figure it out. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Apr 6 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 LAA10111 for ; Thu, 6 Apr 2000 11:40: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 CAEFC4434C; Thu, 6 Apr 2000 11:33:37 -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 24C3044336 for ; Tue, 4 Apr 2000 20:44:05 -0400 (EDT) Received: from vovida.com (pool0250.cvx21-bradley.dialup.earthlink.net [209.179.192.250]) by repulse.cnchost.com id UAA04112; Tue, 4 Apr 2000 20:45:32 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <38EAABA8.1F905F20@vovida.com> Date: Tue, 04 Apr 2000 19:57:45 -0700 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Content-Type: multipart/alternative; boundary="------------B2253A19A66A1F5475E2CB16" Subject: [SIP] Question on ACKs for responses > 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: X-BeenThere: sip@lists.bell-labs.com --------------B2253A19A66A1F5475E2CB16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For ACKS, it is given that the ACK request Uri is based on the Route (if any), else the Contact(if any) else the To field of the 200 response. Does this hold good for all other responses, such as > 200 status codes.(because the record route makes sense only for 200 ) The reason for this question is: Consider a situation such as: endpt A --INVITE----> proxy A ----INVITE--> proxy B----> endpt B. endpt B ---4xx----> proxy B and proxy B ---ACKs---> endpt B and this continues to endpt A. Here, how does proxy B know endpt B's address to send it an ACK. Thanks! -- Sunitha Kumar Software Engineer Vovida Networks (408) 383-1076 --------------B2253A19A66A1F5475E2CB16 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
For ACKS, it is given that the ACK request Uri is based on the Route (if any), else the Contact(if any)
else the To field of the 200 response.



Does this hold good for all other responses, such as > 200 status codes.(because the



record route makes sense only for 200 )



The reason for this question is:



Consider a situation such as:






endpt A --INVITE----> proxy A ----INVITE--> proxy B----> endpt B.






endpt B ---4xx----> proxy B  and proxy B ---ACKs---> endpt B and this continues to endpt A.



Here, how does proxy B know endpt B's address to send it an ACK.









Thanks!



-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 383-1076

 

--------------B2253A19A66A1F5475E2CB16--




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


From sip-admin@lists.bell-labs.com  Thu Apr  6 11: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 LAA10140
	for ; Thu, 6 Apr 2000 11:43:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 34E994434E; Thu,  6 Apr 2000 11:33:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74])
	by lists.bell-labs.com (Postfix) with ESMTP id BE8F644336
	for ; Tue,  4 Apr 2000 18:46:05 -0400 (EDT)
Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226])
	by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id RAA05281
	for ; Tue, 4 Apr 2000 17:34:16 -0500
Message-ID: <38EA6F80.999D86FE@ipunity.com>
Date: Tue, 04 Apr 2000 15:41:04 -0700
From: jimmy Zhang 
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/alternative;
 boundary="------------7E1A59F91FDD5CC35AC998F5"
Subject: [SIP] payload description
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


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


hi,

    I would like to know if there exists a standard way to describe the
payload size  of the RTP stream. So for instance,

10, 20, 30 ms.  We've read the sip spec, but could not find it.

--

Jimmy zhang (jz@ipunity.com)

Software Engineer



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



 

hi,

    I would like to know if there exists a standard way
to describe the payload size  of the RTP stream. So for instance,

10, 20, 30 ms.  We've read the sip spec, but could not find it.

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer

 

--------------7E1A59F91FDD5CC35AC998F5--




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


From sip-admin@lists.bell-labs.com  Thu Apr  6 11:59: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 LAA10259
	for ; Thu, 6 Apr 2000 11:59: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 8DE3444353; Thu,  6 Apr 2000 11:57:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.mera.ru (FireWall.mera.ru [195.98.50.58])
	by lists.bell-labs.com (Postfix) with ESMTP id 50D0E44339
	for ; Thu,  6 Apr 2000 11:57:29 -0400 (EDT)
Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12])
	by mail.mera.ru (8.9.3/8.9.3) with ESMTP id TAA95217;
	Thu, 6 Apr 2000 19:59:09 +0400 (MSD)
Date: Thu, 6 Apr 2000 20:00:36 +0400
From: "Stanislav S. Timinsky" 
X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational
Reply-To: "Stanislav S. Timinsky" 
Organization: MERA Labs.
X-Priority: 3 (Normal)
Message-ID: <15833.000406@mera.ru>
To: jimmy Zhang 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] payload description
In-reply-To: <38EA6F80.999D86FE@ipunity.com>
References: <38EA6F80.999D86FE@ipunity.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hello jimmy,

Wednesday, April 05, 2000, 2:41:04 AM, you wrote:


jimmy Zhang> hi,

jimmy Zhang>     I would like to know if there exists a standard way to describe the
jimmy Zhang> payload size  of the RTP stream. So for instance,

jimmy Zhang> 10, 20, 30 ms.  We've read the sip spec, but could not find it.

jimmy Zhang> --

jimmy Zhang> Jimmy zhang (jz@ipunity.com)

jimmy Zhang> Software Engineer


I think, You may use the attribute parameter in SDP (rfc-2327, page 22).

   a=ptime:
     This gives the length of time in milliseconds represented by the
     media in a packet.
       
-- 
Best regards,
 Stanislav S. Timinsky                      mailto:timinsky@mera.ru
 Mera Labs.




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


From sip-admin@lists.bell-labs.com  Thu Apr  6 12:05:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10371
	for ; Thu, 6 Apr 2000 12:05:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 69D4944344; Thu,  6 Apr 2000 12:04:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4A87444339
	for ; Thu,  6 Apr 2000 12:04:12 -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 MAA04756
	for ; Thu, 6 Apr 2000 12:07:07 -0400 (EDT)
Message-ID: <38ECB540.A6261D26@dynamicsoft.com>
Date: Thu, 06 Apr 2000 12:03:12 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP Digest Authentication Clarification
References: <38EB7016.60A50D85@ubiquity.net>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

"Message body" and "entity body" are synonymous in SIP. Here is a quote
from sec. 3 of the RFC2543 that uses the terms interchangeably:

Both Request (section 4) and Response (section 5) messages use the
   generic-message format of RFC 822 [24] for transferring entities (the
   body of the message). Both types of messages consist of a start-line,
   one or more header fields (also known as "headers"), an empty line
   (i.e., a line with nothing preceding the carriage-return line-feed
   (CRLF)) indicating the end of the header fields, and an optional
   message-body. To avoid confusion with similar-named headers in HTTP,
   we refer to the headers describing the message body as entity
   headers.

---
Igor Slepchin


Phil Hoffer wrote:
> 
> Hi,
> 
> rfc2617.txt HTTP Authentication : Basic & Digest Access Authentication,
section 3.2.2.3,
> refers to H(entity-body), when calculating A2 if the QOP value is
"auth-int".
> 
> 3.2.2.4 goes on to describe H(entity-body) as the hash of the entity body,
not the
> message body.....
> 
> rfc2543 doesn't appear to elaborate on this!
> 
> Can someone please describe or point me towards some information
describing
> what constitutes the entity-body of a SIP message?
> 
> An example would also be useful!
> 
> Thanks In Advance
> Phil Hoffer
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr  6 13:02:45 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11452
	for ; Thu, 6 Apr 2000 13:02: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 7A05F44338; Thu,  6 Apr 2000 13:00:58 -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 214FD44336
	for ; Thu,  6 Apr 2000 13:00:56 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id NAA91047; Thu, 6 Apr 2000 13:02:34 -0400 (EDT)
Message-ID: <015b01bf9fea$25429f30$3102a8c0@broadsoft.com>
From: "Brett Tate" 
To: "Sunitha Kumar" ,
        "SIPbell-labs" 
References: <38EAABA8.1F905F20@vovida.com>
Subject: Re: [SIP] Question on  ACKs for responses > 200
Date: Thu, 6 Apr 2000 13:04:17 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0158_01BF9FC8.9DB3B8E0"
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:  
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0158_01BF9FC8.9DB3B8E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My understanding concerning Acks for responses >=3D3xx:

- Set Request-URI based on Record-Route and Contact=20
  from the response if present.  They should only be=20
  present in certain situations and it indicates they want you to use =
it.=20
- Otherwise (based on section 10.5.1 in April 2000's=20
  draft-ietf-sip-rfc2543bis-00) use the same Request-URI that=20
  was used in the Invite. =20
- Could try location server next if not forking and think its=20
  worth the effort since it might not give the correct location. =20
- Only as a last resort, use the To field to set the Request-URI=20
  since it is most likely only ever correct for the original=20
  originator of the Invite.
  ----- Original Message -----=20
  From: Sunitha Kumar=20
  To: SIPbell-labs=20
  Sent: Tuesday, April 04, 2000 10:57 PM
  Subject: [SIP] Question on ACKs for responses > 200


For ACKS, it is given that the ACK request Uri is based on the Route (if =
any), else the Contact(if any)
else the To field of the 200 response.

Does this hold good for all other responses, such as > 200 status =
codes.(because the
record route makes sense only for 200 )
The reason for this question is:
Consider a situation such as:

endpt A --INVITE----> proxy A ----INVITE--> proxy B----> endpt B.

endpt B ---4xx----> proxy B  and proxy B ---ACKs---> endpt B and this =
continues to endpt A.
Here, how does proxy B know endpt B's address to send it an ACK.


Thanks!
--=20
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 383-1076
   =20

------=_NextPart_000_0158_01BF9FC8.9DB3B8E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









My understanding concerning Acks for responses=20
>=3D3xx:


 


- Set Request-URI based on Record-Route and=20
Contact 


  from the response if present.  They =
should only be=20



  present in certain situations and it =
indicates they=20
want you to use it. 


- Otherwise (based on section 10.5.1 in April 2000's =




  draft-ietf-sip-rfc2543bis-00) use=20
the same Request-URI that 


  was used in the =
Invite.  


- Could try location server next if not forking =
and think=20
its 


  worth the effort since it might not give the =
correct=20
location.  


- Only as a last resort, use the To field to set the =

Request-URI 


  since it is most likely only ever correct for =
the=20
original 


  originator of the=20
Invite.


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

  From:=20
  Sunitha =
Kumar=20
  

  
To: SIPbell-labs 

  
Sent: Tuesday, April 04, 2000 =
10:57=20
  PM

  
Subject: [SIP] Question on ACKs =
for=20
  responses > 200

  

For ACKS, it is given that the ACK request Uri is =
based on the Route (if any), else the Contact(if any)
else the =
To field of the 200 response.
Does this hold good =
for all other responses, such as > 200 status codes.(because =
the
record route makes sense only for 200 )
The =
reason for this question is:
Consider a situation such =
as:
endpt A --INVITE----> proxy A =
----INVITE--> proxy B----> endpt B.
endpt B =
---4xx----> proxy B  and proxy B ---ACKs---> endpt B and this =
continues to endpt A.
Here, how does proxy B know endpt B's =
address to send it an =
ACK.
Thanks!
-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 383-1076
  

------=_NextPart_000_0158_01BF9FC8.9DB3B8E0--



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


From sip-admin@lists.bell-labs.com  Thu Apr  6 15:22:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13434
	for ; Thu, 6 Apr 2000 15:22: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 9D06544337; Thu,  6 Apr 2000 15:21:05 -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 3AE2844336
	for ; Thu,  6 Apr 2000 15:21:03 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FSM00EJG0H7LP@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  6 Apr 2000 19:22:19 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSM00M010H6HF@dgismtp01.wcomnet.com>;
 Thu, 06 Apr 2000 19:22:19 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSM00L720H6ND@dgismtp01.wcomnet.com>; Thu,
 06 Apr 2000 19:22:18 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <2294LYF5>; Thu, 06 Apr 2000 19:22:17 +0000
Content-return: allowed
Date: Thu, 06 Apr 2000 19:22:16 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] Question on  ACKs for responses > 200
To: "'Sunitha Kumar'" ,
        SIPbell-labs 
Message-id: <75C79E507864D3118AFC00805FEAB7D83493DA@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_mEH3QcPUZyvlhOmPYKMWVQ)"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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.

--Boundary_(ID_mEH3QcPUZyvlhOmPYKMWVQ)
Content-type: text/plain; charset=ISO-8859-1

Sunitha,
 
The correct behavior for ACKs in the scenario you discuss is as follows:
 
A                       P1                        P2
B
INVITE--------------->
                           INVITE----------------->
 
INVITE--------------->
 
<--------------------4XX
 
ACK------------------->
                           <---------------------4XX
                           ACK-------------------->
<------------------- 4XX
ACK-------------------->
 
At each point, the ACK is sent to where the original request was sent.  Note
that P1 and P2 need to add a To tag when sending the response downstream to
know that the ACK was destined for them and not for B.
 
This is different then a 200 OK response, which looks like:
 
A                       P1                        P2
B
INVITE--------------->
                           INVITE----------------->
 
INVITE--------------->
 
<--------------------200
                           <---------------------200
<------------------- 200
ACK-------------------->
                           ACK-------------------->
 
ACK------------------->
 
In this case, the ACK is sent per the rules you mention (route if available,
etc.)
 
This is all fairly clearly described in section 10.5.1.
 
Steve
 

-----Original Message-----
From: Sunitha Kumar [mailto:skumar@vovida.com]
Sent: Tuesday, April 04, 2000 9:58 PM
To: SIPbell-labs
Subject: [SIP] Question on ACKs for responses > 200


For ACKS, it is given that the ACK request Uri is based on the Route (if
any), else the Contact(if any)
else the To field of the 200 response.

Does this hold good for all other responses, such as > 200 status
codes.(because the
record route makes sense only for 200 )
The reason for this question is:
Consider a situation such as:

endpt A --INVITE----> proxy A ----INVITE--> proxy B----> endpt B.

endpt B ---4xx----> proxy B  and proxy B ---ACKs---> endpt B and this
continues to endpt A.
Here, how does proxy B know endpt B's address to send it an ACK.


Thanks!
-- 

Sunitha Kumar

Software Engineer

Vovida Networks

(408) 383-1076
  


--Boundary_(ID_mEH3QcPUZyvlhOmPYKMWVQ)
Content-type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable









Sunitha,


 


The=20
correct behavior for ACKs in the scenario you discuss is as=20
follows:


 


A       &n=
bsp;           &n=
bsp;  =20
P1           &nbs=
p;           =20
P2           &nbs=
p;           =20
B


INVITE--------------->
=


       &nb=
sp;           &nb=
sp;      =20
INVITE----------------->


       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
INVITE--------------->


       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
<--------------------4XX


       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
ACK------------------->


       &nb=
sp;           &nb=
sp;      =20
<---------------------4XX


       &nb=
sp;           &nb=
sp;      =20
ACK-------------------->


<------------------- =
4XX


ACK-------------------->

 


At=20
each point, the ACK is sent to where the original request was =
sent.  Note=20
that P1 and P2 need to add a To tag when sending the response =
downstream to know=20
that the ACK was destined for them and not for B.


 


This=20
is different then a 200 OK response, which looks =
like:


 




A       &n=
bsp;           &n=
bsp;  =20
P1           &nbs=
p;           =20
P2           &nbs=
p;           =20
B


INVITE--------------->
=


       &nb=
sp;           &nb=
sp;      =20
INVITE----------------->


       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
INVITE--------------->


       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
<--------------------200


       &nb=
sp;           &nb=
sp;      =20
<---------------------200


<------------------- =
200


ACK-------------------->



       &nb=
sp;           &nb=
sp;      =20
ACK-------------------->




       &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;           =20
ACK------------------->


 


In=20
this case, the ACK is sent per the rules you mention (route if =
available,=20
etc.)


 


This=20
is all fairly clearly described in section 10.5.1.


 


Steve


 


  
-----Original Message-----
From: Sunitha Kumar=20
  [mailto:skumar@vovida.com]
Sent: Tuesday, April 04, 2000 =
9:58=20
  PM
To: SIPbell-labs
Subject: [SIP] Question on =
ACKs for=20
  responses > 200

For ACKS, it is given =
that the ACK request Uri is based on the Route (if any), else the =
Contact(if any)
else the To field of the 200 =
response.
Does this hold good for all other =
responses, such as > 200 status codes.(because the
record =
route makes sense only for 200 )
The reason for this question =
is:
Consider a situation such as:
endpt =
A --INVITE----> proxy A ----INVITE--> proxy B----> endpt =
B.
endpt B ---4xx----> proxy B  and proxy =
B ---ACKs---> endpt B and this continues to endpt A.
Here, =
how does proxy B know endpt B's address to send it an =
ACK.
Thanks!
-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 383-1076
  

--Boundary_(ID_mEH3QcPUZyvlhOmPYKMWVQ)--


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


From sip-admin@lists.bell-labs.com  Thu Apr  6 16:59: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 QAA14617
	for ; Thu, 6 Apr 2000 16:59: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 F2A6144337; Thu,  6 Apr 2000 16:57:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by lists.bell-labs.com (Postfix) with ESMTP id 7C83D44336
	for ; Thu,  6 Apr 2000 16:57:24 -0400 (EDT)
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA03290
	for ; Thu, 6 Apr 2000 23:58:57 +0300 (EETDST)
From: Eric.Cooper@nokia.com
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA06558
	for ; Thu, 6 Apr 2000 23:58:56 +0300 (EETDST)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0)
	id ; Thu, 6 Apr 2000 15:57:47 -0500
Message-ID: 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Question on  ACKs for responses > 200
Date: Thu, 6 Apr 2000 15:57:02 -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:  
X-BeenThere: sip@lists.bell-labs.com

Given the message flow shown below, and assuming that P1and P2 are stateless
UDP proxies, how would reliability be assured?
 
A                       P1                        P2
B
INVITE--------------->
                           INVITE----------------->
 
INVITE--------------->
 
<--------------------4XX
 
ACK------------------->
                           <---------------------4XX
                           ACK-------------------->
<------------------- 4XX
ACK-------------------->
 
----
Eric Cooper
eric.cooper@nokia.com  
(613) 271-6805


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


From sip-admin@lists.bell-labs.com  Thu Apr  6 17:32: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 RAA15264
	for ; Thu, 6 Apr 2000 17:32:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B3FD4433C; Thu,  6 Apr 2000 17:30:40 -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 3512644336
	for ; Thu,  6 Apr 2000 17:30:38 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FSM0087O6HYG8@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  6 Apr 2000 21:32:22 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSM00C016HXVJ@dgismtp01.wcomnet.com>;
 Thu, 06 Apr 2000 21:32:22 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSM00C6Z6HX2O@dgismtp01.wcomnet.com>; Thu,
 06 Apr 2000 21:32:21 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <2294L9K4>; Thu, 06 Apr 2000 21:32:20 +0000
Content-return: allowed
Date: Thu, 06 Apr 2000 21:32:19 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] Question on  ACKs for responses > 200
To: "'Eric.Cooper@nokia.com'" , sip@lists.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D83493DB@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

This flow does not apply to stateless proxies.  As stated in section 12.3 of
the RFC:

"...a stateless proxy forwards every request it
   receives downstream, and every response it receives upstream."

Thus the stateless proxy does not send the ACK.

I'm not sure I understand your question on reliability.

Steve

> -----Original Message-----
> From: Eric.Cooper@nokia.com [mailto:Eric.Cooper@nokia.com]
> Sent: Thursday, April 06, 2000 3:57 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Question on ACKs for responses > 200
> 
> 
> Given the message flow shown below, and assuming that P1and 
> P2 are stateless
> UDP proxies, how would reliability be assured?
>  
> A                       P1                        P2
> B
> INVITE--------------->
>                            INVITE----------------->
>  
> INVITE--------------->
>  
> <--------------------4XX
>  
> ACK------------------->
>                            <---------------------4XX
>                            ACK-------------------->
> <------------------- 4XX
> ACK-------------------->
>  
> ----
> Eric Cooper
> eric.cooper@nokia.com  
> (613) 271-6805
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr  6 17:33: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 RAA15300
	for ; Thu, 6 Apr 2000 17:33:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F255344345; Thu,  6 Apr 2000 17:30:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lists.bell-labs.com (Postfix) with ESMTP id D2E3044336
	for ; Thu,  6 Apr 2000 17:30:51 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA15024 for ; Thu, 6 Apr 2000 14:32:36 -0700 (MST)]
Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA22910 for <  sip@lists.bell-labs.com>; Thu, 6 Apr 2000 14:32:36 -0700 (MST)]
Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 6 Apr 2000 16:32:36 -0500
Message-ID: 
From: Lohrbach Jeff-CJL002 
To: "'SIP List'" 
Date: Thu, 6 Apr 2000 16:32:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [SIP] Questions about SIP support for gateways connected to PBX's
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

I'm looking into the development of an IP telephony system.  In particular,
I'm looking into the development of something like a PC-based key telephony
system in which user agents can access the PSTN or analog PBX extensions via
a gateway.  Each PC can monitor one or more of the PBX extensions/PSTN
telephone lines offered by the gateway, and each extension/PSTN line may be
monitored by one or more PC (We don't necessarily want to be able to dial
down to each individual computer.).  SIP seems like it can handle this at
the feature level, but I'm now at the point where I have some questions
about accessing the PSTN or a PBX via a gateway.  I'm hoping some of you can
help me.


1. Most PBX's allow access to their features (forwarding, transfer, etc.)
over analog lines through a hook-flash/DTMF sequence.  Does SIP support
this?  I haven't seen any information in the SIP drafts about supporting a
hook-flash as a digit, and I'm wondering if this (allowing the user agents
to control PBX features on the analog lines that are terminated by the
gateway) is supported by SIP in some way.

2. I have a related question about generating individual DTMF digits.
Assuming I'm using a gateway that can generate DTMF tones (probably a safe
assumption), does SIP support a means of instructing the gateway to insert
DTMF tones into an active call's audio?  This would be useful for the
previously-mentioned access of PBX features.  It would also be useful for
accessing systems with automated voice response or automated attendants.  My
reading of the drafts leads me to believe that this can be done (by sending
additional INVITE messages with the same Call ID and with
incrementally-longer digit strings), but I'd like to see my novice
interpretation of the draft confirmed by someone with more experience.  
     If I'm correct in thinking that this method allows the dialing of
individual digits, does that mean that overlap dialing is also supported by
SIP?  If my hunch is wrong and SIP doesn't support overlap dialing, does SIP
provide a way for me to open a call through the gateway without sending any
PSTN/PBX address digits (just to get dial-tone from the PBX or PSTN) so that
I can then generate digits locally and send them in the audio stream (not an
ideal solution if audio coding with lower bit-rates is used, but possibly
useful for my needs)?  

Thanks for your help!


Jeff Lohrbach
Jeff.Lohrbach@motorola.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 Apr  7 03: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 DAA03991
	for ; Fri, 7 Apr 2000 03:05: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 CEBE144337; Fri,  7 Apr 2000 03:03:55 -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 9133D44336
	for ; Fri,  7 Apr 2000 03:03:53 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2JR0J6HA>; Fri, 7 Apr 2000 00:06:09 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'sip@lists.bell-labs.com'" 
Date: Fri, 7 Apr 2000 00:06:01 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] 405 vs 501 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:  
X-BeenThere: sip@lists.bell-labs.com


I noticed in the Bake-off client classification form that there is an item:

"reject unknown request methods with 405 response"

I was under the impression that you respond to unknown methods with a 501
Not implemented response and the 405 response should only be sent if the
request is recognized but disallowed.

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 Apr  7 08:28: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 IAA06750
	for ; Fri, 7 Apr 2000 08:28: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 EE4AE44337; Fri,  7 Apr 2000 08:26:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by lists.bell-labs.com (Postfix) with ESMTP id E41F444336
	for ; Fri,  7 Apr 2000 08:26:37 -0400 (EDT)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id OAA14531 for ; Fri, 7 Apr 2000 14:27:24 +0200 (MET DST)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id OAA15997 for ; Fri, 7 Apr 2000 14:26:41 +0200 (MET DST)
Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id OAA14804
	for ; Fri, 7 Apr 2000 14:26:50 +0200 (MET DST)
Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it
          (Netscape Messaging Server 3.0)  with ESMTP id AAA17958
          for ; Fri, 7 Apr 2000 14:35:22 +0200
Message-ID: <38EDCF2A.8DBD05F4@italtel.it>
Date: Fri, 07 Apr 2000 14:06:03 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/alternative;
 boundary="------------B016D1017BF90389E39B4866"
Subject: [SIP] State-of-the art on SIP QOS and security
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


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

Hi,

I' ve heard lots of people and I' ve read many documents (including the
excellent draft presented by Henry in Adealaide)  about QOS in
SIP-signaled networks, as well as about security (encryption of
signalling messages, at least).

Nevertheless I' ve not been able to find any official SIP drafts
tackling these issues: can anyone bief me about the state-of-the-art in
these two areas ?


   * did I miss some relevant WG document
   * or is it an explicit desire by the WG not to restrict the number of
     QOS mechanisms that can be utilized by implementors
   * or is it just a matter of time and we will have something like an
     informational RCF with a taxonomy of possible QOS
     methods/suggestions on how the various policy-based mechanisms can
     be coupled with SIP?

What about security ?

Thank you very much,
and apologies in advance, should this issue have already been
exetensively discussed by the list
Giuseppe Ricagni



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



Hi,

I' ve heard lots of people and I' ve read many documents (including
the excellent draft presented by Henry in Adealaide)  about QOS in
SIP-signaled networks, as well as about security (encryption of signalling
messages, at least).

Nevertheless I' ve not been able to find any official SIP drafts tackling
these issues: can anyone bief me about the state-of-the-art in these two
areas ?

 

    

  • 
did I miss some relevant WG document
    • 


  • 
or is it an explicit desire by the WG not to restrict the number of QOS
mechanisms that can be utilized by implementors
    • 


  • 
or is it just a matter of time and we will have something like an informational
RCF with a taxonomy of possible QOS methods/suggestions on how the various
policy-based mechanisms can be coupled with SIP?
    • 





What about security ?

Thank you very much,

and apologies in advance, should this issue have already been exetensively
discussed by the list

Giuseppe Ricagni

 

--------------B016D1017BF90389E39B4866--





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


From sip-admin@lists.bell-labs.com  Fri Apr  7 08:37: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 IAA06895
	for ; Fri, 7 Apr 2000 08:37:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EEE6544343; Fri,  7 Apr 2000 08:35:08 -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 E902C4433C
	for ; Fri,  7 Apr 2000 08:35:04 -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 IAA10461;
	Fri, 7 Apr 2000 08:36:44 -0400 (EDT)
Message-ID: <38EDD6A0.38A7C845@cs.columbia.edu>
Date: Fri, 07 Apr 2000 08:37: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: "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] 405 vs 501 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Typo.

"Fairlie-Cuninghame, Robert" wrote:
> 
> I noticed in the Bake-off client classification form that there is an item:
> 
> "reject unknown request methods with 405 response"
> 
> I was under the impression that you respond to unknown methods with a 501
> Not implemented response and the 405 response should only be sent if the
> request is recognized but disallowed.
>


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


From sip-admin@lists.bell-labs.com  Fri Apr  7 09:04: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 JAA07323
	for ; Fri, 7 Apr 2000 09:04: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 BF15144338; Fri,  7 Apr 2000 09:02:48 -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 02E2F44336
	for ; Fri,  7 Apr 2000 09:02:46 -0400 (EDT)
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA06176;
	Fri, 7 Apr 2000 16:04:31 +0300 (EETDST)
From: Eric.Cooper@nokia.com
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183])
	by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA02746;
	Fri, 7 Apr 2000 16:04:28 +0300 (EETDST)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id ; Fri, 7 Apr 2000 08:04:27 -0500
Message-ID: 
To: Steven.R.Donovan@wcom.com, sip@lists.bell-labs.com
Subject: RE: [SIP] Question on  ACKs for responses > 200
Date: Fri, 7 Apr 2000 08:02:33 -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:  
X-BeenThere: sip@lists.bell-labs.com

I apologize for the formatting problem in the previous message, but it seems
like the question was understood.

If UDP proxies do not send ACKs, then that clears it up for me.
I was reading section 4.2.2: 

2xx responses are acknowledged by client user agents, all other final
responses by the first proxy or client user agent to receive the response.

It sounds like that only applies to TCP proxies.

Although it's moot now, I was wondering about the reliability of the 4XX on
it's way back to A.  If it were ACKed by P2, and lost between P2 and P1, or
P1 and A, then I figured that the INVITE would be have to be retransmitted
by A, which didn't seem correct.

Thanks for clarifying.

Eric.

-----Original Message-----
From: EXT Donovan, Steven R. [mailto:Steven.R.Donovan@wcom.com]
Sent: Thursday, April 06, 2000 5:32 PM
To: 'Eric.Cooper@nokia.com'; sip@lists.bell-labs.com
Subject: RE: [SIP] Question on ACKs for responses > 200


This flow does not apply to stateless proxies.  As stated in section 12.3 of
the RFC:

"...a stateless proxy forwards every request it
   receives downstream, and every response it receives upstream."

Thus the stateless proxy does not send the ACK.

I'm not sure I understand your question on reliability.

Steve

> -----Original Message-----
> From: Eric.Cooper@nokia.com [mailto:Eric.Cooper@nokia.com]
> Sent: Thursday, April 06, 2000 3:57 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Question on ACKs for responses > 200
> 
> 
> Given the message flow shown below, and assuming that P1and 
> P2 are stateless
> UDP proxies, how would reliability be assured?
>  
> A                       P1                        P2 	 	B
> INVITE--------------->
>                            INVITE----------------->
>					INVITE--------------->
>  
>					 <--------------------4XX
> 					ACK------------------->
>                            <---------------------4XX
>                            ACK-------------------->
> <------------------- 4XX
> ACK-------------------->
>  
> ----
> Eric Cooper
> eric.cooper@nokia.com  
> (613) 271-6805
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr  7 09:40:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08021
	for ; Fri, 7 Apr 2000 09:40: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 213EA44338; Fri,  7 Apr 2000 09:38:09 -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 A49DF44336
	for ; Fri,  7 Apr 2000 09:38:06 -0400 (EDT)
Received: from fokus.gmd.de (jobe [193.175.132.219])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA06456
	for ; Fri, 7 Apr 2000 15:38:26 +0200 (MET DST)
Message-ID: <38EDE527.5D0D15F6@fokus.gmd.de>
Date: Fri, 07 Apr 2000 15:39:51 +0200
From: Jiri Kuthan 
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Subject: Re: [SIP] State-of-the art on SIP QOS and security
References: <38EDCF2A.8DBD05F4@italtel.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Yes, the intention is to keep specific QoS mechanisms
apart from call signaling. The I-D draft-manyfolks-sip-resource-00.txt
desribes how QoS preconditions (regardless of QoS mechanism
being used) can be signaled with SIP/SDP. QoS mechanism
themselves are out of scope of SIP WG.

The I-D draft-sinnreich-interdomain-sip-qos-osp-01.txt is of 
informational nature and documents how to put all the pieces 
(SIP call signaling, RSVP QoS reservation, COPS Policy,
OSP settlement) in a complex commercial service provisioning 
environment together.

Jiri

Giuseppe Ricagni wrote:
> 
> Hi,
> 
> I' ve heard lots of people and I' ve read many documents (including
> the excellent draft presented by Henry in Adealaide)  about QOS in
> SIP-signaled networks, as well as about security (encryption of
> signalling messages, at least).
> 
> Nevertheless I' ve not been able to find any official SIP drafts
> tackling these issues: can anyone bief me about the state-of-the-art
> in these two areas ?
> 
> 
>    * did I miss some relevant WG document
>    * or is it an explicit desire by the WG not to restrict the number
>      of QOS mechanisms that can be utilized by implementors
>    * or is it just a matter of time and we will have something like an
>      informational RCF with a taxonomy of possible QOS
>      methods/suggestions on how the various policy-based mechanisms
>      can be coupled with SIP?
> 
> What about security ?
> 
> Thank you very much,
> and apologies in advance, should this issue have already been
> exetensively discussed by the list
> Giuseppe Ricagni
> 
> 

-- 
Jiri Kuthan		  Phone: +(49) / 30 - 3463 7 271
GMD FOKUS                 Fax  : +(49) / 30 - 3463 8 271
Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan


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


From sip-admin@lists.bell-labs.com  Fri Apr  7 09:55: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 JAA08329
	for ; Fri, 7 Apr 2000 09:55: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 E2BB644338; Fri,  7 Apr 2000 09:53:44 -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 DA24E44336
	for ; Thu,  6 Apr 2000 18:30:16 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr  6 18:31:32 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 78F7944346; Thu,  6 Apr 2000 18:17:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 5359C44341
	for ; Thu,  6 Apr 2000 18:17:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 247D052BB; Thu,  6 Apr 2000 18:17:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 35E4952B6
	for ; Thu,  6 Apr 2000 18:17:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Apr  6 18:16:36 EDT 2000
Received: from howler.tri.sbc.com ([205.173.58.4]) by dusty; Thu Apr  6 18:16:35 EDT 2000
Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10])
	by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA27354
	for ; Thu, 6 Apr 2000 17:18:13 -0500 (CDT)
Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227])
	by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA27358
	for ; Thu, 6 Apr 2000 17:16:03 -0500 (CDT)
Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0)
	id <142AB51A>; Thu, 6 Apr 2000 17:16:02 -0500
Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790A0@trimail2.tri.sbc.com>
From: "Schroeder, Tim" 
To: sip@lists.research.bell-labs.com
Subject: RE: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt
Date: Thu, 6 Apr 2000 17:16:01 -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:  
X-BeenThere: sip@lists.bell-labs.com

Donovan, Steven R. [mailto:Steven.R.Donovan@wcom.com] writes:
> I don't know, there are some pretty serious regulatory issues involved.
I'm
> almost inclined to say that SHOULD is to weak and that if the encryption
key
> information is not available then the ISUP information SHOULD NOT be
> included in the SIP message.

I agree with this.  The ISUP information must be treated as very sensitive,
by regulation (at least in the US).

Tim Schroeder
SBC Technology Resources



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


From sip-admin@lists.bell-labs.com  Fri Apr  7 09:56: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 JAA08342
	for ; Fri, 7 Apr 2000 09:56: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 8F71F44344; Fri,  7 Apr 2000 09:53:48 -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 8FAC044336
	for ; Fri,  7 Apr 2000 05:46:13 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr  7 05:46:23 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 245AD44344; Fri,  7 Apr 2000 05:33:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 8136944341
	for ; Fri,  7 Apr 2000 05:33:12 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id BFEB652BB; Fri,  7 Apr 2000 05:33:10 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7DD2D52AB
	for ; Fri,  7 Apr 2000 05:33:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Apr  7 05:32:16 EDT 2000
Received: from mex.italtel.it ([138.132.117.4]) by dusty; Fri Apr  7 05:32:15 EDT 2000
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id LAA00728 for ; Fri, 7 Apr 2000 11:31:30 +0200 (MET DST)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id LAA01880 for ; Fri, 7 Apr 2000 11:30:45 +0200 (MET DST)
Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id LAA16283
	for ; Fri, 7 Apr 2000 11:30:54 +0200 (MET DST)
Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it
          (Netscape Messaging Server 3.0)  with ESMTP id AAA15189
          for ;
          Fri, 7 Apr 2000 11:39:25 +0200
Message-ID: <38EDABC8.398C67CE@italtel.it>
Date: Fri, 07 Apr 2000 11:35:05 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sip list 
Content-Type: multipart/alternative;
 boundary="------------0F79731677EF6DC7EEBF3ADF"
Subject: [SIP] State-of-the art on SIP QOS and security
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


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

Hi,

I' ve heard lots of people and I' ve read many documents (including the
excellent draft presented by Henry in Adealaide)  about QOS in
SIP-signaled networks, as well as about security (encryption of
signalling messages, at least).

Nevertheless I' ve not been able to find any official SIP drafts
tackling these issues: can anyone bief me about the state-of-the-art in
these two areas ?


   * did I miss some relevant WG document
   * or is it an explicit desire by the WG not to restrict the number of
     QOS mechanisms that can be utilized by implementors
   * or is it just a matter of time and we will have something like an
     informational RCF with a taxonomy of possible QOS
     methods/suggestions on how the various policy-based mechanisms can
     be coupled with SIP?

What about security ?

Thank you very much,
and apologies in advance, should this issue have already been
exetensively discussed by the list
Giuseppe Ricagni



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



Hi,

I' ve heard lots of people and I' ve read many documents (including
the excellent draft presented by Henry in Adealaide)  about QOS in
SIP-signaled networks, as well as about security (encryption of signalling
messages, at least).

Nevertheless I' ve not been able to find any official SIP drafts tackling
these issues: can anyone bief me about the state-of-the-art in these two
areas ?

 

    

  • 
did I miss some relevant WG document
    • 


  • 
or is it an explicit desire by the WG not to restrict the number of QOS
mechanisms that can be utilized by implementors
    • 


  • 
or is it just a matter of time and we will have something like an informational
RCF with a taxonomy of possible QOS methods/suggestions on how the various
policy-based mechanisms can be coupled with SIP?
    • 





What about security ?

Thank you very much,

and apologies in advance, should this issue have already been exetensively
discussed by the list

Giuseppe Ricagni

 

 

--------------0F79731677EF6DC7EEBF3ADF--




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


From sip-admin@lists.bell-labs.com  Fri Apr  7 09:58:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08368
	for ; Fri, 7 Apr 2000 09:58:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 152944434B; Fri,  7 Apr 2000 09:53:52 -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 8BD8344336
	for ; Fri,  7 Apr 2000 06:44:12 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr  7 06:44:20 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id E471F44344; Fri,  7 Apr 2000 06:31:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 5514944341
	for ; Fri,  7 Apr 2000 06:31:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 207A452BB; Fri,  7 Apr 2000 06:31:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4F96252B6
	for ; Fri,  7 Apr 2000 06:31:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Apr  7 06:29:56 EDT 2000
Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Fri Apr  7 06:29:55 EDT 2000
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Fri, 7 Apr 2000 05:12:26 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <2MBQ0TJJ>; Fri, 7 Apr 2000 05:12:23 -0500
Message-ID: <2E532B03F035D3119AF40000F80932C32073B4@crchy28d.us.nortel.com>
From: "William Lee" 
To: "'Fairlie-Cuninghame, Robert'" 
Cc: sip@lists.research.bell-labs.com
Subject: RE: [SIP] 405 vs 501 response.
Date: Fri, 7 Apr 2000 05:11:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA079.C445DAA4"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFA079.C445DAA4
Content-Type: text/plain

According to the spec, you are correct.  The server should respond with a
501.

	"The server does not support the functionality required to fulfill
the request. This
	is the appropriate response when the server does not recognize the
request method
	and is not capable of supporting if for any user."

Bill

> -----Original Message-----
> From:	Fairlie-Cuninghame, Robert [SMTP:rfairlie@nuera.com]
> Sent:	Friday, April 07, 2000 2:06 AM
> To:	'sip@lists.bell-labs.com'
> Subject:	[SIP] 405 vs 501 response.
> 
> 
> I noticed in the Bake-off client classification form that there is an
> item:
> 
> "reject unknown request methods with 405 response"
> 
> I was under the impression that you respond to unknown methods with a 501
> Not implemented response and the 405 response should only be sent if the
> request is recognized but disallowed.
> 
> Robert.
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFA079.C445DAA4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] 405 vs 501 response.




According to the =
spec, you are correct.  The server should respond with a =
501.




        "The server does not support the =
functionality required to fulfill the request. This

        is the appropriate response when the server =
does not recognize the request method

        and is not capable of supporting if for any =
user."




Bill



    

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

    From:   Fairlie-Cuninghame, Robert =
[SMTP:rfairlie@nuera.com]

    Sent:   Friday, April 07, 2000 2:06 AM

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

    Subject:       =
 [SIP] 405 vs 501 response.

    

    


    I noticed in the Bake-off client =
classification form that there is an item:

    


    "reject unknown request methods =
with 405 response"

    


    I was under the impression that you =
respond to unknown methods with a 501

    Not implemented response and the 405 =
response should only be sent if the

    request is recognized but =
disallowed.

    


    Robert.

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFA079.C445DAA4--



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


From sip-admin@lists.bell-labs.com  Fri Apr  7 09:59: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 JAA08394
	for ; Fri, 7 Apr 2000 09:59: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 EB00844350; Fri,  7 Apr 2000 09:53:54 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 641F744336
	for ; Thu,  6 Apr 2000 13:10:19 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr  6 13:10:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 2D05644344; Thu,  6 Apr 2000 12:57:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 05ECA44341
	for ; Thu,  6 Apr 2000 12:57:10 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id BCCD852BB; Thu,  6 Apr 2000 12:57:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D90A552AB
	for ; Thu,  6 Apr 2000 12:57:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Apr  6 12:56:05 EDT 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Apr  6 12:56:05 EDT 2000
Received: from vovida.com (pool0752.cvx21-bradley.dialup.earthlink.net [209.179.194.242])
	by repulse.cnchost.com
	id MAA19895; Thu, 6 Apr 2000 12:55:58 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38ECC19D.2A269C96@vovida.com>
Date: Thu, 06 Apr 2000 09:55:57 -0700
From: Krishan Veer 
Organization: Vovida Networks
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Reg: Field "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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi Everyone,

I think the Grammer in rfc 2543 for "TO" field say that :
TO = ("TO" | "t") ":" (name-addr | addr-spec) *(";" addr-params)

questions:

1. Is there any limit for the character length in name-addr|addr-spec ?
2. there can be 0 or more addr-params -> (we can have multiple tags ? in
same "TO" ) is some thing worng with grammer here ?

Thanks : )
--
Krishan veer
Software Engineer
http://www.vovida.com






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


From sip-admin@lists.bell-labs.com  Fri Apr  7 11:14:02 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10127
	for ; Fri, 7 Apr 2000 11:14:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5021744337; Fri,  7 Apr 2000 11:12:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 3FBA744336
	for ; Fri,  7 Apr 2000 11:12:05 -0400 (EDT)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id RAA29544 for ; Fri, 7 Apr 2000 17:13:10 +0200 (MET DST)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id RAA01221 for ; Fri, 7 Apr 2000 17:12:27 +0200 (MET DST)
Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id RAA14671
	for ; Fri, 7 Apr 2000 17:12:37 +0200 (MET DST)
Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it
          (Netscape Messaging Server 3.0)  with ESMTP id AAA20854;
          Fri, 7 Apr 2000 17:21:08 +0200
Message-ID: <38EDFBDB.46D560A4@italtel.it>
Date: Fri, 07 Apr 2000 17:16:45 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] State-of-the art on SIP QOS and security
References: <38EDCF2A.8DBD05F4@italtel.it> <38EDE527.5D0D15F6@fokus.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jiri Kuthan wrote:

> Yes, the intention is to keep specific QoS mechanisms
> apart from call signaling. The I-D draft-manyfolks-sip-resource-00.txt
> desribes how QoS preconditions (regardless of QoS mechanism
> being used) can be signaled with SIP/SDP. QoS mechanism
> themselves are out of scope of SIP WG.
>

well, draft-manyfolks-sip-resource-00.txt doesn' t seem to me to be an
official WG I-D anyway.
So I would conclude that the WG is not even  interested in specifying  the
preconditions necessary for QOS mechanism to be applied to SIP-based
networks.

There's still some missing piece, or at least something I don' t understand,
in this picture, since it seems to me that previous discussions have clearly
shown how QOS handling appears to be the real driving force behind an
operator deploying a SIP-based network (without QOS there appear to be
little reason to have equipment in the core of the network: endpoints can
use SIP to call each other e2e)


Do you know anything about the security issue ? (signalling encryption)

Thank you very much
Giuseppe



>
> Giuseppe Ricagni wrote:
> >
> > Hi,
> >
> > I' ve heard lots of people and I' ve read many documents (including
> > the excellent draft presented by Henry in Adealaide)  about QOS in
> > SIP-signaled networks, as well as about security (encryption of
> > signalling messages, at least).
> >
> > Nevertheless I' ve not been able to find any official SIP drafts
> > tackling these issues: can anyone bief me about the state-of-the-art
> > in these two areas ?
> >
> >
> >    * did I miss some relevant WG document
> >    * or is it an explicit desire by the WG not to restrict the number
> >      of QOS mechanisms that can be utilized by implementors
> >    * or is it just a matter of time and we will have something like an
> >      informational RCF with a taxonomy of possible QOS
> >      methods/suggestions on how the various policy-based mechanisms
> >      can be coupled with SIP?
> >
> > What about security ?
> >
> > Thank you very much,
> > and apologies in advance, should this issue have already been
> > exetensively discussed by the list
> > Giuseppe Ricagni
> >
> >
>
> --
> Jiri Kuthan               Phone: +(49) / 30 - 3463 7 271
> GMD FOKUS                 Fax  : +(49) / 30 - 3463 8 271
> Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de
> D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr  7 12:48: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 MAA12101
	for ; Fri, 7 Apr 2000 12: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 2AFEA4433A; Fri,  7 Apr 2000 12:46:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id AD18444336
	for ; Fri,  7 Apr 2000 12:46:16 -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 MAA07782;
	Fri, 7 Apr 2000 12:49:17 -0400 (EDT)
Message-ID: <38EE10C3.62EE484D@dynamicsoft.com>
Date: Fri, 07 Apr 2000 12:45:55 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Eric.Cooper@nokia.com
Cc: Steven.R.Donovan@wcom.com, sip@lists.bell-labs.com
Subject: Re: [SIP] Question on  ACKs for responses > 200
References: 
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Eric.Cooper@nokia.com wrote:
> 
> I apologize for the formatting problem in the previous message, but it seems
> like the question was understood.
> 
> If UDP proxies do not send ACKs, then that clears it up for me.

_Stateless_ UDP proxies do not send ACKs, stateful do. Note that
stateless proxies cannot generate responses of their own as well, they
just proxy responses according to the Via header.
 
> Although it's moot now, I was wondering about the reliability of the 4XX on
> it's way back to A.  If it were ACKed by P2, and lost between P2 and P1, or
> P1 and A, then I figured that the INVITE would be have to be retransmitted
> by A, which didn't seem correct.

Assuming you refer to the picture from your previous message and P1 and
P2 are stateless, no ACKs will be generated by either P1 or P2.  In this
situation, UAC A and UAS B will provide reliability so the ACK
effectively becomes end to end. The correct diagram follows:

A                       P1                        P2                   
B
INVITE--------------->
                         INVITE----------------->
                                                  INVITE--------------->
                                                
<--------------------4XX
                          <---------------------4XX
<------------------- 4XX
ACK-------------------->
                         ACK-------------------->
                                                 
ACK------------------->

---
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 Apr  7 12:49: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 MAA12202
	for ; Fri, 7 Apr 2000 12:49: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 5835444349; Fri,  7 Apr 2000 12:48:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id BBDDA44348
	for ; Fri,  7 Apr 2000 12:47:58 -0400 (EDT)
Received: from fokus.gmd.de (jobe [193.175.132.219])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA23819;
	Fri, 7 Apr 2000 18:48:16 +0200 (MET DST)
Message-ID: <38EE11A5.39FFFAC8@fokus.gmd.de>
Date: Fri, 07 Apr 2000 18:49:41 +0200
From: Jiri Kuthan 
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Giuseppe Ricagni 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] State-of-the art on SIP QOS and security
References: <38EDCF2A.8DBD05F4@italtel.it> <38EDE527.5D0D15F6@fokus.gmd.de> <38EDFBDB.46D560A4@italtel.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


> Do you know anything about the security issue ? (signalling encryption)
> 
> Thank you very much
> Giuseppe
> 

There are two kinds of signaling encryption: end-to-end and hop-by-hop.

E2E is difficult if a SIP proxy in the middle of signaling chain
needs to know a particular message element for call processing.
RFC2543 introduces these header field classes: those which 
1) MUST NOT  be encrypted 2) MAY be encrypted 3) SHOULD be encrypted.

In fact, a caller never knows which of the fields really MAY be
encrypted because a SIP proxy in the middle may still want
to use a "MAY-be-encrypted" field for call processing logic.
The same applies also for SIP bodies. A proxy may want
to examine SDP payload in order to open pinholes in firewalls
or it possibly uses JPEGs in INVITEs to implement
"deny-calls-originating-from-skin-headed-callers" policy.

The most recent suggestion was to let caller encrypt whatever
he wants to and see if it works. If the encrypted message
encounters a SIP proxy which is unable to process it
the proxy sends an appropriate reply to the caller. The
reply may include some some hint on which parts of the message
were needed in plain text. Then, the caller will decide
if he wants to resend the message with indicated fields
in plain text or give up the call.

With HBH encryption, SIP messages are completely encrypted
but  all of the SIP entities along the signaling chain
see the messages (or part of them if E2E encrytion is
also used) in plain text. Which could make someone
who is concerned about privacy of his signaling worried.
To minimize the risk of disclosure of unencrypted signaling 
to untrusted proxies transitive HBH trust may be deployed.
Which means that SIP proxies forward HBH-encrypted SIP 
messages only to trusted adjacent proxies and assume they
will behave the same way.

With the exception of the proposal for "cannot process
encrypted fields" reply, all aforementioned issues are 
already addressed in the SIP RFC.

Jiri


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


From sip-admin@lists.bell-labs.com  Fri Apr  7 12:51:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12262
	for ; Fri, 7 Apr 2000 12:51:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5C02444357; Fri,  7 Apr 2000 12:48:41 -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 76AD344356
	for ; Fri,  7 Apr 2000 12:48:38 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 83E2A4CE0B; Fri,  7 Apr 2000 12:50:26 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA02217;
	Fri, 7 Apr 2000 12:50:25 -0400 (EDT)
Received: (from kkrama@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA04296;
	Fri, 7 Apr 2000 12:49:30 -0400 (EDT)
From: "K. K. Ramakrishnan" 
Message-Id: <1000407124930.ZM4294@windsor.research.att.com>
Date: Fri, 7 Apr 2000 12:49:30 -0400
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: giuseppe.ricagni@italtel.it, kuthan@fokus.gmd.de
Subject: Re: [SIP] State-of-the art on SIP QOS and security
Cc: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Giuseppe,
The I-D draft-manyfolks-sip-resource-00.txt
desribing how QoS preconditions can be signaled with SIP/SDP
is the result of multiple efforts that have been ongoing
among several people in the WG for a while now.

Several of us in the group are quite enthusiastic about it,
and think it will be very good for SIP in the future to
include the mechanisms and methods described in the draft.
It will also meet some of the critical requirements we have
as service providers too. My belief is that there is quite
a bit of support for the work.

It hasn't yet been included as part of a WG item probably because
a few issues (not-technical) need to be worked out. I hope these
will be overcome in the next few days/weeks and then we can help
progress it to a WG item, with consensus from people on the list
and the WG chairs.

Thanks,
       K. K. Ramakrishnan

-- 
K. K. Ramakrishnan                             Email:kkrama@research.att.com
AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
	URL: http://www.research.att.com/info/kkrama


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


From sip-admin@lists.bell-labs.com  Fri Apr  7 13:25: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 NAA13110
	for ; Fri, 7 Apr 2000 13:25: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 8911244336; Fri,  7 Apr 2000 13:23:42 -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 652DC44336
	for ; Fri,  7 Apr 2000 12:04:12 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr  7 12:04:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id C29CC44345; Fri,  7 Apr 2000 11:51:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 98D4444341
	for ; Fri,  7 Apr 2000 11:51:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 4D34752BB; Fri,  7 Apr 2000 11:51:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4045B52B6
	for ; Fri,  7 Apr 2000 11:51:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Apr  7 11:50:57 EDT 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Fri Apr  7 11:50:55 EDT 2000
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FSN00D1LLCUGR@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Fri,  7 Apr 2000 15:50:54 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FSN00101LCT2Q@pmismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Fri, 07 Apr 2000 15:50:53 +0000 (GMT)
Received: from omta4.mcit.com ([166.37.204.6])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FSN00JGKLCTUW@pmismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Fri, 07 Apr 2000 15:50:53 +0000 (GMT)
Received: from wcom.com ([166.33.132.111])
 by omta4.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000407155316.ETTL14395@wcom.com> for
 ; Fri, 07 Apr 2000 15:53:16 +0000
Date: Fri, 07 Apr 2000 10:51:38 -0500
From: Alan Johnston 
To: SIP 
Message-id: <38EE040A.7CF5E3B2@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Subject: [SIP] phone-context and 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Based on reports from Adelaide, it sounds like the consensus of the working
group was to progress the Call Flows I-D (draft-ietf-sip-call-flows-00.txt) to
Informational RFC as soon as possible.

One item that needs to be resolved first is the "phone-context" tag which is
used extensively in the Gateway dialing sections of the document for private
phone numbers (extensions).

In RFC2543, support for phone numbers in SIP URLs was included by including
parameters from the then current version of the Tel URL I-D if "user=phone" was
present.  Since then, there have been additional drafts of this document
(currently draft-antti-telephony-url-12.txt).

One of the critical additions to the Tel draft since RFC2543 was the addition of
the phone-context tag used for local numbers to identify the scope in which the
number is valid.  I believe this tag needs to be included in SIP URLs in the
next SIP draft.

For example, the U.S. directory assistance telephone number can be written in
global form as:

	sip:+1-314-555-1212@gateway.carrier.com;user=phone

However, if the number was only valid if dialed from within the U.S., the number
could be written as a local phone number as:

	sip:314-555-1212@gateway.carrier.com;phone-context=+1

Where the phone-context tag indicates that it is only valid from within country
code 1.

Another more compelling use of the phone-context tag is in dealing with private
numbers - numbers that are not part of the public number space, but are part of
a private numbering plan administered by a corporation or organization.  The
examples in the Call Flows document are of this kind:

	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier

In this example, it appears that the host portion (gateway address) of the URL
is sufficient to specify the context of the private number.  However, for cases
where a gateway is shared among multiple customers, each with possibly
overlapping private numbering plans, the use of phone-context is required:
	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier-customer1

The use of the phone-context tag also allows interdomain private dialing,
something impossible in todays PSTN.  For example, dialed digits for a
particular dialing plan could be sent to a proxy for gateway lookup

	sip:444-1000@proxy.wcom.com;phone-context=carrier-customer2

The proxy would lookup the gateway based on dialed digits and phone-context.  If
the proxy did not have gateway information for that carrier (domain), the
request could be proxied to that domain with the Request-URI becoming:

	sip:444-1000@proxy.carrier.com;phone-context=carrier-customer2

These are just a few examples of the use of this tag.

Are there any reasons why this tag should not be supported in SIP URLs in the
next draft of RFC2543?

Alan Johnston
MCI WorldCom



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


From sip-admin@lists.bell-labs.com  Fri Apr  7 13:41: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 NAA13434
	for ; Fri, 7 Apr 2000 13:40:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2A7AB44349; Fri,  7 Apr 2000 13:39:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id BFA7344336
	for ; Fri,  7 Apr 2000 13:39:02 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FSN00024QFXIR@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri,  7 Apr 2000 17:40:45 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSN00601QFX2Z@dgismtp01.wcomnet.com>;
 Fri, 07 Apr 2000 17:40:45 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSN0048LQFWQ0@dgismtp01.wcomnet.com>; Fri,
 07 Apr 2000 17:40:45 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <2294MVGK>; Fri, 07 Apr 2000 17:40:44 +0000
Content-return: allowed
Date: Fri, 07 Apr 2000 17:40:43 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] Question on  ACKs for responses > 200
To: "'Eric.Cooper@nokia.com'" , sip@lists.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D83493DD@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Eric,

"Stateless proxy" and "UDP proxy" are not synonymous terms.  A stateful
proxy can support UDP.  The only limitation with regards to TCP and UDP is
that a proxy that supports TCP for an individual request must be stateful
for that request.  

Steve

> -----Original Message-----
> From: Eric.Cooper@nokia.com [mailto:Eric.Cooper@nokia.com]
> Sent: Friday, April 07, 2000 8:03 AM
> To: Donovan, Steven R.; sip@lists.bell-labs.com
> Subject: RE: [SIP] Question on ACKs for responses > 200
> 
> 
> I apologize for the formatting problem in the previous 
> message, but it seems
> like the question was understood.
> 
> If UDP proxies do not send ACKs, then that clears it up for me.
> I was reading section 4.2.2: 
> 
> 2xx responses are acknowledged by client user agents, all other final
> responses by the first proxy or client user agent to receive 
> the response.
> 
> It sounds like that only applies to TCP proxies.
> 
> Although it's moot now, I was wondering about the reliability 
> of the 4XX on
> it's way back to A.  If it were ACKed by P2, and lost between 
> P2 and P1, or
> P1 and A, then I figured that the INVITE would be have to be 
> retransmitted
> by A, which didn't seem correct.
> 
> Thanks for clarifying.
> 
> Eric.
> 
> -----Original Message-----
> From: EXT Donovan, Steven R. [mailto:Steven.R.Donovan@wcom.com]
> Sent: Thursday, April 06, 2000 5:32 PM
> To: 'Eric.Cooper@nokia.com'; sip@lists.bell-labs.com
> Subject: RE: [SIP] Question on ACKs for responses > 200
> 
> 
> This flow does not apply to stateless proxies.  As stated in 
> section 12.3 of
> the RFC:
> 
> "...a stateless proxy forwards every request it
>    receives downstream, and every response it receives upstream."
> 
> Thus the stateless proxy does not send the ACK.
> 
> I'm not sure I understand your question on reliability.
> 
> Steve
> 
> > -----Original Message-----
> > From: Eric.Cooper@nokia.com [mailto:Eric.Cooper@nokia.com]
> > Sent: Thursday, April 06, 2000 3:57 PM
> > To: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Question on ACKs for responses > 200
> > 
> > 
> > Given the message flow shown below, and assuming that P1and 
> > P2 are stateless
> > UDP proxies, how would reliability be assured?
> >  
> > A                       P1                        P2 	
>  	B
> > INVITE--------------->
> >                            INVITE----------------->
> >					INVITE--------------->
> >  
> >					 <--------------------4XX
> > 					ACK------------------->
> >                            <---------------------4XX
> >                            ACK-------------------->
> > <------------------- 4XX
> > ACK-------------------->
> >  
> > ----
> > Eric Cooper
> > eric.cooper@nokia.com  
> > (613) 271-6805
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr  7 14:48:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15034
	for ; Fri, 7 Apr 2000 14:48:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BBA6444338; Fri,  7 Apr 2000 14:46:06 -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 7E9C044336
	for ; Fri,  7 Apr 2000 14:46:04 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FSN00A1ZTJVCZ@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri,  7 Apr 2000 18:47:56 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FSN00K01TJVON@pmismtp01.wcomnet.com>;
 Fri, 07 Apr 2000 18:47:55 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FSN00HAHTJUTW@pmismtp01.wcomnet.com>; Fri,
 07 Apr 2000 18:47:55 +0000 (GMT)
Received: from C25776A ([166.35.226.98])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000407184754.VHHT1695@C25776A>; Fri, 07 Apr 2000 18:47:54 +0000
Date: Fri, 07 Apr 2000 13:47:58 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] State-of-the art on SIP QOS and security
In-reply-to: <38EDFBDB.46D560A4@italtel.it>
To: Giuseppe Ricagni ,
        Jiri Kuthan 
Cc: sip@lists.bell-labs.com
Reply-To: henry.sinnreich@wcom.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Giuseppe,

I would like to add the responses from Jiri Kuthan and K. K.
Ramakrishnan regarding QoS that for AAA issues: There was
interest in the AAAArch BOF for AAA functions for areas such as
SIP where admission control is depending on application servers
(such as SIP proxies) and there can be more complex models, such
as "the called party pays and admits the call", also using
clearinghouses. There may be some model I-Ds on this topic.

Suggest you may want to attend the AAAARch session at the next
IETF.

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Giuseppe Ricagni
>Sent: Friday, April 07, 2000 10:17 AM
>To: Jiri Kuthan
>Cc: sip@lists.bell-labs.com
>Subject: Re: [SIP] State-of-the art on SIP QOS and security
>
>
>Jiri Kuthan wrote:
>
>> Yes, the intention is to keep specific QoS mechanisms
>> apart from call signaling. The I-D
>draft-manyfolks-sip-resource-00.txt
>> desribes how QoS preconditions (regardless of QoS mechanism
>> being used) can be signaled with SIP/SDP. QoS mechanism
>> themselves are out of scope of SIP WG.
>>
>
>well, draft-manyfolks-sip-resource-00.txt doesn' t
>seem to me to be an
>official WG I-D anyway.
>So I would conclude that the WG is not even
>interested in specifying  the
>preconditions necessary for QOS mechanism to be
>applied to SIP-based
>networks.
>
>There's still some missing piece, or at least
>something I don' t understand,
>in this picture, since it seems to me that previous
>discussions have clearly
>shown how QOS handling appears to be the real driving
>force behind an
>operator deploying a SIP-based network (without QOS
>there appear to be
>little reason to have equipment in the core of the
>network: endpoints can
>use SIP to call each other e2e)
>
>
>Do you know anything about the security issue ?
>(signalling encryption)
>
>Thank you very much
>Giuseppe
>
>
>
>>
>> Giuseppe Ricagni wrote:
>> >
>> > Hi,
>> >
>> > I' ve heard lots of people and I' ve read many
>documents (including
>> > the excellent draft presented by Henry in
>Adealaide)  about QOS in
>> > SIP-signaled networks, as well as about security
>(encryption of
>> > signalling messages, at least).
>> >
>> > Nevertheless I' ve not been able to find any
>official SIP drafts
>> > tackling these issues: can anyone bief me about
>the state-of-the-art
>> > in these two areas ?
>> >
>> >
>> >    * did I miss some relevant WG document
>> >    * or is it an explicit desire by the WG not to
>restrict the number
>> >      of QOS mechanisms that can be utilized by implementors
>> >    * or is it just a matter of time and we will
>have something like an
>> >      informational RCF with a taxonomy of possible QOS
>> >      methods/suggestions on how the various
>policy-based mechanisms
>> >      can be coupled with SIP?
>> >
>> > What about security ?
>> >
>> > Thank you very much,
>> > and apologies in advance, should this issue have
>already been
>> > exetensively discussed by the list
>> > Giuseppe Ricagni
>> >
>> >
>>
>> --
>> Jiri Kuthan               Phone: +(49) / 30 - 3463 7 271
>> GMD FOKUS                 Fax  : +(49) / 30 - 3463 8 271
>> Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de
>> D-10589 Berlin, Germany   WWW    :
http://www.fokus.gmd.de/usr/kuthan
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr  7 14:48: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 OAA15077
	for ; Fri, 7 Apr 2000 14:48: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 E74434434C; Fri,  7 Apr 2000 14:46:13 -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 4679044336
	for ; Fri,  7 Apr 2000 14:46:10 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id 96E0B4CE02
	for ; Fri,  7 Apr 2000 14:48:00 -0400 (EDT)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA10708
	for ; Fri, 7 Apr 2000 14:48:00 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id OAA18384
	for sip@lists.bell-labs.com; Fri, 7 Apr 2000 14:46:37 -0400 (EDT)
Date: Fri, 7 Apr 2000 14:46:37 -0400 (EDT)
Message-Id: <200004071846.OAA18384@fish-ha.research.att.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] phone-context and 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:  
X-BeenThere: sip@lists.bell-labs.com

I agree completely that there is a great need for phone-context.
Draft-dcsgroup-sip-proxy-proxy-01 made a simple suggestion that
Figure 4 in RFC2543 be updated with the current syntax from
draft-antti-telephony-uri-12, since it apparently came from
there to begin with.

Discussions in Adelaide seemed to focus on the question of
whether ";phone-context" appeared to the left of the "@"
or to the right of the "@".  To the left of the "@" there
are already defined some tags, such as "isub=" and "postd=",
so there is obviously not an issue with parsers.  

Making it part of the telephone-subscriber syntax seems cleaner
in that it avoids confusion in cases such as
	sip:somethingorother@gateway;phone-context=mycarrier
where the meaning isn't at all clear; whereas
	sip:somethingorother;phone-context=mycarrier@gateway
means the username has some strange characters in it, and
	sip:somethingorother;phone-context=mycarrier@gateway;user=phone
means to apply the telephony-subscriber syntax to the username.

BTW, our use of phone-context is to store the fact that LNP dip
was done, and the results.

Bill Marshall
wtm@research.att.com

-----original message-----
Date: Fri, 07 Apr 2000 10:51:38 -0500
From: Alan Johnston 
To: SIP 
Subject: [SIP] phone-context and RFC2543bis

Based on reports from Adelaide, it sounds like the consensus of the working
group was to progress the Call Flows I-D (draft-ietf-sip-call-flows-00.txt) to
Informational RFC as soon as possible.

One item that needs to be resolved first is the "phone-context" tag which is
used extensively in the Gateway dialing sections of the document for private
phone numbers (extensions).

In RFC2543, support for phone numbers in SIP URLs was included by including
parameters from the then current version of the Tel URL I-D if "user=phone" was
present.  Since then, there have been additional drafts of this document
(currently draft-antti-telephony-url-12.txt).

One of the critical additions to the Tel draft since RFC2543 was the addition of
the phone-context tag used for local numbers to identify the scope in which the
number is valid.  I believe this tag needs to be included in SIP URLs in the
next SIP draft.

For example, the U.S. directory assistance telephone number can be written in
global form as:

	sip:+1-314-555-1212@gateway.carrier.com;user=phone

However, if the number was only valid if dialed from within the U.S., the number
could be written as a local phone number as:

	sip:314-555-1212@gateway.carrier.com;phone-context=+1

Where the phone-context tag indicates that it is only valid from within country
code 1.

Another more compelling use of the phone-context tag is in dealing with private
numbers - numbers that are not part of the public number space, but are part of
a private numbering plan administered by a corporation or organization.  The
examples in the Call Flows document are of this kind:

	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier

In this example, it appears that the host portion (gateway address) of the URL
is sufficient to specify the context of the private number.  However, for cases
where a gateway is shared among multiple customers, each with possibly
overlapping private numbering plans, the use of phone-context is required:
	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier-customer1

The use of the phone-context tag also allows interdomain private dialing,
something impossible in todays PSTN.  For example, dialed digits for a
particular dialing plan could be sent to a proxy for gateway lookup

	sip:444-1000@proxy.wcom.com;phone-context=carrier-customer2

The proxy would lookup the gateway based on dialed digits and phone-context.  If
the proxy did not have gateway information for that carrier (domain), the
request could be proxied to that domain with the Request-URI becoming:

	sip:444-1000@proxy.carrier.com;phone-context=carrier-customer2

These are just a few examples of the use of this tag.

Are there any reasons why this tag should not be supported in SIP URLs in the
next draft of RFC2543?

Alan Johnston
MCI WorldCom



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr 10 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 IAA07471
	for ; Mon, 10 Apr 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 1C6E744338; Mon, 10 Apr 2000 08:27:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by lists.bell-labs.com (Postfix) with ESMTP id B8FB044336
	for ; Mon, 10 Apr 2000 08:27:38 -0400 (EDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA27824 for ; Mon, 10 Apr 2000 05:29:52 -0700 (PDT)
Message-Id: <4.3.1.2.20000410081613.00aeb9e0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 10 Apr 2000 08:27:08 -0400
To: sip@lists.bell-labs.com
From: Chip Sharp 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Carrying Q.BICC as an Mime-type 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:  
X-BeenThere: sip@lists.bell-labs.com

ITU (SG11) is currently defining a variant of ISUP that is being called 
"Bearer Independent Call Control" (BICC).  I'm sure many of you are aware 
of this.

They have completed work for Q.BICC to handle Narrowband ISDN services over 
ATM (this is now numbered Q.1901) and they are now beginning work on IP and 
other networks.

It seems that networks using SIP will have to interwork with these networks 
as well as the current PSTN that uses ISUP.

Could (or should) this be included in the SIP-T draft?  Would it be its own 
type or could/should it be included as a value for the version or spec field?

Chip
http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.			
------------------------------------------------------------------------



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


From sip-admin@lists.bell-labs.com  Mon Apr 10 09:04: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 JAA09180
	for ; Mon, 10 Apr 2000 09:04: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 359BB44336; Mon, 10 Apr 2000 09:02:17 -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 7AED844336
	for ; Mon, 10 Apr 2000 01:23:49 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 10 01:24:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 27AED44344; Mon, 10 Apr 2000 01:11:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id EB58F44341
	for ; Mon, 10 Apr 2000 01:11:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id AFA6852BB; Mon, 10 Apr 2000 01:11:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D969D52AB
	for ; Mon, 10 Apr 2000 01:11:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 10 01:10:55 EDT 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Apr 10 01:10:54 EDT 2000
Received: from dynamicsoft.com (1Cust247.tnt2.freehold.nj.da.uu.net [63.17.114.247])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09729;
	Mon, 10 Apr 2000 01:12:04 -0400 (EDT)
Message-ID: <38F16461.2B335BD@dynamicsoft.com>
Date: Mon, 10 Apr 2000 01:19:29 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R." 
Cc: sip@lists.research.bell-labs.com
References: <75C79E507864D3118AFC00805FEAB7D83493D3@ripexch001.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Comment on draft-ietf-sip-isup-mime-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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Donovan, Steven R." wrote:
> 

> > Lets be careful here. It depends on the application of SIP-T.
> > For single
> > provider networks among a set of  softswitches, its easy to
> > manage keys
> > in such a way that e2e encryption is possible. For
> > multi-provider, wide
> > area operation, e2e encryption is harder, and I'm reluctant to make it
> > SHOULD. It requires the originator to know the key of the ultimate
> > recipient before sending the request. Since the entity the
> > request will
> > terminate on can't always be known ahead of time (due to forwarding or
> > routing to a remote gateway), this requirement is overly strong.
> >
> 
> I don't know, there are some pretty serious regulatory issues involved.  I'm
> almost inclined to say that SHOULD is to weak and that if the encryption key
> information is not available then the ISUP information SHOULD NOT be
> included in the SIP message.
> 
> This doesn't break the call, it just weakens the interoperability between
> the SIP and PSTN networks.  All of the information necessary for the call to
> be re-originated from the SIP network to the PSTN exists in the SIP headers.
> The only loss is some of the information carried in the ISUP message (caller
> id, reason codes, etc.).  This is analogous to interoperability between an
> SS7 ISUP network and a CAS network, where information is lost when the call
> is handed off to the CAS network.  The calls still work, just with a limited
> set of features.

One of the premises we were aiming for with this work was that the
originating gateway did not need to know the terminating entity (gateway
or otherwise) before launching the call. If the terminating entity was a
gateway, the ISUP information could be used and transparency is
achieved. If the terminating entity was not a gateway, the ISUP is
ignored and everything still works. I still believe this to be a
valuable goal, and I'd like to consider other options besides abandoning
it.

My assumption is that the only sensitive information, per se, is the
calling name and number (at least as far as regulatory issues in the
PSTN go). Are there any others?

So, some possibilities:

1. We rely on hop by hop encryption. If the message hits a point where
the next hop is not over an encrypted transport, the sensitive
information (or the ISUP message in its entirety) is removed. This is
kind of bad, since the proxies then need to examine bodies.

2. Variant on (1); if the call hits a non-encrypted hop, an error is
generated, and the originating gateway relaunches the INVITE without
ISUP or with the sensitive information removed. We talked about this
during the security task force meeting - a caller preferences extension
that could request a proxy to reject the request if it crosses a trust
boundary.

3. The calling name and number are removed from the ISUP message (or set
to something innocuous), and the information is conveyed using the DCS
mechanisms for caller privacy.

Others?

> 
> If it is absolutely necessary to include the ISUP for all call related
> features to work then the calling gateway can insist on use of the security
> pre-condition mechanism defined in the manyfolks draft.

These preconditions are for security for the sessions (i.e., RTP), not
for SIP.

-Jonathan R.

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



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


From sip-admin@lists.bell-labs.com  Mon Apr 10 09:05: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 JAA09248
	for ; Mon, 10 Apr 2000 09:05: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 B7B3044343; Mon, 10 Apr 2000 09:03: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 87B3644336
	for ; Mon, 10 Apr 2000 07:47:48 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 10 07:48:20 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id F3DB844344; Mon, 10 Apr 2000 07:35:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id CA08244341
	for ; Mon, 10 Apr 2000 07:35:10 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 810B852BB; Mon, 10 Apr 2000 07:35:09 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9FFBD52AB
	for ; Mon, 10 Apr 2000 07:35:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 10 07:34:41 EDT 2000
Received: from ietf.org ([132.151.1.176]) by dusty; Mon Apr 10 07:34:41 EDT 2000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05566;
	Mon, 10 Apr 2000 07:34:39 -0400 (EDT)
Message-Id: <200004101134.HAA05566@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.research.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Mon, 10 Apr 2000 07:34:39 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-info-method-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:  
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-03.txt
	Pages		: 10
	Date		: 06-Apr-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-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-info-method-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-info-method-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:	<20000406142929.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-info-method-03.txt

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

Content-Type: text/plain
Content-ID:	<20000406142929.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 Apr 10 09:06: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 JAA09300
	for ; Mon, 10 Apr 2000 09: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 8D1BA44342; Mon, 10 Apr 2000 09:03:26 -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 7496C44340
	for ; Mon, 10 Apr 2000 08:29:47 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 10 08:30:17 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 0911544344; Mon, 10 Apr 2000 08:17:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id D2DD244341
	for ; Mon, 10 Apr 2000 08:17:07 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5399752BB; Mon, 10 Apr 2000 08:17:06 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 61BCD52B6
	for ; Mon, 10 Apr 2000 08:17:04 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 10 08:16:53 EDT 2000
Received: from mailman.cisco.com ([171.68.225.9]) by dusty; Mon Apr 10 08:16:52 EDT 2000
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA25557; Mon, 10 Apr 2000 05:16:47 -0700 (PDT)
Message-Id: <4.3.1.2.20000410080706.00ac45d0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 10 Apr 2000 08:15:22 -0400
To: "Donovan, Steven R." ,
        "'Jonathan Rosenberg'" 
From: Chip Sharp 
Subject: Re: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <75C79E507864D3118AFC00805FEAB7D83493D3@ripexch001.mcit.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:  
X-BeenThere: sip@lists.bell-labs.com

At 09:44 PM 4/5/00 +0000, Donovan, Steven R. wrote:
>Jonathan Rosenberg wrote:
> >
> >
> > "Donovan, Steven R." wrote:
> > >
> > > One quick comment on the security section of this draft.  I
> > agree that it is
> > > true that the security section in SIP that discusses
> > end-to-end encryption
> > > of the SIP message body should be sufficient to meet the
> > security concerns
> > > associated with carrying ISUP and QSIG message bodies.
> > >
> > > I would, however, suggest that the following be added to the spec:
> > >
> > > "Due to the potentially sensitive nature of the information
> > contained in
> > > ISUP and QSIG message bodies, the UAC SHOULD perform
> > end-to-end encryption
> > > on ISUP and QSIG message bodies."
> >
> > Lets be careful here. It depends on the application of SIP-T.
> > For single
> > provider networks among a set of  softswitches, its easy to
> > manage keys
> > in such a way that e2e encryption is possible. For
> > multi-provider, wide
> > area operation, e2e encryption is harder, and I'm reluctant to make it
> > SHOULD. It requires the originator to know the key of the ultimate
> > recipient before sending the request. Since the entity the
> > request will
> > terminate on can't always be known ahead of time (due to forwarding or
> > routing to a remote gateway), this requirement is overly strong.
> >
>
>I don't know, there are some pretty serious regulatory issues involved.  I'm
>almost inclined to say that SHOULD is to weak and that if the encryption key
>information is not available then the ISUP information SHOULD NOT be
>included in the SIP message.

I believe this may be too strong.  ISUP doesn't use end2end encryption 
today over the SS7 network which is essentially a connectionless packet 
network.  There is no reason to require end2end encryption for SIP-T when 
carrying ISUP over a similarly designed (in terms of security) IP network.

If a carrier doesn't want to carry ISUP in the clear over an IP network due 
to regulatory reasons, there is not reason it has to.  The carrier can 
require its vendors to provide the requisite features for this (such as you 
describe).

BTW, what (US) regulation covers security of ISUP?  I'd like to look it up.

Thanks,
Chip


>This doesn't break the call, it just weakens the interoperability between
>the SIP and PSTN networks.  All of the information necessary for the call to
>be re-originated from the SIP network to the PSTN exists in the SIP headers.
>The only loss is some of the information carried in the ISUP message (caller
>id, reason codes, etc.).  This is analogous to interoperability between an
>SS7 ISUP network and a CAS network, where information is lost when the call
>is handed off to the CAS network.  The calls still work, just with a limited
>set of features.
>
>If it is absolutely necessary to include the ISUP for all call related
>features to work then the calling gateway can insist on use of the security
>pre-condition mechanism defined in the manyfolks draft.
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.			
------------------------------------------------------------------------




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


From sip-admin@lists.bell-labs.com  Mon Apr 10 09: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 JAA09402
	for ; Mon, 10 Apr 2000 09:08: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 6198744352; Mon, 10 Apr 2000 09:06:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from felix.intertex.se (unknown [195.22.82.2])
	by lists.bell-labs.com (Postfix) with ESMTP id D38B244350
	for ; Mon, 10 Apr 2000 09:06:13 -0400 (EDT)
Message-Id: <4.3.1.0.20000410150556.00a76ae0@pop3.intertex.se>
X-Sender: anderscl@pop3.intertex.se
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 10 Apr 2000 15:08:35 +0200
To: sip@lists.bell-labs.com
From: Anders Clausen 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Key agreement using SIP/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:  
X-BeenThere: sip@lists.bell-labs.com

Hello,

We are two students writing on a graduate thesis about VoIP security
with SIP/SDP/RTP, with focus on encrypting the media stream. We are
new to this, and would be grateful for help on this subject.

There are some problems transferring or agreeing on a session
encryption key using the k= field in SDP, if one are to send it in a
SIP INVITE through a NAT. Since the NAT needs to change some fields in
the SDP description, the SDP must not be encrypted.

The end user should be oblivious of the FW/NAT and thus should neither
query it for the adresses to enter into the SDP, nor depend on the FW
to encrypt anything.

A couple of possible solutions (?).

The simplest (and least secure) way to transfer a symmetric key would
be that the caller enters his public key (or Diffie-Hellman "A") into
the k= field of the SDP.

"k=base64:"

together with a couple of attributes that could look something like

"a=key-encr-alg:RSA"
or
"a=key-encr-alg:D-H"

for describing the algorithm the key in the k= field corresponds to,
and

"a=media-encr-alg:3DES-CBC"

for describing preferred media encryption algorithm.

In case of RSA, the "callers key" is the public key, corresponding to
a private key only known by him. In case of Diffie-Hellman the
"callers key" is the "A"-part of the partly built media key.

The callee then generates a "callee key". In case of RSA, this is the
symmetric media key, encrypted using the callers public key. In case
of Diffie-Hellman, the "callee key" is the "B"-part of the partly
built symmetric media key. The callee sends this back in the k= field
in the SDP of the 180 response. Should the callee fail to meet the
specific security wishes of the caller, it could simply omit the k=
field in the response, and the caller could choose to proceed and not
encrypt the media or just hang up.

  CALLER		          SIP-PROXY(s)                   CALLEE
    |                           |                           |
    | INVITE w/SDP(caller's key)|                           |
    |-------------------------->| INVITE w/SDP(caller's key)|
    |                           |-------------------------->|
    |                           |                           |
    |                           |   100                     |
    |   100                     |<--------------------------|
    |<--------------------------|                      Key generation
    |                           |   180 w/SDP(callee's key) |
    |   180 w/SDP(callee's key) |<--------------------------|
    |<--------------------------|                           |

Another way could be to insert something similar to a TLS handshake
(or some other more secure way of agreeing on or transferring keys)
into the Reservation stage in the QoS/security negotiation described
in draft-manyfolks-sip-resource-00.txt.

This would probably also need a couple of attributes to tell the
callee which handshake protocol should be used.

Comments?

(After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
number of drafts, we have not found any solutions to the problems
described above.)

---
Anders Clausen 
Thomas Karlsson 



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


From sip-admin@lists.bell-labs.com  Mon Apr 10 12:54: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 MAA24557
	for ; Mon, 10 Apr 2000 12:54: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 26D1944341; Mon, 10 Apr 2000 12:52:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from daystrom.abatis-sys.com (unknown [216.13.164.98])
	by lists.bell-labs.com (Postfix) with ESMTP id A388744336
	for ; Mon, 10 Apr 2000 12:52:35 -0400 (EDT)
Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2448.0)
	id ; Mon, 10 Apr 2000 09:55:39 -0700
Message-ID: <811670B03A7DD211A2730008C709C20959F445@daystrom.abatissys.com>
From: "Li, Renwei" 
To: sip@lists.bell-labs.com
Date: Mon, 10 Apr 2000 09:54:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Seven & Eleven
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

In RFC 2543, there are two magic numbers: seven and eleven.

  Page 89:
          Retransmissions cease when the client has sent a total of ELEVEN
packets
 
  Page 91:
          or once it has sent a total of 7 request packets.

Is there any particular reasons for them? 

Thanks,

Renwei




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


From sip-admin@lists.bell-labs.com  Mon Apr 10 13:29:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26399
	for ; Mon, 10 Apr 2000 13:29: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 E7BCC44338; Mon, 10 Apr 2000 13:26: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 A2C9C44336
	for ; Mon, 10 Apr 2000 13:26:55 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA15393
	for ; Mon, 10 Apr 2000 13:29:08 -0400 (EDT)
Message-ID: <38F20F64.C34CF2AD@cs.columbia.edu>
Date: Mon, 10 Apr 2000 13:29:08 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Subject: Re: [SIP] Seven & Eleven
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

"Li, Renwei" wrote:
> 
> In RFC 2543, there are two magic numbers: seven and eleven.
> 
>   Page 89:
>           Retransmissions cease when the client has sent a total of ELEVEN
> packets
> 
>   Page 91:
>           or once it has sent a total of 7 request packets.
> 
> Is there any particular reasons for them?
> 

This is a secret, but a major U.S. convenience store chain is sponsoring
this work. They are into sips of slurpee and coffee, I gather. Other
numbers (e.g., for status codes) are still available for sponsorship.

The numbers were picked more-or-less arbitrarily, as a compromise
between the likely network failure rates, reasonable time-outs (i.e., if
you didn't get a response in that interval, somebody else will likely
lose patience anyway) and avoiding continuous flooding of the network.
-- 
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 Apr 10 13:34:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26787
	for ; Mon, 10 Apr 2000 13:34:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C6E5C4434A; Mon, 10 Apr 2000 13:32:27 -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 DCBA544337
	for ; Mon, 10 Apr 2000 13:32:24 -0400 (EDT)
Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Apr 2000 10:34:13 -0700 (Pacific Daylight Time)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58)
	id <2LZTDQ4G>; Mon, 10 Apr 2000 10:34:10 -0700
Message-ID: 
From: Christian Huitema 
To: "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Seven & Eleven
Date: Mon, 10 Apr 2000 10:34:03 -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:  
X-BeenThere: sip@lists.bell-labs.com

More seriously, there is a rationale way to determine when to stop
retransmitting. It has to do with the original value of the retransmission
timer, the exponential back-off and its 4 second cap, and the application
level timers in telephony gateways.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Monday, April 10, 2000 10:29 AM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Seven & Eleven
> 
> 
> "Li, Renwei" wrote:
> > 
> > In RFC 2543, there are two magic numbers: seven and eleven.
> > 
> >   Page 89:
> >           Retransmissions cease when the client has sent a 
> total of ELEVEN
> > packets
> > 
> >   Page 91:
> >           or once it has sent a total of 7 request packets.
> > 
> > Is there any particular reasons for them?
> > 
> 
> This is a secret, but a major U.S. convenience store chain is 
> sponsoring
> this work. They are into sips of slurpee and coffee, I gather. Other
> numbers (e.g., for status codes) are still available for sponsorship.
> 
> The numbers were picked more-or-less arbitrarily, as a compromise
> between the likely network failure rates, reasonable 
> time-outs (i.e., if
> you didn't get a response in that interval, somebody else will likely
> lose patience anyway) and avoiding continuous flooding of the network.
> -- 
> 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 Apr 10 15:49: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 PAA01730
	for ; Mon, 10 Apr 2000 15:49: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 DAB7C44337; Mon, 10 Apr 2000 15:47:20 -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 75C7B4434D
	for ; Mon, 10 Apr 2000 13:37:46 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 10 13:38:17 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 7170844344; Mon, 10 Apr 2000 13:25:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 49FF244341
	for ; Mon, 10 Apr 2000 13:25:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 0D81352BB; Mon, 10 Apr 2000 13:25:07 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 52C6952AB
	for ; Mon, 10 Apr 2000 13:25:04 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 10 13:24:26 EDT 2000
Received: from mail2.microsoft.com ([131.107.3.124]) by dusty; Mon Apr 10 13:24:25 EDT 2000
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Apr 2000 10:24:27 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58)
	id <2L5PTPP3>; Mon, 10 Apr 2000 10:24:26 -0700
Message-ID: 
From: Christian Huitema 
To: sip@lists.research.bell-labs.com
Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-info-method-03.txt
Date: Mon, 10 Apr 2000 10:24:25 -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:  
X-BeenThere: sip@lists.bell-labs.com

Would it be possible to explain in the draft exactly when to use the INFO
method and when to use the NOTIFY method defined in PINT?




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


From sip-admin@lists.bell-labs.com  Mon Apr 10 16:40:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03790
	for ; Mon, 10 Apr 2000 16:40: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 8414C44338; Mon, 10 Apr 2000 16:38:07 -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 264D244337
	for ; Mon, 10 Apr 2000 16:38:05 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FST006G6IR3YZ@firewall.mcit.com> for sip@lists.bell-labs.com;
 Mon, 10 Apr 2000 20:40:15 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FST00F01IR3UJ@dgismtp02.wcomnet.com>;
 Mon, 10 Apr 2000 20:40:15 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FST00F41IR25A@dgismtp02.wcomnet.com>; Mon,
 10 Apr 2000 20:40:15 +0000 (GMT)
Received: from dwillispc8 ([166.35.227.170])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000410204014.ESCK21369@dwillispc8>; Mon,
 10 Apr 2000 20:40:14 +0000
Date: Mon, 10 Apr 2000 15:39:20 -0500
From: Dean Willis 
Subject: RE: [SIP] State-of-the art on SIP QOS and security
In-reply-to: <1000407124930.ZM4294@windsor.research.att.com>
To: "K. K. Ramakrishnan" ,
        giuseppe.ricagni@italtel.it, kuthan@fokus.gmd.de
Cc: sip@lists.bell-labs.com
Message-id: <002701bfa32c$d9184c40$aae323a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


K. K. sums it up nicely. It is my personal hope to poll the WG on inclusion
of the manyfolks work as core WG activity once we get the RFC2026 stuff
worked out. I think it has fairly broad applicability.

--
Dean Willis
SIP WG co-chair.



> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of K. K. Ramakrishnan
> Sent: Friday, April 07, 2000 11:50 AM
> To: giuseppe.ricagni@italtel.it; kuthan@fokus.gmd.de
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] State-of-the art on SIP QOS and security
>
>
> Giuseppe,
> The I-D draft-manyfolks-sip-resource-00.txt
> desribing how QoS preconditions can be signaled with SIP/SDP
> is the result of multiple efforts that have been ongoing
> among several people in the WG for a while now.
>
> Several of us in the group are quite enthusiastic about it,
> and think it will be very good for SIP in the future to
> include the mechanisms and methods described in the draft.
> It will also meet some of the critical requirements we have
> as service providers too. My belief is that there is quite
> a bit of support for the work.
>
> It hasn't yet been included as part of a WG item probably because
> a few issues (not-technical) need to be worked out. I hope these
> will be overcome in the next few days/weeks and then we can help
> progress it to a WG item, with consensus from people on the list
> and the WG chairs.
>
> Thanks,
>        K. K. Ramakrishnan
>
> --
> K. K. Ramakrishnan
> Email:kkrama@research.att.com
> AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
> 180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
> 	URL: http://www.research.att.com/info/kkrama
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 11 10: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 KAA05735
	for ; Tue, 11 Apr 2000 10:22: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 DE8E544336; Tue, 11 Apr 2000 10:19:20 -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 A125644337
	for ; Mon, 10 Apr 2000 20:55:42 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 10 20:56:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id B3E9344344; Mon, 10 Apr 2000 20:43:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 7FDAE44341
	for ; Mon, 10 Apr 2000 20:43:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 37B9B52BB; Mon, 10 Apr 2000 20:43:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 71BAE52AB
	for ; Mon, 10 Apr 2000 20:43:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Apr 10 20:42:39 EDT 2000
Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Mon Apr 10 20:42:38 EDT 2000
Received: from ORANLT ([161.44.116.121]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id RAA17941; Mon, 10 Apr 2000 17:41:47 -0700 (PDT)
From: "David Oran" 
To: "Schroeder, Tim" ,
        
Subject: RE: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt
Date: Mon, 10 Apr 2000 20:41:40 -0400
Keywords: IETF
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: <4D45BA2A58A7D3119E050008C7E69E290790A0@trimail2.tri.sbc.com>
Importance: Normal
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Ok, I'll bite. What's so sensitive in ISUP that wouldn't be sensitive if
carried in SIP headers?

I think rather the issue is that ISUP assumes full transitive trust among
everybody and hence if you don't trust the next hop for everything there's
no way to "scrub" the ISUP body and hence you have to drop the whole
bag-o-bits.
Encryption just hides the sucker from eavesdroppping and modification by
intermediate baddies.

Right?

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Schroeder, Tim
> Sent: Thursday, April 06, 2000 6:16 PM
> To: sip@lists.research.bell-labs.com
> Subject: RE: [SIP] RE: Comment on draft-ietf-sip-isup-mime-00.txt
>
>
> Donovan, Steven R. [mailto:Steven.R.Donovan@wcom.com] writes:
> > I don't know, there are some pretty serious regulatory issues involved.
> I'm
> > almost inclined to say that SHOULD is to weak and that if the encryption
> key
> > information is not available then the ISUP information SHOULD NOT be
> > included in the SIP message.
>
> I agree with this.  The ISUP information must be treated as very
> sensitive,
> by regulation (at least in the US).
>
> Tim Schroeder
> SBC Technology Resources
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 11 10:38:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06579
	for ; Tue, 11 Apr 2000 10:38:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DD36C4433D; Tue, 11 Apr 2000 10:35:41 -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 8E98944336
	for ; Tue, 11 Apr 2000 10:35:39 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 11 10:36:20 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id B904444344; Tue, 11 Apr 2000 10:23:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 930B944341
	for ; Tue, 11 Apr 2000 10:23:10 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 4619352BB; Tue, 11 Apr 2000 10:23:09 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4737F52B6
	for ; Tue, 11 Apr 2000 10:23:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Apr 11 10:22:42 EDT 2000
Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Apr 11 10:22:41 EDT 2000
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA10835;
	Tue, 11 Apr 2000 10:22:39 -0400 (EDT)
Message-ID: <38F3352F.E548ED87@cisco.com>
Date: Tue, 11 Apr 2000 10:22:39 -0400
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Registrar - lookup 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I have some doubts about the lookup key used by the registrar. Let us say
that a user A sends a REGISTER to his registrar :

REGISTER mydomain.com:5060 SIP/2.0
Via: ...
From: ...
Call-ID: ...
CSeq: ...
To: 
Contact: ;expires=7200
Content-Length:0

Now, there are 2 fundamental questions :

1) How to locate the registrations of userA
Use "userA@mydomain.com" as search key. Is that a correct answer ??
(In other words use user@host as the search key.)

2) How to determine if this Contact updates an existing Contact or is a new
Contact ?

At one point, the spec says SIP URI in Contact should be compared according
to the URI comparison rules and then subsequently it says registrations are
matched based on the user, host, port and maddr parameters. 
Can someone clarify this ??

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  Tue Apr 11 10:56: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 KAA07501
	for ; Tue, 11 Apr 2000 10:56: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 70E034433B; Tue, 11 Apr 2000 10:54:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp.tari.toshiba.com (unknown [207.122.4.195])
	by lists.bell-labs.com (Postfix) with SMTP id 0DD6844337
	for ; Tue, 11 Apr 2000 10:54:18 -0400 (EDT)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-000225) with ESMTP id KAA06223
	for ; Tue, 11 Apr 2000 10:57:45 -0400
To: sip@lists.bell-labs.com
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000411100030N.sbaba@tari.toshiba.com>
Date: Tue, 11 Apr 2000 10:00:30 -0500 (EST)
From: "Baba, S." 
X-Dispatcher: imput version 20000228(IM140)
Lines: 44
Subject: [SIP] SIP and soft hand-off
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

Thank you for your attention to my presentation of
our mobility management requirement in Adelaide.

Let me add a brief explanation about a relation between
SIP and wireless soft hand-off, since I feel I didn't answer
raised questions well. Please read the related part (4.1)
of our revised draft  also.

First, we believe that the requirement wireless
'technology-independent" is very important principle.
At the same time, the soft hand-off is one of the key
technology promising high efficiency for the CDMA-based
wireless system. So any protocol on top of the wireless
shall not break the soft hand-off capability in the
wireless part. These are our basic assumptions.

The soft hand-off has some aspects like giving smooth hand-off
taking several tens seconds or more for the radio path change
and giving more than one radio paths during the hand-off.
If the soft hand-off is handled in the L2 only or below
L3 and doesn't affect the upper layer process, it is no
problem with SIP.

But if we consider the future RAN using IP transport,
SIP User Agent and/or Proxy Server may need a process
to support the mobility management on top of the soft hand-off.
Because SIP controls smooth hand-off of its IP sessions.

Although the details are still open issues, this is the
basic consideration about the soft hand-off.
Any questions and comments are welcomed.

Thank you.

Baba//
-----
Shinichi Baba
Toshiba America Research, Inc. (TARI)
Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
Phone: (973) 829-4795/ Fax: (973) 829-5601
Email: sbaba@tari.toshiba.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 Apr 11 22:18:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27270
	for ; Tue, 11 Apr 2000 22: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 BC97E44337; Tue, 11 Apr 2000 22:15:42 -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 48B4B44336
	for ; Tue, 11 Apr 2000 22:15:40 -0400 (EDT)
Received: from vovida.com ([209.237.8.98])
	by repulse.cnchost.com
	id WAA08420; Tue, 11 Apr 2000 22:18:05 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38F3FC06.612AA92F@vovida.com>
Date: Tue, 11 Apr 2000 21:31:02 -0700
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPbell-labs 
Content-Type: multipart/alternative;
 boundary="------------B2D4368FFA42BF7A9E0BD547"
Subject: [SIP] INFO msg call Flows
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


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

Hi :

Are there any call flows with the INFO method, similar to the ones in
the call flow document.


Thanks!

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



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



Hi :

Are there any call flows with the INFO method, similar to the ones in
the call flow document.

 

Thanks!

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

 

--------------B2D4368FFA42BF7A9E0BD547--



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


From sip-admin@lists.bell-labs.com  Wed Apr 12 07:49: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 HAA15913
	for ; Wed, 12 Apr 2000 07:49: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 9394344337; Wed, 12 Apr 2000 07:47:01 -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 A2E9544336
	for ; Wed, 12 Apr 2000 07:46:58 -0400 (EDT)
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id NAA11613;
	Wed, 12 Apr 2000 13:49:28 +0200 (MET DST)
Received: from ericsson.com ([136.225.183.58])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id NAA16060;
	Wed, 12 Apr 2000 13:49:18 +0200 (MET DST)
Message-ID: <38F43E30.899524BC@ericsson.com>
Date: Wed, 12 Apr 2000 11:13:20 +0200
From: Stephen Terrill 
Organization: L.M. Ericsson
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Baba, S." 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and soft hand-off
References: <20000411100030N.sbaba@tari.toshiba.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hi Baba,

I am not sure that I understand the requirements as discussed here.  I understand that the technology independance requirement, and quite like that, however I don´t understand the need of the SIP protocol level to be involved in the Soft hand-off.  I would have expected that the soft hand-off would be entirely within the "access network" (the mobile network technology), from the prespective of the SIP applications.  As such, the application shouldn´t even be aware of the hand-overs (won´t even change IP address).

Regards,

..//steve

"Baba, S." wrote:

> Folks,
>
> Thank you for your attention to my presentation of
> our mobility management requirement in Adelaide.
>
> Let me add a brief explanation about a relation between
> SIP and wireless soft hand-off, since I feel I didn't answer
> raised questions well. Please read the related part (4.1)
> of our revised draft  also.
>
> First, we believe that the requirement wireless
> 'technology-independent" is very important principle.
> At the same time, the soft hand-off is one of the key
> technology promising high efficiency for the CDMA-based
> wireless system. So any protocol on top of the wireless
> shall not break the soft hand-off capability in the
> wireless part. These are our basic assumptions.
>
> The soft hand-off has some aspects like giving smooth hand-off
> taking several tens seconds or more for the radio path change
> and giving more than one radio paths during the hand-off.
> If the soft hand-off is handled in the L2 only or below
> L3 and doesn't affect the upper layer process, it is no
> problem with SIP.
>
> But if we consider the future RAN using IP transport,
> SIP User Agent and/or Proxy Server may need a process
> to support the mobility management on top of the soft hand-off.
> Because SIP controls smooth hand-off of its IP sessions.
>
> Although the details are still open issues, this is the
> basic consideration about the soft hand-off.
> Any questions and comments are welcomed.
>
> Thank you.
>
> Baba//
> -----
> Shinichi Baba
> Toshiba America Research, Inc. (TARI)
> Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> Phone: (973) 829-4795/ Fax: (973) 829-5601
> Email: sbaba@tari.toshiba.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 Apr 12 09: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 JAA19575
	for ; Wed, 12 Apr 2000 09: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 EEC7044337; Wed, 12 Apr 2000 09:31:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id A474944336
	for ; Wed, 12 Apr 2000 09:31:18 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAB26993;
	Wed, 12 Apr 2000 09:33:42 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA13475; Wed, 12 Apr 2000 09:34:42 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <2ZA533PH>; Wed, 12 Apr 2000 07:34:34 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Stephen Terrill ,
        "Baba, S." 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Wed, 12 Apr 2000 09:33:21 -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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA19575

Hi, Baba and Steve:

I guess that Steve is right.

Let us keep the activities of the lower layer (e.g., link/network) separate
from the application layer (e.g., SIP) as far as practicable.

For example, if the network layer address (e.g., IP address) is not changed
during the soft-handover why should we bring that abstraction to the
application layer (e.g., SIP)?

Best regards,
Radhika R. Roy
AT&T
+1 732 420 1580
rrroy@att.com

> -----Original Message-----
> From:	Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> Sent:	Wednesday, April 12, 2000 5:13 AM
> To:	Baba, S.
> Cc:	sip@lists.bell-labs.com
> Subject:	Re: [SIP] SIP and soft hand-off
> 
> Hi Baba,
> 
> I am not sure that I understand the requirements as discussed here.  I
> understand that the technology independance requirement, and quite like
> that, however I don´t understand the need of the SIP protocol level to be
> involved in the Soft hand-off.  I would have expected that the soft
> hand-off would be entirely within the "access network" (the mobile network
> technology), from the prespective of the SIP applications.  As such, the
> application shouldn´t even be aware of the hand-overs (won´t even change
> IP address).
> 
> Regards,
> 
> ..//steve
> 
> "Baba, S." wrote:
> 
> > Folks,
> >
> > Thank you for your attention to my presentation of
> > our mobility management requirement in Adelaide.
> >
> > Let me add a brief explanation about a relation between
> > SIP and wireless soft hand-off, since I feel I didn't answer
> > raised questions well. Please read the related part (4.1)
> > of our revised draft  also.
> >
> > First, we believe that the requirement wireless
> > 'technology-independent" is very important principle.
> > At the same time, the soft hand-off is one of the key
> > technology promising high efficiency for the CDMA-based
> > wireless system. So any protocol on top of the wireless
> > shall not break the soft hand-off capability in the
> > wireless part. These are our basic assumptions.
> >
> > The soft hand-off has some aspects like giving smooth hand-off
> > taking several tens seconds or more for the radio path change
> > and giving more than one radio paths during the hand-off.
> > If the soft hand-off is handled in the L2 only or below
> > L3 and doesn't affect the upper layer process, it is no
> > problem with SIP.
> >
> > But if we consider the future RAN using IP transport,
> > SIP User Agent and/or Proxy Server may need a process
> > to support the mobility management on top of the soft hand-off.
> > Because SIP controls smooth hand-off of its IP sessions.
> >
> > Although the details are still open issues, this is the
> > basic consideration about the soft hand-off.
> > Any questions and comments are welcomed.
> >
> > Thank you.
> >
> > Baba//
> > -----
> > Shinichi Baba
> > Toshiba America Research, Inc. (TARI)
> > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > Email: sbaba@tari.toshiba.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 Apr 12 11:07: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 LAA23683
	for ; Wed, 12 Apr 2000 11:07: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 8E47644337; Wed, 12 Apr 2000 11:05:04 -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 8C9A444336
	for ; Wed, 12 Apr 2000 11:04:52 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA04844;
	Wed, 12 Apr 2000 11:07:07 -0400 (EDT)
Received: from research.telcordia.com (VFaramak.cc.telcordia.com [128.96.54.222])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA25395;
	Wed, 12 Apr 2000 11:07:06 -0400 (EDT)
Message-ID: <38F49115.A9DA3B05@research.telcordia.com>
Date: Wed, 12 Apr 2000 11:07:04 -0400
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: "Roy, Radhika R, ALARC" 
Cc: Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com,
        "itsumo@research.telcordia.com" ,
        ococking@telcordia.com
Subject: Re: [SIP] SIP and soft hand-off
References: 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

In a nutshell, the soft hand-off  process

 i.   a mobile station (MS) commences communication
      with a new base station (BS) without interuppting
      communication with the old base station. In
      other word, the MS receives multiple copies of
      the "same" signal  from multiple BSs simultaneously.
 ii.  Then, the MS (DSP algorithms within the hand set) forwards
      a weighted combination of the received signal to the higher layers.

Thus, in order to maintain advantages of the soft hand-off process in
an IP environment, during the soft hand-off process of an MS (refered
to as the MS, hereafter)

   a.  the packets destined for the MS should be forwarded to
        multiple BSs (at least current and previous ones) during the
        soft hand-off process to ensure that signals received from
        different BSs carries actual user data, and
   b. multiple copies of the same packet forwarded by different
       BSs to the MS must arrive at the MS synchronously so that at the
       CDMA layer all signals contain identical user information, and
       accurate information is forwarded to higher layers of the MS.

Without much elaboration, we refer to (a) and (b) as "virtual"
soft hand-off in . In
order to support it, we need to commence a synchronous multicast
of packets bound for the MS to multiple BSs during the soft hand-off
process and this is where SIP gets involved.  A simple and neat resoultion
of this problem is a challenge and we are currently working on it.

One last point, one way for ensuring wireless "technlogy independence"
axiom/requirement is that the MS may communicate its hand-off
preference (soft or hard) to its corresponding host via the SDP.

Regards, Faramak


Roy, Radhika R, ALARC wrote:

> Hi, Baba and Steve:
>
> I guess that Steve is right.
>
> Let us keep the activities of the lower layer (e.g., link/network) separate
> from the application layer (e.g., SIP) as far as practicable.
>
> For example, if the network layer address (e.g., IP address) is not changed
> during the soft-handover why should we bring that abstraction to the
> application layer (e.g., SIP)?
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy@att.com
>
> > -----Original Message-----
> > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> > Sent: Wednesday, April 12, 2000 5:13 AM
> > To:   Baba, S.
> > Cc:   sip@lists.bell-labs.com
> > Subject:      Re: [SIP] SIP and soft hand-off
> >
> > Hi Baba,
> >
> > I am not sure that I understand the requirements as discussed here.  I
> > understand that the technology independance requirement, and quite like
> > that, however I don´t understand the need of the SIP protocol level to be
> > involved in the Soft hand-off.  I would have expected that the soft
> > hand-off would be entirely within the "access network" (the mobile network
> > technology), from the prespective of the SIP applications.  As such, the
> > application shouldn´t even be aware of the hand-overs (won´t even change
> > IP address).
> >
> > Regards,
> >
> > ..//steve
> >
> > "Baba, S." wrote:
> >
> > > Folks,
> > >
> > > Thank you for your attention to my presentation of
> > > our mobility management requirement in Adelaide.
> > >
> > > Let me add a brief explanation about a relation between
> > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > raised questions well. Please read the related part (4.1)
> > > of our revised draft  also.
> > >
> > > First, we believe that the requirement wireless
> > > 'technology-independent" is very important principle.
> > > At the same time, the soft hand-off is one of the key
> > > technology promising high efficiency for the CDMA-based
> > > wireless system. So any protocol on top of the wireless
> > > shall not break the soft hand-off capability in the
> > > wireless part. These are our basic assumptions.
> > >
> > > The soft hand-off has some aspects like giving smooth hand-off
> > > taking several tens seconds or more for the radio path change
> > > and giving more than one radio paths during the hand-off.
> > > If the soft hand-off is handled in the L2 only or below
> > > L3 and doesn't affect the upper layer process, it is no
> > > problem with SIP.
> > >
> > > But if we consider the future RAN using IP transport,
> > > SIP User Agent and/or Proxy Server may need a process
> > > to support the mobility management on top of the soft hand-off.
> > > Because SIP controls smooth hand-off of its IP sessions.
> > >
> > > Although the details are still open issues, this is the
> > > basic consideration about the soft hand-off.
> > > Any questions and comments are welcomed.
> > >
> > > Thank you.
> > >
> > > Baba//
> > > -----
> > > Shinichi Baba
> > > Toshiba America Research, Inc. (TARI)
> > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > Email: sbaba@tari.toshiba.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 Apr 12 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 LAA24866
	for ; Wed, 12 Apr 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 EF6FE4433E; Wed, 12 Apr 2000 11:42:37 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp.tari.toshiba.com (unknown [207.122.4.195])
	by lists.bell-labs.com (Postfix) with SMTP id CEEAC44336
	for ; Wed, 12 Apr 2000 11:42:33 -0400 (EDT)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-000225) with ESMTP id LAA09501;
	Wed, 12 Apr 2000 11:46:10 -0400
To: sip@lists.bell-labs.com
Cc: itsumo@research.telcordia.com
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: 
References: 
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000412104852L.sbaba@tari.toshiba.com>
Date: Wed, 12 Apr 2000 10:48:52 -0500 (EST)
From: "Baba, S." 
X-Dispatcher: imput version 20000228(IM140)
Lines: 25
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi Steve and Radhika,

Thank you for your comments.

First of all, I agree with you that SIP needs to do nothing in
any case if IP address of Mobile Station (MS) is not changed.

And I also agree with both of you in the case of certain (and maybe
popular) architecture, e.g. the one on which 3GPP or 3GPP2 is
working right now. Because in this case the soft hand-off is
completely processed in or under the layer 2 and MS can not
distinguish if it is the hard hand-off or the soft hand-off from
upper layers.

As Faramak mentioned in his reply, we are looking at the future RAN
which will use the IP even for its transport method, i.e. IP
in the RAN or IP to the BTS, at the same time. Even in this case,
the mobility management by SIP shall not break the soft hand-off
process using IP communication. That is the point where we are
thinking as one of the important principles.

Regards,

baba//



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


From sip-admin@lists.bell-labs.com  Wed Apr 12 13:22:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28281
	for ; Wed, 12 Apr 2000 13:22:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4353C44336; Wed, 12 Apr 2000 13:19:19 -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 B80A544336
	for ; Wed, 12 Apr 2000 07:25:31 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 12 07:26:20 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 3B6FA44344; Wed, 12 Apr 2000 07:13:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id A524144341
	for ; Wed, 12 Apr 2000 07:13:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 644B452BB; Wed, 12 Apr 2000 07:13:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8087252AB
	for ; Wed, 12 Apr 2000 07:13:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Apr 12 07:11:28 EDT 2000
Received: from ietf.org ([132.151.1.176]) by dusty; Wed Apr 12 07:11:28 EDT 2000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15143;
	Wed, 12 Apr 2000 07:11:26 -0400 (EDT)
Message-Id: <200004121111.HAA15143@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.research.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Wed, 12 Apr 2000 07:11:25 -0400
Subject: [SIP] I-D ACTION:draft-itsumo-sip-mobility-req-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:  
X-BeenThere: sip@lists.bell-labs.com

--NextPart

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


	Title		: Mobility Management in a SIP Environment Requirements,
                          Functions and Issues
	Author(s)	: F. Vakil, A. Dutta, J. Chen,  S. Baba,
                          Y. Shobatake, H. Schulzrinne
	Filename	: draft-itsumo-sip-mobility-req-01.txt
	Pages		: 15
	Date		: 11-Apr-00
	
Mobility is rapidly becoming a rule rather than an exception in
communication services and SIP is gaining widespread acceptance as
the signaling protocol for multimedia applications on the Internet.
Thus, it is essential to develop a mobility management scheme that
utilizes salient features and capabilities of SIP as well as other
protocols (e.g., mobile IP) to support mobile services efficiently.
Without providing any specific solution, this document presents
preliminary requirements and identifies the issues that need to be
resolved in order to develop a mobility management scheme for
supporting multimedia applications in a SIP signaling and control
environment.

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

ENCODING mime
FILE /internet-drafts/draft-itsumo-sip-mobility-req-01.txt

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

Content-Type: text/plain
Content-ID:	<20000411095858.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 Apr 12 13: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 NAA28297
	for ; Wed, 12 Apr 2000 13: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 D28AC44344; Wed, 12 Apr 2000 13:19:21 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 159C444336
	for ; Tue, 11 Apr 2000 16:57:37 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 11 16:58:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id C8F9144344; Tue, 11 Apr 2000 16:45:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 9F26444341
	for ; Tue, 11 Apr 2000 16:45:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5C60052BB; Tue, 11 Apr 2000 16:45:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7E09952AB
	for ; Tue, 11 Apr 2000 16:45:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Apr 11 16:44:22 EDT 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Apr 11 16:44:21 EDT 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FSV00JL3DLV71@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 11 Apr 2000 20:44:19 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSV00701DLU0G@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Tue, 11 Apr 2000 20:44:19 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSV003NMDLUXG@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Tue, 11 Apr 2000 20:44:18 +0000 (GMT)
Received: from dwillispc8 ([166.35.144.185])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000411204417.PXYO9726@[166.35.144.185]>; Tue,
 11 Apr 2000 20:44:17 +0000
Date: Tue, 11 Apr 2000 15:43:38 -0500
From: Dean Willis 
Subject: RE: [SIP] phone-context and RFC2543bis
In-reply-to: <38EE040A.7CF5E3B2@wcom.com>
To: Alan Johnston 
Cc: SIP 
Message-id: <001301bfa3f6$9d26a0e0$b99023a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


Alan,

I believe the existing SIP syntax allows for arbitrary URI parameters, so
there really aren't any syntactic changes needed.  The real question is the
semantics. I don't believe the semantics of which you want to use
"phone-contet" for have been discussed on the list.

I'd suggest you write your thoughts up as an ID and share them with us. I
think the basic idea sounds pretty good, but I'd like to see a more complete
framing of your intent.

--
Dean


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Alan Johnston
> Sent: Friday, April 07, 2000 10:52 AM
> To: SIP
> Subject: [SIP] phone-context and RFC2543bis
>
>
> Based on reports from Adelaide, it sounds like the consensus of
> the working
> group was to progress the Call Flows I-D
> (draft-ietf-sip-call-flows-00.txt) to
> Informational RFC as soon as possible.
>
> One item that needs to be resolved first is the "phone-context"
> tag which is
> used extensively in the Gateway dialing sections of the document
> for private
> phone numbers (extensions).
>
> In RFC2543, support for phone numbers in SIP URLs was included by
> including
> parameters from the then current version of the Tel URL I-D if
> "user=phone" was
> present.  Since then, there have been additional drafts of this document
> (currently draft-antti-telephony-url-12.txt).
>
> One of the critical additions to the Tel draft since RFC2543 was
> the addition of
> the phone-context tag used for local numbers to identify the
> scope in which the
> number is valid.  I believe this tag needs to be included in SIP
> URLs in the
> next SIP draft.
>
> For example, the U.S. directory assistance telephone number can
> be written in
> global form as:
>
> 	sip:+1-314-555-1212@gateway.carrier.com;user=phone
>
> However, if the number was only valid if dialed from within the
> U.S., the number
> could be written as a local phone number as:
>
> 	sip:314-555-1212@gateway.carrier.com;phone-context=+1
>
> Where the phone-context tag indicates that it is only valid from
> within country
> code 1.
>
> Another more compelling use of the phone-context tag is in
> dealing with private
> numbers - numbers that are not part of the public number space,
> but are part of
> a private numbering plan administered by a corporation or
> organization.  The
> examples in the Call Flows document are of this kind:
>
> 	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier
>
> In this example, it appears that the host portion (gateway
> address) of the URL
> is sufficient to specify the context of the private number.
> However, for cases
> where a gateway is shared among multiple customers, each with possibly
> overlapping private numbering plans, the use of phone-context is required:
> 	sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier-customer1
>
> The use of the phone-context tag also allows interdomain private dialing,
> something impossible in todays PSTN.  For example, dialed digits for a
> particular dialing plan could be sent to a proxy for gateway lookup
>
> 	sip:444-1000@proxy.wcom.com;phone-context=carrier-customer2
>
> The proxy would lookup the gateway based on dialed digits and
> phone-context.  If
> the proxy did not have gateway information for that carrier (domain), the
> request could be proxied to that domain with the Request-URI becoming:
>
> 	sip:444-1000@proxy.carrier.com;phone-context=carrier-customer2
>
> These are just a few examples of the use of this tag.
>
> Are there any reasons why this tag should not be supported in SIP
> URLs in the
> next draft of RFC2543?
>
> Alan Johnston
> MCI WorldCom
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 12 15:50:24 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02054
	for ; Wed, 12 Apr 2000 15: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 75B8244337; Wed, 12 Apr 2000 15:47:43 -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 B8B2E44336
	for ; Wed, 12 Apr 2000 15:47:40 -0400 (EDT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FSX00CLT5RMXT@firewall.mcit.com> for sip@lists.bell-labs.com;
 Wed, 12 Apr 2000 19:50:10 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FSX00G015RL9M@pmismtp02.wcomnet.com>;
 Wed, 12 Apr 2000 19:50:10 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FSX00EAA5RKXT@pmismtp02.wcomnet.com>; Wed,
 12 Apr 2000 19:50:09 +0000 (GMT)
Received: from dwillispc8 ([166.35.150.75])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000412195006.OOQV32034@dwillispc8>; Wed,
 12 Apr 2000 19:50:06 +0000
Date: Wed, 12 Apr 2000 14:49:26 -0500
From: Dean Willis 
Subject: RE: [SIP] SIP and soft hand-off
In-reply-to: <38F43E30.899524BC@ericsson.com>
To: Stephen Terrill ,
        "Baba, S." 
Cc: sip@lists.bell-labs.com
Message-id: <001001bfa4b8$35558cc0$4b9623a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8BIT


One can envision a layer-2 hand off, a layer-3 (mobile-IP) hand off, or a
layer-4 handoff . . .

This mobility approach seems to me to be appropriate to a layer-4 handoff,
wherein the IP address actually changes. This has applicability outside
classic mobilephone. For example, when I undock my PC, I might want to
switch from my wired 100TX card to my wireless 802.11 card. Both can be
active during handoff -- then I shut down the wired card and undock.

--
Dean

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stephen Terrill
> Sent: Wednesday, April 12, 2000 4:13 AM
> To: Baba, S.
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] SIP and soft hand-off
>
>
> Hi Baba,
>
> I am not sure that I understand the requirements as discussed
> here.  I understand that the technology independance requirement,
> and quite like that, however I don´t understand the need of the
> SIP protocol level to be involved in the Soft hand-off.  I would
> have expected that the soft hand-off would be entirely within the
> "access network" (the mobile network technology), from the
> prespective of the SIP applications.  As such, the application
> shouldn´t even be aware of the hand-overs (won´t even change IP address).
>
> Regards,
>
> ..//steve
>
> "Baba, S." wrote:
>
> > Folks,
> >
> > Thank you for your attention to my presentation of
> > our mobility management requirement in Adelaide.
> >
> > Let me add a brief explanation about a relation between
> > SIP and wireless soft hand-off, since I feel I didn't answer
> > raised questions well. Please read the related part (4.1)
> > of our revised draft  also.
> >
> > First, we believe that the requirement wireless
> > 'technology-independent" is very important principle.
> > At the same time, the soft hand-off is one of the key
> > technology promising high efficiency for the CDMA-based
> > wireless system. So any protocol on top of the wireless
> > shall not break the soft hand-off capability in the
> > wireless part. These are our basic assumptions.
> >
> > The soft hand-off has some aspects like giving smooth hand-off
> > taking several tens seconds or more for the radio path change
> > and giving more than one radio paths during the hand-off.
> > If the soft hand-off is handled in the L2 only or below
> > L3 and doesn't affect the upper layer process, it is no
> > problem with SIP.
> >
> > But if we consider the future RAN using IP transport,
> > SIP User Agent and/or Proxy Server may need a process
> > to support the mobility management on top of the soft hand-off.
> > Because SIP controls smooth hand-off of its IP sessions.
> >
> > Although the details are still open issues, this is the
> > basic consideration about the soft hand-off.
> > Any questions and comments are welcomed.
> >
> > Thank you.
> >
> > Baba//
> > -----
> > Shinichi Baba
> > Toshiba America Research, Inc. (TARI)
> > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > Email: sbaba@tari.toshiba.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 Apr 12 16:49: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 QAA03091
	for ; Wed, 12 Apr 2000 16:49: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 07F5B44338; Wed, 12 Apr 2000 16:47:13 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 4CE7C44336
	for ; Wed, 12 Apr 2000 16:47:10 -0400 (EDT)
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25730;
	Wed, 12 Apr 2000 16:49:40 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA17220;
	Wed, 12 Apr 2000 16:49:43 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <2MSFVSYR>; Wed, 12 Apr 2000 16:44:40 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF67819D@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Dean Willis'" ,
        Stephen Terrill ,
        "Baba, S." 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Wed, 12 Apr 2000 16:49:41 -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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03091

I understand what you want to do.  I like it.
I don't like saying that because your IP address changed,
ALL application level protocols have to know about it.

If that's what you want to do, let's purge the app level
protocols of the part that changes, even if we have to add a layer
somewhere.  It SHOULD NOT require changes in EVERY protocol
to make real mobility work.  

That is the basic issue I see with the flurry of mobility efforts.
These guys are EVERYWHERE telling us that we have to change what we
are doing in order to accommodate mobility.  There isn't a protocol
effort I'm involved in that doesn't have a cadre of people trying
to get something in it to make mobility work.

That is just plain wrong.  If mobility is, or is about to be,
ubiquitous, then we should change IP if we have to.  We should not
change SIP, LDAP, COPS, ISUP, DNS, NTP, HTTP, FTP, RADIUS,
and every other protocol we really use.  

It is entirely inappropriate for any session level protocol, let alone
session establishment protocols, to have knowledge that the end
device is mobile.  It's like having the protocol have to know
whether they are on a LAN or a WAN.  Somewhere, someone cares,
but it shouldn't be SIP!

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com 



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@wcom.com]
> Sent: Wednesday, April 12, 2000 3:49 PM
> To: Stephen Terrill; Baba, S.
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
> 
> 
> 
> One can envision a layer-2 hand off, a layer-3 (mobile-IP) 
> hand off, or a
> layer-4 handoff . . .
> 
> This mobility approach seems to me to be appropriate to a 
> layer-4 handoff,
> wherein the IP address actually changes. This has 
> applicability outside
> classic mobilephone. For example, when I undock my PC, I might want to
> switch from my wired 100TX card to my wireless 802.11 card. 
> Both can be
> active during handoff -- then I shut down the wired card and undock.
> 
> --
> Dean
> 
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stephen Terrill
> > Sent: Wednesday, April 12, 2000 4:13 AM
> > To: Baba, S.
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] SIP and soft hand-off
> >
> >
> > Hi Baba,
> >
> > I am not sure that I understand the requirements as discussed
> > here.  I understand that the technology independance requirement,
> > and quite like that, however I don´t understand the need of the
> > SIP protocol level to be involved in the Soft hand-off.  I would
> > have expected that the soft hand-off would be entirely within the
> > "access network" (the mobile network technology), from the
> > prespective of the SIP applications.  As such, the application
> > shouldn´t even be aware of the hand-overs (won´t even 
> change IP address).
> >
> > Regards,
> >
> > ..//steve
> >
> > "Baba, S." wrote:
> >
> > > Folks,
> > >
> > > Thank you for your attention to my presentation of
> > > our mobility management requirement in Adelaide.
> > >
> > > Let me add a brief explanation about a relation between
> > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > raised questions well. Please read the related part (4.1)
> > > of our revised draft  also.
> > >
> > > First, we believe that the requirement wireless
> > > 'technology-independent" is very important principle.
> > > At the same time, the soft hand-off is one of the key
> > > technology promising high efficiency for the CDMA-based
> > > wireless system. So any protocol on top of the wireless
> > > shall not break the soft hand-off capability in the
> > > wireless part. These are our basic assumptions.
> > >
> > > The soft hand-off has some aspects like giving smooth hand-off
> > > taking several tens seconds or more for the radio path change
> > > and giving more than one radio paths during the hand-off.
> > > If the soft hand-off is handled in the L2 only or below
> > > L3 and doesn't affect the upper layer process, it is no
> > > problem with SIP.
> > >
> > > But if we consider the future RAN using IP transport,
> > > SIP User Agent and/or Proxy Server may need a process
> > > to support the mobility management on top of the soft hand-off.
> > > Because SIP controls smooth hand-off of its IP sessions.
> > >
> > > Although the details are still open issues, this is the
> > > basic consideration about the soft hand-off.
> > > Any questions and comments are welcomed.
> > >
> > > Thank you.
> > >
> > > Baba//
> > > -----
> > > Shinichi Baba
> > > Toshiba America Research, Inc. (TARI)
> > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > Email: sbaba@tari.toshiba.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 Apr 12 16:56:34 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03216
	for ; Wed, 12 Apr 2000 16:56: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 9A7744434C; Wed, 12 Apr 2000 16:53:56 -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 EEC8A4434B
	for ; Wed, 12 Apr 2000 16:53:53 -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 NAA21182;
	Wed, 12 Apr 2000 13:56:24 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ACP00578;
	Wed, 12 Apr 2000 13:54:42 -0700 (PDT)
Message-Id: <4.2.0.58.20000412135150.00c2d5f0@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 12 Apr 2000 13:55:39 -0700
To: Faramak Vakil 
From: Rohan Mahy 
Subject: Re: [SIP] SIP and soft hand-off
Cc: "Roy, Radhika R, ALARC" ,
        Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com,
        "itsumo@research.telcordia.com" ,
        ococking@telcordia.com
In-Reply-To: <38F49115.A9DA3B05@research.telcordia.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03216

Hi,

Is this a layer 2 multicast?  If so, it seems this problem could be solved 
by simply changing the ARP table during soft handoff.  Am I missing 
something here?

thanks,
-rohan


At 08:07 AM 4/12/00 , Faramak Vakil wrote:
>In a nutshell, the soft hand-off  process
>
>  i.   a mobile station (MS) commences communication
>       with a new base station (BS) without interuppting
>       communication with the old base station. In
>       other word, the MS receives multiple copies of
>       the "same" signal  from multiple BSs simultaneously.
>  ii.  Then, the MS (DSP algorithms within the hand set) forwards
>       a weighted combination of the received signal to the higher layers.
>
>Thus, in order to maintain advantages of the soft hand-off process in
>an IP environment, during the soft hand-off process of an MS (refered
>to as the MS, hereafter)
>
>    a.  the packets destined for the MS should be forwarded to
>         multiple BSs (at least current and previous ones) during the
>         soft hand-off process to ensure that signals received from
>         different BSs carries actual user data, and
>    b. multiple copies of the same packet forwarded by different
>        BSs to the MS must arrive at the MS synchronously so that at the
>        CDMA layer all signals contain identical user information, and
>        accurate information is forwarded to higher layers of the MS.
>
>Without much elaboration, we refer to (a) and (b) as "virtual"
>soft hand-off in . In
>order to support it, we need to commence a synchronous multicast
>of packets bound for the MS to multiple BSs during the soft hand-off
>process and this is where SIP gets involved.  A simple and neat resoultion
>of this problem is a challenge and we are currently working on it.
>
>One last point, one way for ensuring wireless "technlogy independence"
>axiom/requirement is that the MS may communicate its hand-off
>preference (soft or hard) to its corresponding host via the SDP.
>
>Regards, Faramak
>
>
>Roy, Radhika R, ALARC wrote:
>
> > Hi, Baba and Steve:
> >
> > I guess that Steve is right.
> >
> > Let us keep the activities of the lower layer (e.g., link/network) separate
> > from the application layer (e.g., SIP) as far as practicable.
> >
> > For example, if the network layer address (e.g., IP address) is not changed
> > during the soft-handover why should we bring that abstraction to the
> > application layer (e.g., SIP)?
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > +1 732 420 1580
> > rrroy@att.com
> >
> > > -----Original Message-----
> > > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> > > Sent: Wednesday, April 12, 2000 5:13 AM
> > > To:   Baba, S.
> > > Cc:   sip@lists.bell-labs.com
> > > Subject:      Re: [SIP] SIP and soft hand-off
> > >
> > > Hi Baba,
> > >
> > > I am not sure that I understand the requirements as discussed here.  I
> > > understand that the technology independance requirement, and quite like
> > > that, however I don´t understand the need of the SIP protocol level to be
> > > involved in the Soft hand-off.  I would have expected that the soft
> > > hand-off would be entirely within the "access network" (the mobile 
> network
> > > technology), from the prespective of the SIP applications.  As such, the
> > > application shouldn´t even be aware of the hand-overs (won´t even change
> > > IP address).
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Baba, S." wrote:
> > >
> > > > Folks,
> > > >
> > > > Thank you for your attention to my presentation of
> > > > our mobility management requirement in Adelaide.
> > > >
> > > > Let me add a brief explanation about a relation between
> > > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > > raised questions well. Please read the related part (4.1)
> > > > of our revised draft  also.
> > > >
> > > > First, we believe that the requirement wireless
> > > > 'technology-independent" is very important principle.
> > > > At the same time, the soft hand-off is one of the key
> > > > technology promising high efficiency for the CDMA-based
> > > > wireless system. So any protocol on top of the wireless
> > > > shall not break the soft hand-off capability in the
> > > > wireless part. These are our basic assumptions.
> > > >
> > > > The soft hand-off has some aspects like giving smooth hand-off
> > > > taking several tens seconds or more for the radio path change
> > > > and giving more than one radio paths during the hand-off.
> > > > If the soft hand-off is handled in the L2 only or below
> > > > L3 and doesn't affect the upper layer process, it is no
> > > > problem with SIP.
> > > >
> > > > But if we consider the future RAN using IP transport,
> > > > SIP User Agent and/or Proxy Server may need a process
> > > > to support the mobility management on top of the soft hand-off.
> > > > Because SIP controls smooth hand-off of its IP sessions.
> > > >
> > > > Although the details are still open issues, this is the
> > > > basic consideration about the soft hand-off.
> > > > Any questions and comments are welcomed.
> > > >
> > > > Thank you.
> > > >
> > > > Baba//
> > > > -----
> > > > Shinichi Baba
> > > > Toshiba America Research, Inc. (TARI)
> > > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > > Email: sbaba@tari.toshiba.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  Wed Apr 12 17: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 RAA03681
	for ; Wed, 12 Apr 2000 17:18: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 671F944343; Wed, 12 Apr 2000 17:16:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ns1.cirilium.com (ns1.cirilium.com [207.13.202.251])
	by lists.bell-labs.com (Postfix) with ESMTP id BB2DB44336
	for ; Wed, 12 Apr 2000 17:16:03 -0400 (EDT)
Received: from tornado.cirilium.com (mailserver.cirilium.com [10.40.3.4])
	by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id OAA08434
	for ; Wed, 12 Apr 2000 14:15:56 -0700
Received: from lcoxnt1 ([10.40.2.147])
          by tornado.cirilium.com (Lotus Domino Release 5.0.2b)
          with SMTP id 2000041214183677:1938 ;
          Wed, 12 Apr 2000 14:18:36 -0700 
Message-Id: <4.1.20000412135615.00b93be0@mail.neta.com>
X-Sender: lcox@mail.neta.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 12 Apr 2000 14:19:59 -0700
To: sip@lists.bell-labs.com
From: Larry Cox 
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: <4FBEA8857476D311A03300204840E1CF67819D@whq-msgusr-02.fore.
 com>
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.2b |December 16, 1999) at
 04/12/2000 02:18:36 PM,
	Serialize by Router on Cirilium1/Cirilium(Release 5.0.2b |December 16, 1999) at
 04/12/2000 02:18:37 PM,
	Serialize complete at 04/12/2000 02:18:37 PM
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:  
X-BeenThere: sip@lists.bell-labs.com

Brian Rosen wrote:
> ...
>
>It is entirely inappropriate for any session level protocol, let alone
>session establishment protocols, to have knowledge that the end
>device is mobile.  It's like having the protocol have to know
>whether they are on a LAN or a WAN.  Somewhere, someone cares,
>but it shouldn't be SIP!
>
>Brian

I am glad that I am not alone. I had begun believing that we had lost sight
of the objective of having a layered protocol. If we cannot localize the
knowledge of delivery addresses, we have probably broken the protocol and
will have to go back and start over as soon as the next major evolutionary
change happens. It appears to me that if we have chosen to use UDP and TCP,
the necessity of having IP and the associated IP addresses underneath it
should be explicitly rejected. Some other protocol should be allowed at
that level if it works better. In the same sense that HDLC works best in
some spaces and Ethernet works better in others. If we are keeping the type
of network hardware separate form the application level, it is highly
illogical that we should expect the app to know about changes required for
mobility. Someone pointed out that simultaneous arrival of duplicate frames
is important for soft handoff. Should the SIP application be tasked with
tracking the transmission delay for multiple routes in order to make this
happen? If we get carried away and make the protocol monolithic there will
be very little chance for it to succeed.

Larry


======================================

Larry Cox
Senior Software Engineer

Cirilium Inc.            Phone: (480) 317-1115
1615 S. 52 St.           Fax:   (480) ???-????
Tempe, AZ 85281-6233     Web:    www.cirilium.com
USA


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


From sip-admin@lists.bell-labs.com  Wed Apr 12 17:36: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 RAA04000
	for ; Wed, 12 Apr 2000 17:36: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 1019F44350; Wed, 12 Apr 2000 17:34:08 -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 73C1E4434F
	for ; Wed, 12 Apr 2000 17:34:05 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA25257;
	Wed, 12 Apr 2000 17:36:27 -0400 (EDT)
Received: from research.telcordia.com (VFaramak.cc.telcordia.com [128.96.54.222])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA03976;
	Wed, 12 Apr 2000 17:36:26 -0400 (EDT)
Message-ID: <38F4EC58.16EFC1D@research.telcordia.com>
Date: Wed, 12 Apr 2000 17:36:25 -0400
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: Rohan Mahy 
Cc: "Roy, Radhika R, ALARC" ,
        Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com,
        "itsumo@research.telcordia.com" ,
        ococking@telcordia.com
Subject: Re: [SIP] SIP and soft hand-off
References:  <4.2.0.58.20000412135150.00c2d5f0@lint.cisco.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hello,

If the MS IP address does not change during the soft hand-off
(i.e., cells belong to the same subnet) you are right in principle.
However, if the cells belong to different subnets and the MS IP
address changes, we need to multicast at the IP layer.

Regards, Faramak

Rohan Mahy wrote:

> Hi,
>
> Is this a layer 2 multicast?  If so, it seems this problem could be solved
> by simply changing the ARP table during soft handoff.  Am I missing
> something here?
>
> thanks,
> -rohan
>
> At 08:07 AM 4/12/00 , Faramak Vakil wrote:
> >In a nutshell, the soft hand-off  process
> >
> >  i.   a mobile station (MS) commences communication
> >       with a new base station (BS) without interuppting
> >       communication with the old base station. In
> >       other word, the MS receives multiple copies of
> >       the "same" signal  from multiple BSs simultaneously.
> >  ii.  Then, the MS (DSP algorithms within the hand set) forwards
> >       a weighted combination of the received signal to the higher layers.
> >
> >Thus, in order to maintain advantages of the soft hand-off process in
> >an IP environment, during the soft hand-off process of an MS (refered
> >to as the MS, hereafter)
> >
> >    a.  the packets destined for the MS should be forwarded to
> >         multiple BSs (at least current and previous ones) during the
> >         soft hand-off process to ensure that signals received from
> >         different BSs carries actual user data, and
> >    b. multiple copies of the same packet forwarded by different
> >        BSs to the MS must arrive at the MS synchronously so that at the
> >        CDMA layer all signals contain identical user information, and
> >        accurate information is forwarded to higher layers of the MS.
> >
> >Without much elaboration, we refer to (a) and (b) as "virtual"
> >soft hand-off in . In
> >order to support it, we need to commence a synchronous multicast
> >of packets bound for the MS to multiple BSs during the soft hand-off
> >process and this is where SIP gets involved.  A simple and neat resoultion
> >of this problem is a challenge and we are currently working on it.
> >
> >One last point, one way for ensuring wireless "technlogy independence"
> >axiom/requirement is that the MS may communicate its hand-off
> >preference (soft or hard) to its corresponding host via the SDP.
> >
> >Regards, Faramak
> >
> >
> >Roy, Radhika R, ALARC wrote:
> >
> > > Hi, Baba and Steve:
> > >
> > > I guess that Steve is right.
> > >
> > > Let us keep the activities of the lower layer (e.g., link/network) separate
> > > from the application layer (e.g., SIP) as far as practicable.
> > >
> > > For example, if the network layer address (e.g., IP address) is not changed
> > > during the soft-handover why should we bring that abstraction to the
> > > application layer (e.g., SIP)?
> > >
> > > Best regards,
> > > Radhika R. Roy
> > > AT&T
> > > +1 732 420 1580
> > > rrroy@att.com
> > >
> > > > -----Original Message-----
> > > > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> > > > Sent: Wednesday, April 12, 2000 5:13 AM
> > > > To:   Baba, S.
> > > > Cc:   sip@lists.bell-labs.com
> > > > Subject:      Re: [SIP] SIP and soft hand-off
> > > >
> > > > Hi Baba,
> > > >
> > > > I am not sure that I understand the requirements as discussed here.  I
> > > > understand that the technology independance requirement, and quite like
> > > > that, however I don´t understand the need of the SIP protocol level to be
> > > > involved in the Soft hand-off.  I would have expected that the soft
> > > > hand-off would be entirely within the "access network" (the mobile
> > network
> > > > technology), from the prespective of the SIP applications.  As such, the
> > > > application shouldn´t even be aware of the hand-overs (won´t even change
> > > > IP address).
> > > >
> > > > Regards,
> > > >
> > > > ..//steve
> > > >
> > > > "Baba, S." wrote:
> > > >
> > > > > Folks,
> > > > >
> > > > > Thank you for your attention to my presentation of
> > > > > our mobility management requirement in Adelaide.
> > > > >
> > > > > Let me add a brief explanation about a relation between
> > > > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > > > raised questions well. Please read the related part (4.1)
> > > > > of our revised draft  also.
> > > > >
> > > > > First, we believe that the requirement wireless
> > > > > 'technology-independent" is very important principle.
> > > > > At the same time, the soft hand-off is one of the key
> > > > > technology promising high efficiency for the CDMA-based
> > > > > wireless system. So any protocol on top of the wireless
> > > > > shall not break the soft hand-off capability in the
> > > > > wireless part. These are our basic assumptions.
> > > > >
> > > > > The soft hand-off has some aspects like giving smooth hand-off
> > > > > taking several tens seconds or more for the radio path change
> > > > > and giving more than one radio paths during the hand-off.
> > > > > If the soft hand-off is handled in the L2 only or below
> > > > > L3 and doesn't affect the upper layer process, it is no
> > > > > problem with SIP.
> > > > >
> > > > > But if we consider the future RAN using IP transport,
> > > > > SIP User Agent and/or Proxy Server may need a process
> > > > > to support the mobility management on top of the soft hand-off.
> > > > > Because SIP controls smooth hand-off of its IP sessions.
> > > > >
> > > > > Although the details are still open issues, this is the
> > > > > basic consideration about the soft hand-off.
> > > > > Any questions and comments are welcomed.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Baba//
> > > > > -----
> > > > > Shinichi Baba
> > > > > Toshiba America Research, Inc. (TARI)
> > > > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > > > Email: sbaba@tari.toshiba.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



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


From sip-admin@lists.bell-labs.com  Wed Apr 12 19:46: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 TAA05374
	for ; Wed, 12 Apr 2000 19: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 224B944339; Wed, 12 Apr 2000 19:43:56 -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 A5BF244336
	for ; Wed, 12 Apr 2000 19:43:53 -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 TAA01883
	for ; Wed, 12 Apr 2000 19:46:27 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id TAA18509; Wed, 12 Apr 2000 19:45:37 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <249MJ9KJ>; Wed, 12 Apr 2000 19:46:27 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: sip@lists.bell-labs.com
Date: Wed, 12 Apr 2000 19:46:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [SIP] SIP for all Networking Environments
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Everyone:

It appears to me that some people may think: SIP can only be used in certain
special circumstances.

However, per RFC 2534, SIP is an application layer control (signaling)
protocol for creating, modifying and terminating sessions with one or more
participants.

So, SIP can be used for all networking environments: Fixed wire-line
networks, cellular (wireless) networks, and/or wireless LANs.

In the cell-based networking environment, 100s and 1000s of users will be
entering and leaving a cell while each session has to go on using SIP.

Definitely, there may be some special requirements especially for the highly
mobile cellular (wireless) networking environments (or in combination of
fixed + mobile) that have NOT been envisioned in RFC 2534. Some of these
issues have been surfaced in some recent internet drafts and email
discussions.

As a result, it is no wonder that we may see some extensions of SIP to
accommodate those requirements in the future.

We might have to address those issues to make SIP a powerful application
layer control protocol that can be used in all networking environments.

Going forward, let us address those technical issues keeping our eyes open.
(Let us keep in our mind that SIP still needs extensions even for the fixed
wire-line networking environment - not to speak about highly mobile
communications networking environments).

Best regards,

Radhika R. Roy
AT&T
+1 732 420 1580
rrroy@att.com



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


From sip-admin@lists.bell-labs.com  Thu Apr 13 03: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 DAA23934
	for ; Thu, 13 Apr 2000 03:38: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 A0FC544337; Thu, 13 Apr 2000 03:35:29 -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 C993344336
	for ; Thu, 13 Apr 2000 03:35:26 -0400 (EDT)
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA21566;
	Thu, 13 Apr 2000 09:38:01 +0200 (MET DST)
Received: from ericsson.com (aletx084.al.etx.ericsson.se [130.100.179.84])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id JAA19501;
	Thu, 13 Apr 2000 09:38:00 +0200 (MET DST)
Message-ID: <38F5793B.B284F98C@ericsson.com>
Date: Thu, 13 Apr 2000 09:37:31 +0200
From: Stephen Terrill 
Organization: L.M. Ericsson
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Baba, S." 
Cc: sip@lists.bell-labs.com, itsumo@research.telcordia.com
Subject: Re: [SIP] SIP and soft hand-off
References:  <20000412104852L.sbaba@tari.toshiba.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hi,

Perhaps out of all of the replies, this is the most appropriate to respond to.

It is interesting that it is pointed out here that for some of the popular archectures where this is being considered that the soft hand-over doesn´t come into the process as it happens at layer 2.  It is also interesting to not that a significant portion of those archectures do run on top of IP.  I think that it is required to remember where the IP network that the Application in the mobile terminal sees actually is - it is not necessary the IP network that is used to run the RAN.

Regards,

..//steve

"Baba, S." wrote:

> Hi Steve and Radhika,
>
> Thank you for your comments.
>
> First of all, I agree with you that SIP needs to do nothing in
> any case if IP address of Mobile Station (MS) is not changed.
>
> And I also agree with both of you in the case of certain (and maybe
> popular) architecture, e.g. the one on which 3GPP or 3GPP2 is
> working right now. Because in this case the soft hand-off is
> completely processed in or under the layer 2 and MS can not
> distinguish if it is the hard hand-off or the soft hand-off from
> upper layers.
>
> As Faramak mentioned in his reply, we are looking at the future RAN
> which will use the IP even for its transport method, i.e. IP
> in the RAN or IP to the BTS, at the same time. Even in this case,
> the mobility management by SIP shall not break the soft hand-off
> process using IP communication. That is the point where we are
> thinking as one of the important principles.
>
> Regards,
>
> baba//
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 13 09:25: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 JAA00551
	for ; Thu, 13 Apr 2000 09: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 CCFD144336; Thu, 13 Apr 2000 09:22:26 -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 CB8B744336
	for ; Wed, 12 Apr 2000 20:24:49 -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 RAA19467;
	Wed, 12 Apr 2000 17:26:52 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA02144; Wed, 12 Apr 2000 17:26:48 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14581.5192.635759.512831@thomasm-u1.cisco.com>
Date: Wed, 12 Apr 2000 17:26:48 -0700 (PDT)
To: "Rosen, Brian" 
Cc: "'Dean Willis'" ,
        Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: <4FBEA8857476D311A03300204840E1CF67819D@whq-msgusr-02.fore.com>
References: <4FBEA8857476D311A03300204840E1CF67819D@whq-msgusr-02.fore.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > It is entirely inappropriate for any session level protocol, let alone
 > session establishment protocols, to have knowledge that the end
 > device is mobile.  It's like having the protocol have to know
 > whether they are on a LAN or a WAN.  Somewhere, someone cares,
 > but it shouldn't be SIP!

Brian,

I think the more interesting question is what you
do when there is no end to end transparency. In
particular, what do you do when you have non-IP
mobile devices which are proxied by IP devices
which terminate the RTP flows into something
else. Sound like anything familiar?

In that case, end to end transparency is already
fogged and it's not entirely clear that mobile IP
is the right answer; it could just as easily be
modeled as a decomposed trunking situation where
the application layer MGC deals with the hard
handoffs. In this case, I don't think you are
inventing unreasonable application layer mobility
awareness since any SIP needs to have the ability
to deal with mid-call SDP changes (codecs, if
nothing else). The mobile SIP on the other hand
could deal with the hows and whens of the handoff
burden but that's not an unreasonable thing to
ask; in fact it's a feature, not a bug that a SIP
application could manage mobility in this way.

		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 Apr 13 09: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 JAA00616
	for ; Thu, 13 Apr 2000 09: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 D8EB044344; Thu, 13 Apr 2000 09:22:29 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id C2F9244336
	for ; Thu, 13 Apr 2000 08:51:22 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 13 08:52:34 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id EF05344344; Thu, 13 Apr 2000 08:39:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id C6F9544341
	for ; Thu, 13 Apr 2000 08:39:24 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 6C6F052BB; Thu, 13 Apr 2000 08:39:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 85F7E52AB
	for ; Thu, 13 Apr 2000 08:39:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Apr 13 08:37:44 EDT 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Thu Apr 13 08:37:43 EDT 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FSY00BENGETBD@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 13 Apr 2000 12:37:41 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSY00H01GETDE@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 13 Apr 2000 12:37:41 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSY00EK0GETR7@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 13 Apr 2000 12:37:41 +0000 (GMT)
Received: from wcom.com ([166.35.150.131])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000413123740.TACX32034@wcom.com>; Thu,
 13 Apr 2000 12:37:40 +0000
Date: Wed, 12 Apr 2000 07:41:22 -0500
From: Alan Johnston 
Subject: Re: [SIP] phone-context and RFC2543bis
To: Dean Willis 
Cc: SIP 
Message-id: <38F46EF1.A807D469@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <001301bfa3f6$9d26a0e0$b99023a6@mcit.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Will do - look for a draft shortly.

Alan

Dean Willis wrote:

> Alan,
>
> I believe the existing SIP syntax allows for arbitrary URI parameters, so
> there really aren't any syntactic changes needed.  The real question is the
> semantics. I don't believe the semantics of which you want to use
> "phone-contet" for have been discussed on the list.
>
> I'd suggest you write your thoughts up as an ID and share them with us. I
> think the basic idea sounds pretty good, but I'd like to see a more complete
> framing of your intent.
>
> --
> Dean
>
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Alan Johnston
> > Sent: Friday, April 07, 2000 10:52 AM
> > To: SIP
> > Subject: [SIP] phone-context and RFC2543bis
> >
> >
> > Based on reports from Adelaide, it sounds like the consensus of
> > the working
> > group was to progress the Call Flows I-D
> > (draft-ietf-sip-call-flows-00.txt) to
> > Informational RFC as soon as possible.
> >
> > One item that needs to be resolved first is the "phone-context"
> > tag which is
> > used extensively in the Gateway dialing sections of the document
> > for private
> > phone numbers (extensions).
> >
> > In RFC2543, support for phone numbers in SIP URLs was included by
> > including
> > parameters from the then current version of the Tel URL I-D if
> > "user=phone" was
> > present.  Since then, there have been additional drafts of this document
> > (currently draft-antti-telephony-url-12.txt).
> >
> > One of the critical additions to the Tel draft since RFC2543 was
> > the addition of
> > the phone-context tag used for local numbers to identify the
> > scope in which the
> > number is valid.  I believe this tag needs to be included in SIP
> > URLs in the
> > next SIP draft.
> >
> > For example, the U.S. directory assistance telephone number can
> > be written in
> > global form as:
> >
> >       sip:+1-314-555-1212@gateway.carrier.com;user=phone
> >
> > However, if the number was only valid if dialed from within the
> > U.S., the number
> > could be written as a local phone number as:
> >
> >       sip:314-555-1212@gateway.carrier.com;phone-context=+1
> >
> > Where the phone-context tag indicates that it is only valid from
> > within country
> > code 1.
> >
> > Another more compelling use of the phone-context tag is in
> > dealing with private
> > numbers - numbers that are not part of the public number space,
> > but are part of
> > a private numbering plan administered by a corporation or
> > organization.  The
> > examples in the Call Flows document are of this kind:
> >
> >       sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier
> >
> > In this example, it appears that the host portion (gateway
> > address) of the URL
> > is sufficient to specify the context of the private number.
> > However, for cases
> > where a gateway is shared among multiple customers, each with possibly
> > overlapping private numbering plans, the use of phone-context is required:
> >       sip:777-1234@gateway.mycarrier.com;phone-context=mycarrier-customer1
> >
> > The use of the phone-context tag also allows interdomain private dialing,
> > something impossible in todays PSTN.  For example, dialed digits for a
> > particular dialing plan could be sent to a proxy for gateway lookup
> >
> >       sip:444-1000@proxy.wcom.com;phone-context=carrier-customer2
> >
> > The proxy would lookup the gateway based on dialed digits and
> > phone-context.  If
> > the proxy did not have gateway information for that carrier (domain), the
> > request could be proxied to that domain with the Request-URI becoming:
> >
> >       sip:444-1000@proxy.carrier.com;phone-context=carrier-customer2
> >
> > These are just a few examples of the use of this tag.
> >
> > Are there any reasons why this tag should not be supported in SIP
> > URLs in the
> > next draft of RFC2543?
> >
> > Alan Johnston
> > MCI WorldCom
> >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/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 Apr 13 09:27: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 JAA00694
	for ; Thu, 13 Apr 2000 09:27: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 9969E44351; Thu, 13 Apr 2000 09:22:39 -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 77F794434D
	for ; Thu, 13 Apr 2000 09:22:36 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Thu, 13 Apr 2000 08:15:58 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <25JK3CVT>; Thu, 13 Apr 2000 08:15:57 -0500
Message-ID: 
From: "Glenn Morrow" 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 08:15:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA54A.6600D7FC"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFA54A.6600D7FC
Content-Type: text/plain

I honestly think this topic should be discussed in another WG, which WG is
something for others (IAB, Area Directors) to decide.

> -----Original Message-----
> From:	Larry Cox [SMTP:lcox@neta.com]
> Sent:	Wednesday, April 12, 2000 4:20 PM
> To:	sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
> 
> Brian Rosen wrote:
> > ...
> >
> >It is entirely inappropriate for any session level protocol, let alone
> >session establishment protocols, to have knowledge that the end
> >device is mobile.  It's like having the protocol have to know
> >whether they are on a LAN or a WAN.  Somewhere, someone cares,
> >but it shouldn't be SIP!
> >
> >Brian
> 
> I am glad that I am not alone. I had begun believing that we had lost
> sight
> of the objective of having a layered protocol. If we cannot localize the
> knowledge of delivery addresses, we have probably broken the protocol and
> will have to go back and start over as soon as the next major evolutionary
> change happens. It appears to me that if we have chosen to use UDP and
> TCP,
> the necessity of having IP and the associated IP addresses underneath it
> should be explicitly rejected. Some other protocol should be allowed at
> that level if it works better. In the same sense that HDLC works best in
> some spaces and Ethernet works better in others. If we are keeping the
> type
> of network hardware separate form the application level, it is highly
> illogical that we should expect the app to know about changes required for
> mobility. Someone pointed out that simultaneous arrival of duplicate
> frames
> is important for soft handoff. Should the SIP application be tasked with
> tracking the transmission delay for multiple routes in order to make this
> happen? If we get carried away and make the protocol monolithic there will
> be very little chance for it to succeed.
> 
> Larry
> 
> 
> ======================================
> 
> Larry Cox
> Senior Software Engineer
> 
> Cirilium Inc.            Phone: (480) 317-1115
> 1615 S. 52 St.           Fax:   (480) ???-????
> Tempe, AZ 85281-6233     Web:    www.cirilium.com
> USA
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFA54A.6600D7FC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SIP and soft hand-off




I honestly think =
this topic should be discussed in another WG, which WG is something for =
others (IAB, Area Directors) to decide.


    

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

    From:   Larry Cox [SMTP:lcox@neta.com]

    Sent:   Wednesday, April 12, 2000 4:20 PM

    To:     sip@lists.bell-labs.com

    Subject:       =
 RE: [SIP] SIP and soft =
hand-off

    


    Brian Rosen wrote:

    > ...

    >

    >It is entirely inappropriate for =
any session level protocol, let alone

    >session establishment protocols, =
to have knowledge that the end

    >device is mobile.  It's like =
having the protocol have to know

    >whether they are on a LAN or a =
WAN.  Somewhere, someone cares,

    >but it shouldn't be SIP!

    >

    >Brian

    


    I am glad that I am not alone. I had =
begun believing that we had lost sight

    of the objective of having a layered =
protocol. If we cannot localize the

    knowledge of delivery addresses, we =
have probably broken the protocol and

    will have to go back and start over =
as soon as the next major evolutionary

    change happens. It appears to me that =
if we have chosen to use UDP and TCP,

    the necessity of having IP and the =
associated IP addresses underneath it

    should be explicitly rejected. Some =
other protocol should be allowed at

    that level if it works better. In the =
same sense that HDLC works best in

    some spaces and Ethernet works better =
in others. If we are keeping the type

    of network hardware separate form the =
application level, it is highly

    illogical that we should expect the =
app to know about changes required for

    mobility. Someone pointed out that =
simultaneous arrival of duplicate frames

    is important for soft handoff. Should =
the SIP application be tasked with

    tracking the transmission delay for =
multiple routes in order to make this

    happen? If we get carried away and =
make the protocol monolithic there will

    be very little chance for it to =
succeed.

    


    Larry

    

    


    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    


    Larry Cox

    Senior Software Engineer

    


    Cirilium =
Inc.            =
Phone: (480) 317-1115

    1615 S. 52 =
St.           =
Fax:   (480) ???-????

    Tempe, AZ =
85281-6233     Web:    =
www.cirilium.com

    USA

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFA54A.6600D7FC--


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 09:51: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 JAA01773
	for ; Thu, 13 Apr 2000 09:51: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 8421E44359; Thu, 13 Apr 2000 09:48:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id C894844355
	for ; Thu, 13 Apr 2000 09:48:47 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA24097;
	Thu, 13 Apr 2000 09:51:26 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA15756; Thu, 13 Apr 2000 09:50:35 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <249MK53R>; Thu, 13 Apr 2000 09:51:25 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Glenn Morrow , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 09:51:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Everyone:

I feel that it will be conflicting if we discuss this in another WG because
of the following:

1. To support mobility in the application layer for session layer, it will
require to extend the SIP.
2. SIP WG  has the sole authority to see whether the extension for mobility
in SIP is consistent with the overall architecture.
3. SIP is the control protocol for all networking environments.

The only thing that I can foresee is: To form a separate sub-group within
the SIP so that SIP WG can see the overall consistency in extensions.

Best regards,

Radhika R. Roy
AT&T

> -----Original Message-----
> From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> Sent:	Thursday, April 13, 2000 9:16 AM
> To:	sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
> 
> I honestly think this topic should be discussed in another WG, which WG is
> something for others (IAB, Area Directors) to decide.
> 
> 	-----Original Message----- 
> From:   Larry Cox [SMTP:lcox@neta.com] 
> Sent:   Wednesday, April 12, 2000 4:20 PM 
> To:     sip@lists.bell-labs.com 
> Subject:        RE: [SIP] SIP and soft hand-off 
> 
> 	Brian Rosen wrote: 
> > ... 
> > 
> >It is entirely inappropriate for any session level protocol, let alone 
> >session establishment protocols, to have knowledge that the end 
> >device is mobile.  It's like having the protocol have to know 
> >whether they are on a LAN or a WAN.  Somewhere, someone cares, 
> >but it shouldn't be SIP! 
> > 
> >Brian 
> 
> 	I am glad that I am not alone. I had begun believing that we had
> lost sight 
> of the objective of having a layered protocol. If we cannot localize the 
> knowledge of delivery addresses, we have probably broken the protocol and 
> will have to go back and start over as soon as the next major evolutionary
> 
> change happens. It appears to me that if we have chosen to use UDP and
> TCP, 
> the necessity of having IP and the associated IP addresses underneath it 
> should be explicitly rejected. Some other protocol should be allowed at 
> that level if it works better. In the same sense that HDLC works best in 
> some spaces and Ethernet works better in others. If we are keeping the
> type 
> of network hardware separate form the application level, it is highly 
> illogical that we should expect the app to know about changes required for
> 
> mobility. Someone pointed out that simultaneous arrival of duplicate
> frames 
> is important for soft handoff. Should the SIP application be tasked with 
> tracking the transmission delay for multiple routes in order to make this 
> happen? If we get carried away and make the protocol monolithic there will
> 
> be very little chance for it to succeed. 
> 
> 	Larry 
> 
> 
> 	====================================== 
> 
> 	Larry Cox 
> Senior Software Engineer 
> 
> 	Cirilium Inc.            Phone: (480) 317-1115 
> 1615 S. 52 St.           Fax:   (480) ???-???? 
> Tempe, AZ 85281-6233     Web:    www.cirilium.com 
> USA 
> 
> 
> 	_______________________________________________ 
> SIP mailing list 
> SIP@lists.bell-labs.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 Apr 13 10: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 KAA02376
	for ; Thu, 13 Apr 2000 10: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 8568A44355; Thu, 13 Apr 2000 10:01:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ren.orange.co.uk (news-gw1.orange.co.uk [193.35.129.99])
	by lists.bell-labs.com (Postfix) with ESMTP id 66D3F4434C
	for ; Thu, 13 Apr 2000 10:01:19 -0400 (EDT)
Received: from ruddick (ruddick.orange.co.uk [172.19.16.129])
	by ren.orange.co.uk (Pro-8.9.3/8.9.3) with SMTP id PAA18338
	for ; Thu, 13 Apr 2000 15:03:57 +0100 (BST)
Received: by ruddick(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 802568C0.004CA46D ; Thu, 13 Apr 2000 14:57:08 +0100
X-Lotus-FromDomain: HTLUK
From: Simon.BARBER@orange.co.uk
To: sip@lists.bell-labs.com
Message-ID: <802568C0.004CA348.00@ruddick>
Date: Thu, 13 Apr 2000 15:12:47 +0100
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] RSVP/SIP problem
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

When building a telephone network a very important factor is GoS - Grade of
Service, i.e. the probability that a call will block due to resources not being
available. I would like to confirm my understanding of how this can happen with
SIP.

If resources for a call are not available the call should block before the
called party is alerted. For this to happen both endpoints must have all the
information they need to know to perform resource reservation before the called
party is alerted, and they should be able to communicate this availability.

Assuming RSVP is going to be used for resource reservation:

These events are required for a reservation: (taken from RSVP rfc)
      H1   A receiver joins the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP Path messages to the
           DestAddress.

      H3   A receiver application receives a Path message.

      H4   A receiver starts sending appropriate Resv messages,
           specifying the desired flow descriptors.

      H5   A sender application receives a Resv message.

      H6   A sender starts sending data packets.

As far as I understand the SIP exchange of INVITE, RINGING does not permit this.

I will look at a point to point full duplex audio call:

The calling end determines the local address to which media should be sent
The calling end sends INVITE, passing the local address to which media should be
sent.
The calling end cannot make any resource reservation yet, since it does not know
the destination address for media
The INVITE is routed to the receiving end of the call.
The receiving end of the call can now send a RSVP path message back to the
calling end to reserve a media path in that direction
The called end determines the local media address where media should be
received.
The called end sends this local address to the calling end via a 183 response
The called end starts alerting

Here is the problem. The called end has started alerting without knowing that
bandwidth has been reserved in the direction from the calling end to the called
end. Potentially when the user picks up the phone only a one way voice path will
be possible.

To solve this problem an ACK to the 183 response, confirming that bandwidth is
available should be sent from the calling end before ringing commences.

regds,

Simon Barber
Orange PCS Ltd




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


From sip-admin@lists.bell-labs.com  Thu Apr 13 10:49:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03766
	for ; Thu, 13 Apr 2000 10:49:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ABEB24434D; Thu, 13 Apr 2000 10:46:13 -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 4E28B44339
	for ; Thu, 13 Apr 2000 10:46:11 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FSY00B4XMGUTR@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 13 Apr 2000 14:48:30 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSY00401MGTEI@dgismtp01.wcomnet.com>;
 Thu, 13 Apr 2000 14:48:29 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSY0034AMGSWE@dgismtp01.wcomnet.com>; Thu,
 13 Apr 2000 14:48:28 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <2V89XCRH>; Thu, 13 Apr 2000 14:48:28 +0000
Content-return: allowed
Date: Thu, 13 Apr 2000 14:48:27 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] RSVP/SIP problem
To: "'Simon.BARBER@orange.co.uk'" ,
        sip@lists.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D83493EF@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Simon,

Please see the following drafts which outline proposals for how to address
the problem you outline:

draft-manyfolks-sip-resource-00.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt

Steve

> -----Original Message-----
> From: Simon.BARBER@orange.co.uk [mailto:Simon.BARBER@orange.co.uk]
> Sent: Thursday, April 13, 2000 9:13 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] RSVP/SIP problem
> 
> 
> When building a telephone network a very important factor is 
> GoS - Grade of
> Service, i.e. the probability that a call will block due to 
> resources not being
> available. I would like to confirm my understanding of how 
> this can happen with
> SIP.
> 
> If resources for a call are not available the call should 
> block before the
> called party is alerted. For this to happen both endpoints 
> must have all the
> information they need to know to perform resource reservation 
> before the called
> party is alerted, and they should be able to communicate this 
> availability.
> 
> Assuming RSVP is going to be used for resource reservation:
> 
> These events are required for a reservation: (taken from RSVP rfc)
>       H1   A receiver joins the multicast group specified by
>            DestAddress, using IGMP.
> 
>       H2   A potential sender starts sending RSVP Path messages to the
>            DestAddress.
> 
>       H3   A receiver application receives a Path message.
> 
>       H4   A receiver starts sending appropriate Resv messages,
>            specifying the desired flow descriptors.
> 
>       H5   A sender application receives a Resv message.
> 
>       H6   A sender starts sending data packets.
> 
> As far as I understand the SIP exchange of INVITE, RINGING 
> does not permit this.
> 
> I will look at a point to point full duplex audio call:
> 
> The calling end determines the local address to which media 
> should be sent
> The calling end sends INVITE, passing the local address to 
> which media should be
> sent.
> The calling end cannot make any resource reservation yet, 
> since it does not know
> the destination address for media
> The INVITE is routed to the receiving end of the call.
> The receiving end of the call can now send a RSVP path 
> message back to the
> calling end to reserve a media path in that direction
> The called end determines the local media address where media 
> should be
> received.
> The called end sends this local address to the calling end 
> via a 183 response
> The called end starts alerting
> 
> Here is the problem. The called end has started alerting 
> without knowing that
> bandwidth has been reserved in the direction from the calling 
> end to the called
> end. Potentially when the user picks up the phone only a one 
> way voice path will
> be possible.
> 
> To solve this problem an ACK to the 183 response, confirming 
> that bandwidth is
> available should be sent from the calling end before ringing 
> commences.
> 
> regds,
> 
> Simon Barber
> Orange PCS Ltd
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 13 11:28: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 LAA04643
	for ; Thu, 13 Apr 2000 11:28: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 8EDA344357; Thu, 13 Apr 2000 11:25:53 -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 ED27644339
	for ; Thu, 13 Apr 2000 11:25:50 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FSY00787OB82H@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 13 Apr 2000 15:28:20 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FSY00101OB7IN@dgismtp01.wcomnet.com>;
 Thu, 13 Apr 2000 15:28:19 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FSY0014NOB75X@dgismtp01.wcomnet.com>; Thu,
 13 Apr 2000 15:28:19 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <2V89X1VA>; Thu, 13 Apr 2000 15:28:19 +0000
Content-return: allowed
Date: Thu, 13 Apr 2000 15:28:16 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] INFO msg call Flows
To: "'Sunitha Kumar'" ,
        SIPbell-labs 
Message-id: <75C79E507864D3118AFC00805FEAB7D83493F0@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_zjJeQYrXl6W1ABRXMHLA+A)"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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.

--Boundary_(ID_zjJeQYrXl6W1ABRXMHLA+A)
Content-type: text/plain; charset=ISO-8859-1

Sunitha,
 
Given that the INFO message can only be used in the context of an existing
session, I'm not so sure that a standalone INFO call flow would be very
useful (much less very interesting, given that it would be a simple INFO,
200 ok exchange, or INFO, 481 exchange if it occurred outside of an existing
session).
 
It might, however, be useful to have a call flow that shows the use of the
INFO message to carry mid-call signaling.
 
This seems like a candidate for the call flow document.  
 
Steve

-----Original Message-----
From: Sunitha Kumar [mailto:skumar@vovida.com]
Sent: Tuesday, April 11, 2000 11:31 PM
To: SIPbell-labs
Subject: [SIP] INFO msg call Flows


Hi : 

Are there any call flows with the INFO method, similar to the ones in the
call flow document. 
  


Thanks! 

-- 

Sunitha Kumar

http://www.vovida.com  
  


--Boundary_(ID_zjJeQYrXl6W1ABRXMHLA+A)
Content-type: text/html; charset=ISO-8859-1









Sunitha,


 


Given 
that the INFO message can only be used in the context of an existing session, 
I'm not so sure that a standalone INFO call flow would be very useful (much less 
very interesting, given that it would be a simple INFO, 200 ok exchange, or 
INFO, 481 exchange if it occurred outside of an existing 
session).


 


It 
might, however, be useful to have a call flow that shows the use of the INFO 
message to carry mid-call signaling.


 


This 
seems like a candidate for the call flow document.  


 


Steve



  
-----Original Message-----
From: Sunitha Kumar 
  [mailto:skumar@vovida.com]
Sent: Tuesday, April 11, 2000 11:31 
  PM
To: SIPbell-labs
Subject: [SIP] INFO msg call 
  Flows

Hi : 
  
Are there any call flows with the INFO method, similar to the ones in the 
  call flow document. 
  
  
Thanks! 
-- 
Sunitha Kumar
http://www.vovida.com
  



--Boundary_(ID_zjJeQYrXl6W1ABRXMHLA+A)--


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 12:04: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 MAA05492
	for ; Thu, 13 Apr 2000 12:04: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 3753644368; Thu, 13 Apr 2000 12:01:41 -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 F2E3944337
	for ; Thu, 13 Apr 2000 12:01:36 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Thu, 13 Apr 2000 10:15:25 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <25JK3KPK>; Thu, 13 Apr 2000 10:11:56 -0500
Message-ID: 
From: "Glenn Morrow" 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 10:11:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA55A.9B4737DE"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFA55A.9B4737DE
Content-Type: text/plain;
	charset="ISO-8859-1"

While this is pretty much the current state of affairs, I would like to
point out even the SIP terminal mobility solution affects more than one
protocol. 

Changes to both SIP and to DHCP and I suspect IP itself are needed. The IETF
also standardizes PPP extensions for address assignment and agent discovery,
etc.. 

Address assignment, VPN support, NATs, Firewalls, policy metrics, multicast
and routing in general are all affected by the mobility solution. 

The point is that mobility solutions can affect more than one protocol. 

The decomposition of a PSTN gateway has led us to the advantage of this
particular solution for a particular business case - namely legacy
circuit-based cellular. This same decomposition led us into Megaco I might
add.

If the IAB wants to solve just this business case, then so be it. If they
want to do more then so be it. Either way more than one protocol is
affected. Right now the solution is being worked adhoc in multiple WGs. 

If this is the correct way to proceed, I have no problem with it. 



> -----Original Message-----
> From:	Roy, Radhika R, ALARC [SMTP:rrroy@att.com]
> Sent:	Thursday, April 13, 2000 8:51 AM
> To:	Morrow, Glenn [RICH2:C301:EXCH]; sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
> 
> Hi, Everyone:
> 
> I feel that it will be conflicting if we discuss this in another WG
> because
> of the following:
> 
> 1. To support mobility in the application layer for session layer, it will
> require to extend the SIP.
> 2. SIP WG  has the sole authority to see whether the extension for
> mobility
> in SIP is consistent with the overall architecture.
> 3. SIP is the control protocol for all networking environments.
> 
> The only thing that I can foresee is: To form a separate sub-group within
> the SIP so that SIP WG can see the overall consistency in extensions.
> 
> Best regards,
> 
> Radhika R. Roy
> AT&T
> 
> > -----Original Message-----
> > From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> > Sent:	Thursday, April 13, 2000 9:16 AM
> > To:	sip@lists.bell-labs.com
> > Subject:	RE: [SIP] SIP and soft hand-off
> > 
> > I honestly think this topic should be discussed in another WG, which WG
> is
> > something for others (IAB, Area Directors) to decide.
> > 
> > 	-----Original Message----- 
> > From:   Larry Cox [SMTP:lcox@neta.com] 
> > Sent:   Wednesday, April 12, 2000 4:20 PM 
> > To:     sip@lists.bell-labs.com 
> > Subject:        RE: [SIP] SIP and soft hand-off 
> > 
> > 	Brian Rosen wrote: 
> > > ... 
> > > 
> > >It is entirely inappropriate for any session level protocol, let alone 
> > >session establishment protocols, to have knowledge that the end 
> > >device is mobile.  It's like having the protocol have to know 
> > >whether they are on a LAN or a WAN.  Somewhere, someone cares, 
> > >but it shouldn't be SIP! 
> > > 
> > >Brian 
> > 
> > 	I am glad that I am not alone. I had begun believing that we had
> > lost sight 
> > of the objective of having a layered protocol. If we cannot localize the
> 
> > knowledge of delivery addresses, we have probably broken the protocol
> and 
> > will have to go back and start over as soon as the next major
> evolutionary
> > 
> > change happens. It appears to me that if we have chosen to use UDP and
> > TCP, 
> > the necessity of having IP and the associated IP addresses underneath it
> 
> > should be explicitly rejected. Some other protocol should be allowed at 
> > that level if it works better. In the same sense that HDLC works best in
> 
> > some spaces and Ethernet works better in others. If we are keeping the
> > type 
> > of network hardware separate form the application level, it is highly 
> > illogical that we should expect the app to know about changes required
> for
> > 
> > mobility. Someone pointed out that simultaneous arrival of duplicate
> > frames 
> > is important for soft handoff. Should the SIP application be tasked with
> 
> > tracking the transmission delay for multiple routes in order to make
> this 
> > happen? If we get carried away and make the protocol monolithic there
> will
> > 
> > be very little chance for it to succeed. 
> > 
> > 	Larry 
> > 
> > 
> > 	====================================== 
> > 
> > 	Larry Cox 
> > Senior Software Engineer 
> > 
> > 	Cirilium Inc.            Phone: (480) 317-1115 
> > 1615 S. 52 St.           Fax:   (480) ???-???? 
> > Tempe, AZ 85281-6233     Web:    www.cirilium.com 
> > USA 
> > 
> > 
> > 	_______________________________________________ 
> > SIP mailing list 
> > SIP@lists.bell-labs.com 
> >  
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFA55A.9B4737DE
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SIP and soft hand-off




While this is pretty =
much the current state of affairs, I would like to point out even the =
SIP terminal mobility solution affects more than one protocol. =




Changes to both SIP =
and to DHCP and I suspect IP itself are needed. The IETF also =
standardizes PPP extensions for address assignment and agent discovery, =
etc.. 



Address assignment, =
VPN support, NATs, Firewalls, policy metrics, multicast and routing in =
general are all affected by the mobility solution. 



The point is that =
mobility solutions can affect more than one protocol. 




The decomposition of =
a PSTN gateway has led us to the advantage of this particular solution =
for a particular business case - namely legacy circuit-based cellular. =
This same decomposition led us into Megaco I might add.



If the IAB wants to =
solve just this business case, then so be it. If they want to do more =
then so be it. Either way more than one protocol is affected. Right now =
the solution is being worked adhoc in multiple WGs. 



If this is the =
correct way to proceed, I have no problem with it. 







    

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

    From:   Roy, Radhika R, ALARC =
[SMTP:rrroy@att.com]

    Sent:   Thursday, April 13, 2000 8:51 AM

    To:     Morrow, Glenn [RICH2:C301:EXCH]; =
sip@lists.bell-labs.com

    Subject:       =
 RE: [SIP] SIP and soft =
hand-off

    


    Hi, Everyone:

    


    I feel that it will be conflicting if =
we discuss this in another WG because

    of the following:

    


    1. To support mobility in the =
application layer for session layer, it will

    require to extend the SIP.

    2. SIP WG  has the sole =
authority to see whether the extension for mobility

    in SIP is consistent with the overall =
architecture.

    3. SIP is the control protocol for =
all networking environments.

    


    The only thing that I can foresee is: =
To form a separate sub-group within

    the SIP so that SIP WG can see the =
overall consistency in extensions.

    


    Best regards,

    


    Radhika R. Roy

    AT&T

    


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

    > From: Glenn Morrow =
[SMTP:gmorrow@nortelnetworks.com]

    > Sent: Thursday, April 13, 2000 =
9:16 AM

    > To:   =
sip@lists.bell-labs.com

    > =
Subject:      RE: [SIP] SIP and soft =
hand-off

    > 

    > I honestly think this topic =
should be discussed in another WG, which WG is

    > something for others (IAB, Area =
Directors) to decide.

    > 

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

    > From:   Larry Cox =
[SMTP:lcox@neta.com] 

    > Sent:   Wednesday, =
April 12, 2000 4:20 PM 

    > To:     =
sip@lists.bell-labs.com 

    > =
Subject:        RE: [SIP] SIP and =
soft hand-off 

    > 

    >       =
Brian Rosen wrote: 

    > > ... 

    > > 

    > >It is entirely inappropriate =
for any session level protocol, let alone 

    > >session establishment =
protocols, to have knowledge that the end 

    > >device is mobile.  It's =
like having the protocol have to know 

    > >whether they are on a LAN or =
a WAN.  Somewhere, someone cares, 

    > >but it shouldn't be SIP! =


    > > 

    > >Brian 

    > 

    >       I =
am glad that I am not alone. I had begun believing that we had

    > lost sight 

    > of the objective of having a =
layered protocol. If we cannot localize the 

    > knowledge of delivery addresses, =
we have probably broken the protocol and 

    > will have to go back and start =
over as soon as the next major evolutionary

    > 

    > change happens. It appears to me =
that if we have chosen to use UDP and

    > TCP, 

    > the necessity of having IP and =
the associated IP addresses underneath it 

    > should be explicitly rejected. =
Some other protocol should be allowed at 

    > that level if it works better. =
In the same sense that HDLC works best in 

    > some spaces and Ethernet works =
better in others. If we are keeping the

    > type 

    > of network hardware separate =
form the application level, it is highly 

    > illogical that we should expect =
the app to know about changes required for

    > 

    > mobility. Someone pointed out =
that simultaneous arrival of duplicate

    > frames 

    > is important for soft handoff. =
Should the SIP application be tasked with 

    > tracking the transmission delay =
for multiple routes in order to make this 

    > happen? If we get carried away =
and make the protocol monolithic there will

    > 

    > be very little chance for it to =
succeed. 

    > 

    >       =
Larry 

    > 

    > 

    >       =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 

    > 

    >       =
Larry Cox 

    > Senior Software Engineer 

    > 

    >       =
Cirilium =
Inc.            =
Phone: (480) 317-1115 

    > 1615 S. 52 =
St.           =
Fax:   (480) ???-???? 

    > Tempe, AZ =
85281-6233     Web:    =
www.cirilium.com 

    > USA 

    > 

    > 

    >       =
_______________________________________________ 

    > SIP mailing list 

    > SIP@lists.bell-labs.com 

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

    > 

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFA55A.9B4737DE--


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 12:06: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 MAA05622
	for ; Thu, 13 Apr 2000 12:06: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 77DAE4436E; Thu, 13 Apr 2000 12:01:45 -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 037D04434C
	for ; Thu, 13 Apr 2000 12:01:37 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Thu, 13 Apr 2000 10:14:01 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <25JK3K33>; Thu, 13 Apr 2000 10:11:06 -0500
Message-ID: 
From: "Glenn Morrow" 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 10:11:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA55A.7CA33F3A"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFA55A.7CA33F3A
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

From my understanding the SIP terminal mobility solution does not =
require
changes to every application even without dynamic DNS updates. This is =
a
common misconception.=20

Perhaps Hennning or someone could describe the interactions when =
someone
wants to FTP to another IP based terminal with a mobile user. Will FTP =
have
to change?

> -----Original Message-----
> From:	Rosen, Brian [SMTP:brosen@fore.com]
> Sent:	Wednesday, April 12, 2000 3:50 PM
> To:	'Dean Willis'; Stephen Terrill; Baba, S.
> Cc:	sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
>=20
> I understand what you want to do.  I like it.
> I don't like saying that because your IP address changed,
> ALL application level protocols have to know about it.
>=20
> If that's what you want to do, let's purge the app level
> protocols of the part that changes, even if we have to add a layer
> somewhere.  It SHOULD NOT require changes in EVERY protocol
> to make real mobility work. =20
>=20
> That is the basic issue I see with the flurry of mobility efforts.
> These guys are EVERYWHERE telling us that we have to change what we
> are doing in order to accommodate mobility.  There isn't a protocol
> effort I'm involved in that doesn't have a cadre of people trying
> to get something in it to make mobility work.
>=20
> That is just plain wrong.  If mobility is, or is about to be,
> ubiquitous, then we should change IP if we have to.  We should not
> change SIP, LDAP, COPS, ISUP, DNS, NTP, HTTP, FTP, RADIUS,
> and every other protocol we really use. =20
>=20
> It is entirely inappropriate for any session level protocol, let =
alone
> session establishment protocols, to have knowledge that the end
> device is mobile.  It's like having the protocol have to know
> whether they are on a LAN or a WAN.  Somewhere, someone cares,
> but it shouldn't be SIP!
>=20
> Brian
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@wcom.com]
> > Sent: Wednesday, April 12, 2000 3:49 PM
> > To: Stephen Terrill; Baba, S.
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] SIP and soft hand-off
> >=20
> >=20
> >=20
> > One can envision a layer-2 hand off, a layer-3 (mobile-IP)=20
> > hand off, or a
> > layer-4 handoff . . .
> >=20
> > This mobility approach seems to me to be appropriate to a=20
> > layer-4 handoff,
> > wherein the IP address actually changes. This has=20
> > applicability outside
> > classic mobilephone. For example, when I undock my PC, I might want =
to
> > switch from my wired 100TX card to my wireless 802.11 card.=20
> > Both can be
> > active during handoff -- then I shut down the wired card and =
undock.
> >=20
> > --
> > Dean
> >=20
> > > -----Original Message-----
> > > From: sip-admin@lists.bell-labs.com
> > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stephen =
Terrill
> > > Sent: Wednesday, April 12, 2000 4:13 AM
> > > To: Baba, S.
> > > Cc: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] SIP and soft hand-off
> > >
> > >
> > > Hi Baba,
> > >
> > > I am not sure that I understand the requirements as discussed
> > > here.  I understand that the technology independance requirement,
> > > and quite like that, however I don=B4t understand the need of the
> > > SIP protocol level to be involved in the Soft hand-off.  I would
> > > have expected that the soft hand-off would be entirely within the
> > > "access network" (the mobile network technology), from the
> > > prespective of the SIP applications.  As such, the application
> > > shouldn=B4t even be aware of the hand-overs (won=B4t even=20
> > change IP address).
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Baba, S." wrote:
> > >
> > > > Folks,
> > > >
> > > > Thank you for your attention to my presentation of
> > > > our mobility management requirement in Adelaide.
> > > >
> > > > Let me add a brief explanation about a relation between
> > > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > > raised questions well. Please read the related part (4.1)
> > > > of our revised draft  also.
> > > >
> > > > First, we believe that the requirement wireless
> > > > 'technology-independent" is very important principle.
> > > > At the same time, the soft hand-off is one of the key
> > > > technology promising high efficiency for the CDMA-based
> > > > wireless system. So any protocol on top of the wireless
> > > > shall not break the soft hand-off capability in the
> > > > wireless part. These are our basic assumptions.
> > > >
> > > > The soft hand-off has some aspects like giving smooth hand-off
> > > > taking several tens seconds or more for the radio path change
> > > > and giving more than one radio paths during the hand-off.
> > > > If the soft hand-off is handled in the L2 only or below
> > > > L3 and doesn't affect the upper layer process, it is no
> > > > problem with SIP.
> > > >
> > > > But if we consider the future RAN using IP transport,
> > > > SIP User Agent and/or Proxy Server may need a process
> > > > to support the mobility management on top of the soft hand-off.
> > > > Because SIP controls smooth hand-off of its IP sessions.
> > > >
> > > > Although the details are still open issues, this is the
> > > > basic consideration about the soft hand-off.
> > > > Any questions and comments are welcomed.
> > > >
> > > > Thank you.
> > > >
> > > > Baba//
> > > > -----
> > > > Shinichi Baba
> > > > Toshiba America Research, Inc. (TARI)
> > > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > > Email: sbaba@tari.toshiba.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
> > >
> >=20
> >=20
> >=20
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >=20
>=20
>=20
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFA55A.7CA33F3A
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SIP and soft hand-off




From my =
understanding the SIP terminal mobility solution does not require =
changes to every application even without dynamic DNS updates. This is =
a common misconception. 



Perhaps Hennning or =
someone could describe the interactions when someone wants to FTP to =
another IP based terminal with a mobile user. Will FTP have to =
change?


    

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

    From:   Rosen, Brian [SMTP:brosen@fore.com]

    Sent:   Wednesday, April 12, 2000 3:50 PM

    To:     'Dean Willis'; Stephen Terrill; Baba, S.

    Cc:     sip@lists.bell-labs.com

    Subject:       =
 RE: [SIP] SIP and soft =
hand-off

    


    I understand what you want to =
do.  I like it.

    I don't like saying that because your =
IP address changed,

    ALL application level protocols have =
to know about it.

    


    If that's what you want to do, let's =
purge the app level

    protocols of the part that changes, =
even if we have to add a layer

    somewhere.  It SHOULD NOT =
require changes in EVERY protocol

    to make real mobility work.  =


    


    That is the basic issue I see with the =
flurry of mobility efforts.

    These guys are EVERYWHERE telling us =
that we have to change what we

    are doing in order to accommodate =
mobility.  There isn't a protocol

    effort I'm involved in that doesn't =
have a cadre of people trying

    to get something in it to make =
mobility work.

    


    That is just plain wrong.  If =
mobility is, or is about to be,

    ubiquitous, then we should change IP =
if we have to.  We should not

    change SIP, LDAP, COPS, ISUP, DNS, =
NTP, HTTP, FTP, RADIUS,

    and every other protocol we really =
use.  

    


    It is entirely inappropriate for any =
session level protocol, let alone

    session establishment protocols, to =
have knowledge that the end

    device is mobile.  It's like =
having the protocol have to know

    whether they are on a LAN or a =
WAN.  Somewhere, someone cares,

    but it shouldn't be SIP!

    


    Brian

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

    Brian Rosen, Principal =
Engineer

    Marconi (Formerly FORE =
Systems)

    1000 FORE Drive, Warrendale, PA =
15086

    (724) 742-6826  =
mailto:brosen@eng.fore.com 

    

    

    


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

    > From: Dean Willis =
[mailto:dean.willis@wcom.com]

    > Sent: Wednesday, April 12, 2000 =
3:49 PM

    > To: Stephen Terrill; Baba, =
S.

    > Cc: =
sip@lists.bell-labs.com

    > Subject: RE: [SIP] SIP and soft =
hand-off

    > 

    > 

    > 

    > One can envision a layer-2 hand =
off, a layer-3 (mobile-IP) 

    > hand off, or a

    > layer-4 handoff . . .

    > 

    > This mobility approach seems to =
me to be appropriate to a 

    > layer-4 handoff,

    > wherein the IP address actually =
changes. This has 

    > applicability outside

    > classic mobilephone. For =
example, when I undock my PC, I might want to

    > switch from my wired 100TX card =
to my wireless 802.11 card. 

    > Both can be

    > active during handoff -- then I =
shut down the wired card and undock.

    > 

    > --

    > Dean

    > 

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

    > > From: =
sip-admin@lists.bell-labs.com

    > > [mailto:sip-admin@lists.bel=
l-labs.com]On Behalf Of =
Stephen Terrill

    > > Sent: Wednesday, April 12, =
2000 4:13 AM

    > > To: Baba, S.

    > > Cc: =
sip@lists.bell-labs.com

    > > Subject: Re: [SIP] SIP and =
soft hand-off

    > >

    > >

    > > Hi Baba,

    > >

    > > I am not sure that I =
understand the requirements as discussed

    > > here.  I understand =
that the technology independance requirement,

    > > and quite like that, =
however I don=B4t understand the need of the

    > > SIP protocol level to be =
involved in the Soft hand-off.  I would

    > > have expected that the soft =
hand-off would be entirely within the

    > > "access network" =
(the mobile network technology), from the

    > > prespective of the SIP =
applications.  As such, the application

    > > shouldn=B4t even be aware =
of the hand-overs (won=B4t even 

    > change IP address).

    > >

    > > Regards,

    > >

    > > ..//steve

    > >

    > > "Baba, S." =
wrote:

    > >

    > > > Folks,

    > > >

    > > > Thank you for your =
attention to my presentation of

    > > > our mobility =
management requirement in Adelaide.

    > > >

    > > > Let me add a brief =
explanation about a relation between

    > > > SIP and wireless soft =
hand-off, since I feel I didn't answer

    > > > raised questions well. =
Please read the related part (4.1)

    > > > of our revised draft =
<draft-itsumo-sip-mobility-req-01> also.

    > > >

    > > > First, we believe that =
the requirement wireless

    > > > =
'technology-independent" is very important principle.

    > > > At the same time, the =
soft hand-off is one of the key

    > > > technology promising =
high efficiency for the CDMA-based

    > > > wireless system. So =
any protocol on top of the wireless

    > > > shall not break the =
soft hand-off capability in the

    > > > wireless part. These =
are our basic assumptions.

    > > >

    > > > The soft hand-off has =
some aspects like giving smooth hand-off

    > > > taking several tens =
seconds or more for the radio path change

    > > > and giving more than =
one radio paths during the hand-off.

    > > > If the soft hand-off =
is handled in the L2 only or below

    > > > L3 and doesn't affect =
the upper layer process, it is no

    > > > problem with =
SIP.

    > > >

    > > > But if we consider the =
future RAN using IP transport,

    > > > SIP User Agent and/or =
Proxy Server may need a process

    > > > to support the =
mobility management on top of the soft hand-off.

    > > > Because SIP controls =
smooth hand-off of its IP sessions.

    > > >

    > > > Although the details =
are still open issues, this is the

    > > > basic consideration =
about the soft hand-off.

    > > > Any questions and =
comments are welcomed.

    > > >

    > > > Thank you.

    > > >

    > > > Baba//

    > > > -----

    > > > Shinichi Baba

    > > > Toshiba America =
Research, Inc. (TARI)

    > > > Mail-To: P.O.Box 136 =
Convent Station, NJ 07961-0136

    > > > Location: 445 South =
St. Suite 1B259B, Morristown, NJ 07960

    > > > Phone: (973) 829-4795/ =
Fax: (973) 829-5601

    > > > Email: =
sbaba@tari.toshiba.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

    




------_=_NextPart_001_01BFA55A.7CA33F3A--


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 12:23:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06156
	for ; Thu, 13 Apr 2000 12:23:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 41F6044366; Thu, 13 Apr 2000 12:20:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 7004944350
	for ; Thu, 13 Apr 2000 12:20:12 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA06360;
	Thu, 13 Apr 2000 12:22:52 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA12488; Thu, 13 Apr 2000 12:22:01 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <2ZA5S1XK>; Thu, 13 Apr 2000 12:22:52 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Glenn Morrow , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 12:22:45 -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:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Everyone:

We are concentrating to extend SIP to support mobility - I guess that it
clear. It is an application protocol. SIP WG is chartered for this because
SIP is applicable for all networking communications environments.

Even now, we are discussing SIP in the context of NATs, firewalls, etc.
whether there is a mobility or not. It is the nature of on-going standard
works because people like to use it in many situations. In fact, it is a
healthy state of business because it proves the popularity of SIP to be a
real one - not just niche market.

Let us NOT predict something based on unnecessary fear. Today, we are taking
care-of how SIP's extensions are affecting the works of MMUSIC, IPTEL, etc.
It is a nature of standard works. We have not even decided what needs in SIP
to support mobility. Once we know this, we will go step by step as we do for
other cases.

In SIP WG, we will concentrate for extensions of SIP to support mobility
only.

Hope this will further clarify.

Best regards,
Radhika R. Roy
AT&T

PS: MEGACO is different story - it is a stand-alone case all by itself. It
can be used by SIP if needed. 

> -----Original Message-----
> From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> Sent:	Thursday, April 13, 2000 11:12 AM
> To:	sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
> 
> While this is pretty much the current state of affairs, I would like to
> point out even the SIP terminal mobility solution affects more than one
> protocol. 
> 
> Changes to both SIP and to DHCP and I suspect IP itself are needed. The
> IETF also standardizes PPP extensions for address assignment and agent
> discovery, etc.. 
> 
> Address assignment, VPN support, NATs, Firewalls, policy metrics,
> multicast and routing in general are all affected by the mobility
> solution. 
> 
> The point is that mobility solutions can affect more than one protocol. 
> 
> The decomposition of a PSTN gateway has led us to the advantage of this
> particular solution for a particular business case - namely legacy
> circuit-based cellular. This same decomposition led us into Megaco I might
> add.
> 
> If the IAB wants to solve just this business case, then so be it. If they
> want to do more then so be it. Either way more than one protocol is
> affected. Right now the solution is being worked adhoc in multiple WGs. 
> 
> If this is the correct way to proceed, I have no problem with it. 
> 
> 
> 
> 	-----Original Message----- 
> From:   Roy, Radhika R, ALARC [SMTP:rrroy@att.com] 
> Sent:   Thursday, April 13, 2000 8:51 AM 
> To:     Morrow, Glenn [RICH2:C301:EXCH]; sip@lists.bell-labs.com 
> Subject:        RE: [SIP] SIP and soft hand-off 
> 
> 	Hi, Everyone: 
> 
> 	I feel that it will be conflicting if we discuss this in another WG
> because 
> of the following: 
> 
> 	1. To support mobility in the application layer for session layer,
> it will 
> require to extend the SIP. 
> 2. SIP WG  has the sole authority to see whether the extension for
> mobility 
> in SIP is consistent with the overall architecture. 
> 3. SIP is the control protocol for all networking environments. 
> 
> 	The only thing that I can foresee is: To form a separate sub-group
> within 
> the SIP so that SIP WG can see the overall consistency in extensions. 
> 
> 	Best regards, 
> 
> 	Radhika R. Roy 
> AT&T 
> 
> 	> -----Original Message----- 
> > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] 
> > Sent: Thursday, April 13, 2000 9:16 AM 
> > To:   sip@lists.bell-labs.com 
> > Subject:      RE: [SIP] SIP and soft hand-off 
> > 
> > I honestly think this topic should be discussed in another WG, which WG
> is 
> > something for others (IAB, Area Directors) to decide. 
> > 
> >       -----Original Message----- 
> > From:   Larry Cox [SMTP:lcox@neta.com] 
> > Sent:   Wednesday, April 12, 2000 4:20 PM 
> > To:     sip@lists.bell-labs.com 
> > Subject:        RE: [SIP] SIP and soft hand-off 
> > 
> >       Brian Rosen wrote: 
> > > ... 
> > > 
> > >It is entirely inappropriate for any session level protocol, let alone 
> > >session establishment protocols, to have knowledge that the end 
> > >device is mobile.  It's like having the protocol have to know 
> > >whether they are on a LAN or a WAN.  Somewhere, someone cares, 
> > >but it shouldn't be SIP! 
> > > 
> > >Brian 
> > 
> >       I am glad that I am not alone. I had begun believing that we had 
> > lost sight 
> > of the objective of having a layered protocol. If we cannot localize the
> 
> > knowledge of delivery addresses, we have probably broken the protocol
> and 
> > will have to go back and start over as soon as the next major
> evolutionary 
> > 
> > change happens. It appears to me that if we have chosen to use UDP and 
> > TCP, 
> > the necessity of having IP and the associated IP addresses underneath it
> 
> > should be explicitly rejected. Some other protocol should be allowed at 
> > that level if it works better. In the same sense that HDLC works best in
> 
> > some spaces and Ethernet works better in others. If we are keeping the 
> > type 
> > of network hardware separate form the application level, it is highly 
> > illogical that we should expect the app to know about changes required
> for 
> > 
> > mobility. Someone pointed out that simultaneous arrival of duplicate 
> > frames 
> > is important for soft handoff. Should the SIP application be tasked with
> 
> > tracking the transmission delay for multiple routes in order to make
> this 
> > happen? If we get carried away and make the protocol monolithic there
> will 
> > 
> > be very little chance for it to succeed. 
> > 
> >       Larry 
> > 
> > 
> >       ====================================== 
> > 
> >       Larry Cox 
> > Senior Software Engineer 
> > 
> >       Cirilium Inc.            Phone: (480) 317-1115 
> > 1615 S. 52 St.           Fax:   (480) ???-???? 
> > Tempe, AZ 85281-6233     Web:    www.cirilium.com 
> > USA 
> > 
> > 
> >       _______________________________________________ 
> > SIP mailing list 
> > SIP@lists.bell-labs.com 
> > < > 
> > 
> 
> 
> 	_______________________________________________ 
> SIP mailing list 
> SIP@lists.bell-labs.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 Apr 13 12: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 MAA07096
	for ; Thu, 13 Apr 2000 12: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 B34C94435D; Thu, 13 Apr 2000 12:34:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sand.global.net.uk (sand.global.net.uk [195.147.248.109])
	by lists.bell-labs.com (Postfix) with ESMTP id AD4E64434C
	for ; Thu, 13 Apr 2000 12:33:58 -0400 (EDT)
Received: from pd6s10a07.client.global.net.uk ([195.147.234.215] helo=isdn-comms.co.uk)
	by sand.global.net.uk with esmtp (Exim 2.05 #1)
	id 12fmWI-0002r6-01; Thu, 13 Apr 2000 17:31:07 +0100
Received: from isdn-comms.co.uk [169.254.128.4] by isdn-comms.co.uk (FTGate 2, 2, 0, 1);
     Thu, 13 Apr 00 17:28:15 +0100
Message-ID: <38F5F57E.FC9B0C55@isdn-comms.co.uk>
Date: Thu, 13 Apr 2000 17:27:42 +0100
From: Chris Wayman Purvis 
Organization: ISDN Communications Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Roy, Radhika R, ALARC" 
Cc: Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and soft hand-off
References: 
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07096

Radhika,

Would you like to take this view back to the ITU (SG16), where you disagreed
with the same point when I made it about H.323 to try to save people the vast
amounts of unnecessary work they're doing there on mobility?

Regards,
Chris

"Roy, Radhika R, ALARC" wrote:
> 
> Hi, Baba and Steve:
> 
> I guess that Steve is right.
> 
> Let us keep the activities of the lower layer (e.g., link/network) separate
> from the application layer (e.g., SIP) as far as practicable.
> 
> For example, if the network layer address (e.g., IP address) is not changed
> during the soft-handover why should we bring that abstraction to the
> application layer (e.g., SIP)?
> 
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy@att.com
> 
> > -----Original Message-----
> > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> > Sent: Wednesday, April 12, 2000 5:13 AM
> > To:   Baba, S.
> > Cc:   sip@lists.bell-labs.com
> > Subject:      Re: [SIP] SIP and soft hand-off
> >
> > Hi Baba,
> >
> > I am not sure that I understand the requirements as discussed here.  I
> > understand that the technology independance requirement, and quite like
> > that, however I don´t understand the need of the SIP protocol level to be
> > involved in the Soft hand-off.  I would have expected that the soft
> > hand-off would be entirely within the "access network" (the mobile network
> > technology), from the prespective of the SIP applications.  As such, the
> > application shouldn´t even be aware of the hand-overs (won´t even change
> > IP address).
> >
> > Regards,
> >
> > ..//steve
> >
> > "Baba, S." wrote:
> >
> > > Folks,
> > >
> > > Thank you for your attention to my presentation of
> > > our mobility management requirement in Adelaide.
> > >
> > > Let me add a brief explanation about a relation between
> > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > raised questions well. Please read the related part (4.1)
> > > of our revised draft  also.
> > >
> > > First, we believe that the requirement wireless
> > > 'technology-independent" is very important principle.
> > > At the same time, the soft hand-off is one of the key
> > > technology promising high efficiency for the CDMA-based
> > > wireless system. So any protocol on top of the wireless
> > > shall not break the soft hand-off capability in the
> > > wireless part. These are our basic assumptions.
> > >
> > > The soft hand-off has some aspects like giving smooth hand-off
> > > taking several tens seconds or more for the radio path change
> > > and giving more than one radio paths during the hand-off.
> > > If the soft hand-off is handled in the L2 only or below
> > > L3 and doesn't affect the upper layer process, it is no
> > > problem with SIP.
> > >
> > > But if we consider the future RAN using IP transport,
> > > SIP User Agent and/or Proxy Server may need a process
> > > to support the mobility management on top of the soft hand-off.
> > > Because SIP controls smooth hand-off of its IP sessions.
> > >
> > > Although the details are still open issues, this is the
> > > basic consideration about the soft hand-off.
> > > Any questions and comments are welcomed.
> > >
> > > Thank you.
> > >
> > > Baba//
> > > -----
> > > Shinichi Baba
> > > Toshiba America Research, Inc. (TARI)
> > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > Email: sbaba@tari.toshiba.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

-- 
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 12:50: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 MAA07536
	for ; Thu, 13 Apr 2000 12:50: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 127F344373; Thu, 13 Apr 2000 12:47:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 7705E44350
	for ; Thu, 13 Apr 2000 12:47:16 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA17078;
	Thu, 13 Apr 2000 12:49:48 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA24090; Thu, 13 Apr 2000 12:48:56 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <249MLR8Z>; Thu, 13 Apr 2000 12:49:46 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Chris Wayman Purvis 
Cc: Stephen Terrill ,
        "Baba, S." , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 12:49:42 -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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07536

Chris:

I disagreed with you that we should not keep our solution assuming that all
mobility related things will be transparent to the appln. (e.g., H.323)
layer.

The work H.323 mobility is going-on. All renown companies that are building
mobility related equipment throughout the world are a part of it.

Now there are internet-drafts related to SIP mobility as well.

Let me clarify: If the network point of attachment is NOT changed, there is
almost (some non-real-time mobility management may be needed) no need to do
anything in the application layer (e.g., SIP, H.323). But it is only a
special situation.

In many situations, it may not be possible. We are addressing those from
mobility management point of view. There can be two aspects of this: 1.
Should we consider hand-off in the appln layer? 2. Should we consider NO
handoff in the appln layer?

I hope that we could agree that the mobility solution would be transparent
to the application layer (we could save our time)!

Best regards,
Radhika

> -----Original Message-----
> From:	Chris Wayman Purvis [SMTP:cwp@isdn-comms.co.uk]
> Sent:	Thursday, April 13, 2000 12:28 PM
> To:	Roy, Radhika R, ALARC
> Cc:	Stephen Terrill; Baba, S.; sip@lists.bell-labs.com
> Subject:	Re: [SIP] SIP and soft hand-off
> 
> Radhika,
> 
> Would you like to take this view back to the ITU (SG16), where you
> disagreed
> with the same point when I made it about H.323 to try to save people the
> vast
> amounts of unnecessary work they're doing there on mobility?
> 
> Regards,
> Chris
> 
> "Roy, Radhika R, ALARC" wrote:
> > 
> > Hi, Baba and Steve:
> > 
> > I guess that Steve is right.
> > 
> > Let us keep the activities of the lower layer (e.g., link/network)
> separate
> > from the application layer (e.g., SIP) as far as practicable.
> > 
> > For example, if the network layer address (e.g., IP address) is not
> changed
> > during the soft-handover why should we bring that abstraction to the
> > application layer (e.g., SIP)?
> > 
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > +1 732 420 1580
> > rrroy@att.com
> > 
> > > -----Original Message-----
> > > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com]
> > > Sent: Wednesday, April 12, 2000 5:13 AM
> > > To:   Baba, S.
> > > Cc:   sip@lists.bell-labs.com
> > > Subject:      Re: [SIP] SIP and soft hand-off
> > >
> > > Hi Baba,
> > >
> > > I am not sure that I understand the requirements as discussed here.  I
> > > understand that the technology independance requirement, and quite
> like
> > > that, however I don´t understand the need of the SIP protocol level to
> be
> > > involved in the Soft hand-off.  I would have expected that the soft
> > > hand-off would be entirely within the "access network" (the mobile
> network
> > > technology), from the prespective of the SIP applications.  As such,
> the
> > > application shouldn´t even be aware of the hand-overs (won´t even
> change
> > > IP address).
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Baba, S." wrote:
> > >
> > > > Folks,
> > > >
> > > > Thank you for your attention to my presentation of
> > > > our mobility management requirement in Adelaide.
> > > >
> > > > Let me add a brief explanation about a relation between
> > > > SIP and wireless soft hand-off, since I feel I didn't answer
> > > > raised questions well. Please read the related part (4.1)
> > > > of our revised draft  also.
> > > >
> > > > First, we believe that the requirement wireless
> > > > 'technology-independent" is very important principle.
> > > > At the same time, the soft hand-off is one of the key
> > > > technology promising high efficiency for the CDMA-based
> > > > wireless system. So any protocol on top of the wireless
> > > > shall not break the soft hand-off capability in the
> > > > wireless part. These are our basic assumptions.
> > > >
> > > > The soft hand-off has some aspects like giving smooth hand-off
> > > > taking several tens seconds or more for the radio path change
> > > > and giving more than one radio paths during the hand-off.
> > > > If the soft hand-off is handled in the L2 only or below
> > > > L3 and doesn't affect the upper layer process, it is no
> > > > problem with SIP.
> > > >
> > > > But if we consider the future RAN using IP transport,
> > > > SIP User Agent and/or Proxy Server may need a process
> > > > to support the mobility management on top of the soft hand-off.
> > > > Because SIP controls smooth hand-off of its IP sessions.
> > > >
> > > > Although the details are still open issues, this is the
> > > > basic consideration about the soft hand-off.
> > > > Any questions and comments are welcomed.
> > > >
> > > > Thank you.
> > > >
> > > > Baba//
> > > > -----
> > > > Shinichi Baba
> > > > Toshiba America Research, Inc. (TARI)
> > > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
> > > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
> > > > Phone: (973) 829-4795/ Fax: (973) 829-5601
> > > > Email: sbaba@tari.toshiba.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
> 
> -- 
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> Phone: +44 1344 899 007
> Fax:   +44 1344 899 001


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 12:55: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 MAA07761
	for ; Thu, 13 Apr 2000 12:55: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 2B2CB4434C; Thu, 13 Apr 2000 12:53:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ren.orange.co.uk (news-gw1.orange.co.uk [193.35.129.99])
	by lists.bell-labs.com (Postfix) with ESMTP id EF8EE4434C
	for ; Thu, 13 Apr 2000 09:55:59 -0400 (EDT)
Received: from ruddick (ruddick.orange.co.uk [172.19.16.129])
	by ren.orange.co.uk (Pro-8.9.3/8.9.3) with SMTP id OAA17689
	for ; Thu, 13 Apr 2000 14:58:38 +0100 (BST)
Received: by ruddick(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 802568C0.004C245E ; Thu, 13 Apr 2000 14:51:40 +0100
X-Lotus-FromDomain: HTLUK
From: Simon.BARBER@orange.co.uk
To: sip@lists.bell-labs.com
Message-ID: <802568C0.004C23A9.00@ruddick>
Date: Thu, 13 Apr 2000 15:07:15 +0100
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] RSVP/SIP problem
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

When building a telephone network a very important factor is GoS - Grade of
Service, i.e. the probability that a call will block due to resources not being
available. I would like to confirm my understanding of how this can happen with
SIP.

If resources for a call are not available the call should block before the
called party is alerted. For this to happen both endpoints must have all the
information they need to know to perform resource reservation before the called
party is alerted, and they should be able to communicate this availability.

Assuming RSVP is going to be used for resource reservation:

These events are required for a reservation: (taken from RSVP rfc)
      H1   A receiver joins the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP Path messages to the
           DestAddress.

      H3   A receiver application receives a Path message.

      H4   A receiver starts sending appropriate Resv messages,
           specifying the desired flow descriptors.

      H5   A sender application receives a Resv message.

      H6   A sender starts sending data packets.

As far as I understand the SIP exchange of INVITE, RINGING does not permit this.

I will look at a point to point full duplex audio call:

The calling end determines the local address to which media should be sent
The calling end sends INVITE, passing the local address to which media should be
sent.
The calling end cannot make any resource reservation yet, since it does not know
the destination address for media
The INVITE is routed to the receiving end of the call.
The receiving end of the call can now send a RSVP path message back to the
calling end to reserve a media path in that direction
The called end determines the local media address where media should be
received.
The called end sends this local address to the calling end via a 183 response
The called end starts alerting

Here is the problem. The called end has started alerting without knowing that
bandwidth has been reserved in the direction from the calling end to the called
end. Potentially when the user picks up the phone only a one way voice path will
be possible.

To solve this problem an ACK to the 183 response, confirming that bandwidth is
available should be sent from the calling end before ringing commences.

regds,

Simon Barber
Orange PCS Ltd





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


From sip-admin@lists.bell-labs.com  Thu Apr 13 13:04: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 NAA08120
	for ; Thu, 13 Apr 2000 13:04: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 E8D544437E; Thu, 13 Apr 2000 12:53:04 -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 86EE74434C
	for ; Thu, 13 Apr 2000 10:14:09 -0400 (EDT)
Received: from super.du.uab.ericsson.se (root@super.du.uab.ericsson.se [134.138.176.16])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA05691;
	Thu, 13 Apr 2000 16:16:46 +0200 (MET DST)
Received: from martell.du.uab.ericsson.se (mml@martell [134.138.176.69])
	by super.du.uab.ericsson.se (8.10.0/8.10.0/erix-1.7) with ESMTP id e3DEGhb05052;
	Thu, 13 Apr 2000 16:16:43 +0200 (MET DST)
Received: by martell.du.uab.ericsson.se (8.10.0/client-1.7)
	id e3DEGhc28131; Thu, 13 Apr 2000 16:16:43 +0200 (MET DST)
Message-ID: <14581.54986.744836.866170@gargle.gargle.HOWL>
Date: Thu, 13 Apr 2000 16:16:42 +0200 (MET DST)
From: Matthias.Lang@ericsson.com
To: "Stanislav S. Timinsky" 
Cc: jimmy Zhang , sip@lists.bell-labs.com
Subject: Re: [SIP] payload description
In-Reply-To: <15833.000406@mera.ru>
References: <38EA6F80.999D86FE@ipunity.com>
	<15833.000406@mera.ru>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Mime-Version: 1.0 (generated by tm-edit 1.5)
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:  
X-BeenThere: sip@lists.bell-labs.com


    Jimmy Zhang>I would like to know if there exists a
    Jimmy Zhang> standard way to describe the jimmy payload
    Jimmy Zhang> size of the RTP stream. 

Stanislav S. Timinsky writes:

 > I think, You may use the attribute parameter in SDP (rfc-2327, page 22).
 > 
 >    a=ptime:
 >      This gives the length of time in milliseconds represented by the
 >      media in a packet.

Keep in mind that both RFC 2327 (SDP) and RFC 1890 (AVP) seem to say
that you can ignore the value of ptime:

RFC2327, Section 6, "Suggested Attributes":

	 It should not be necessary to know ptime to decode RTP or
	 vat audio, and it is intended as a recommendation for the
	 encoding/packetisation of audio.

RFC1890, Section 4.2:

	 A receiver should accept packets representing between 0
	 and 200ms of audio data.

RFC1890, Section 4.3:

	 All frame-oriented audio codecs should be able to encode
	 and decode several consecutive frames within a single packet.

Matthias



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


From sip-admin@lists.bell-labs.com  Thu Apr 13 13:17: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 NAA08492
	for ; Thu, 13 Apr 2000 13:17: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 9725844389; Thu, 13 Apr 2000 13:05:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203])
	by lists.bell-labs.com (Postfix) with ESMTP id 0FAA344387
	for ; Thu, 13 Apr 2000 13:05:34 -0400 (EDT)
Received: by mail with Internet Mail Service (5.5.2650.21)
	id <2ZWPJZH6>; Thu, 13 Apr 2000 10:15:11 -0700
Message-ID: 
From: Marcelo San Martin 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 10:15: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:  
X-BeenThere: sip@lists.bell-labs.com


I think another very important issue here is how to keep a given QoS for a
established call, how do we guarantee the current QoS of at the next
location? maybe there will not be enough bandwidth at that point and the
hand-off will fail anyway.  

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, April 12, 2000 5:27 PM
To: Rosen, Brian
Cc: 'Dean Willis'; Stephen Terrill; Baba, S.; sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off


Rosen, Brian writes:
 > It is entirely inappropriate for any session level protocol, let alone
 > session establishment protocols, to have knowledge that the end
 > device is mobile.  It's like having the protocol have to know
 > whether they are on a LAN or a WAN.  Somewhere, someone cares,
 > but it shouldn't be SIP!

Brian,

I think the more interesting question is what you
do when there is no end to end transparency. In
particular, what do you do when you have non-IP
mobile devices which are proxied by IP devices
which terminate the RTP flows into something
else. Sound like anything familiar?

In that case, end to end transparency is already
fogged and it's not entirely clear that mobile IP
is the right answer; it could just as easily be
modeled as a decomposed trunking situation where
the application layer MGC deals with the hard
handoffs. In this case, I don't think you are
inventing unreasonable application layer mobility
awareness since any SIP needs to have the ability
to deal with mid-call SDP changes (codecs, if
nothing else). The mobile SIP on the other hand
could deal with the hows and whens of the handoff
burden but that's not an unreasonable thing to
ask; in fact it's a feature, not a bug that a SIP
application could manage mobility in this way.

		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  Thu Apr 13 15:17: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 PAA11696
	for ; Thu, 13 Apr 2000 15:17: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 B95BC4433A; Thu, 13 Apr 2000 15:14:33 -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 350A544338
	for ; Thu, 13 Apr 2000 15:14:31 -0400 (EDT)
Received: from mo3980r1.ems.att.com ([135.38.12.14])
	by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA08456;
	Thu, 13 Apr 2000 15:17:11 -0400 (EDT)
Received: from njb140bh1.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA09281; Thu, 13 Apr 2000 15:12:00 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <249MMDYS>; Thu, 13 Apr 2000 15:17:09 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Marcelo San Martin , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 15:17:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Everyone:

Yes, it is right that QOS issues need to be addressed. We may proceed as
follows:

1. First, let us see how SIP can support mobility while a mobile user moves
from one place to another (e.g., maintain the session level connectivity).
2. Second, how the QOS is maintained in the mobile environment.

We are addressing the first one for now.

For QOS, we are waiting to see the final standard of SIP that supports QOS
considering the fixed environment. When it is complete, we can then use it
for extension in mobile environment (I hope that we can do although it is a
complex problem).

However, when the two endpoints do not support the same level of QOS, they
may fall back to the common denominator (e.g., best-effort). It may be true
for both fixed and mobile environment. In mobile environment, there may be
additional requirements. For example, service providers may have to make
apriori agreement what will happen if the same level of QOS is not provided.

Best regards,
Radhika R. Roy
AT&T

> -----Original Message-----
> From:	Marcelo San Martin [SMTP:MSanmartin@lboard.com]
> Sent:	Thursday, April 13, 2000 1:15 PM
> To:	sip@lists.bell-labs.com
> Subject:	RE: [SIP] SIP and soft hand-off
> 
> 
> I think another very important issue here is how to keep a given QoS for a
> established call, how do we guarantee the current QoS of at the next
> location? maybe there will not be enough bandwidth at that point and the
> hand-off will fail anyway.  
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, April 12, 2000 5:27 PM
> To: Rosen, Brian
> Cc: 'Dean Willis'; Stephen Terrill; Baba, S.; sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
> 
> 
> Rosen, Brian writes:
>  > It is entirely inappropriate for any session level protocol, let alone
>  > session establishment protocols, to have knowledge that the end
>  > device is mobile.  It's like having the protocol have to know
>  > whether they are on a LAN or a WAN.  Somewhere, someone cares,
>  > but it shouldn't be SIP!
> 
> Brian,
> 
> I think the more interesting question is what you
> do when there is no end to end transparency. In
> particular, what do you do when you have non-IP
> mobile devices which are proxied by IP devices
> which terminate the RTP flows into something
> else. Sound like anything familiar?
> 
> In that case, end to end transparency is already
> fogged and it's not entirely clear that mobile IP
> is the right answer; it could just as easily be
> modeled as a decomposed trunking situation where
> the application layer MGC deals with the hard
> handoffs. In this case, I don't think you are
> inventing unreasonable application layer mobility
> awareness since any SIP needs to have the ability
> to deal with mid-call SDP changes (codecs, if
> nothing else). The mobile SIP on the other hand
> could deal with the hows and whens of the handoff
> burden but that's not an unreasonable thing to
> ask; in fact it's a feature, not a bug that a SIP
> application could manage mobility in this way.
> 
> 		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


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 16:26: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 QAA13267
	for ; Thu, 13 Apr 2000 16:26: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 89CBE4433E; Thu, 13 Apr 2000 16:23:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from witbier.cisco.com (witbier.cisco.com [171.71.152.57])
	by lists.bell-labs.com (Postfix) with ESMTP id 5FABE44336
	for ; Thu, 13 Apr 2000 16:23:52 -0400 (EDT)
Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34])
	by witbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA09082;
	Thu, 13 Apr 2000 13:25:33 -0700 (PDT)
Message-Id: <4.1.20000413160843.00a94500@localhost>
X-Sender: mramalho@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 13 Apr 2000 16:20:17 -0400
To: Dean Willis ,
        Stephen Terrill ,
        "Baba, S." 
From: "Michael A. Ramalho" 
Subject: RE: [SIP] SIP and soft hand-off
Cc: sip@lists.bell-labs.com
In-Reply-To: <001001bfa4b8$35558cc0$4b9623a6@mcit.com>
References: <38F43E30.899524BC@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA13267

I was going to jump in earlier ... but I agree with at least layer
3 ... and therefore SIP should be aware of soft handoff.

The issue here is that you get redundant streams (from the
voice payload point of view) from two different sources/sinks
during soft handoff.

If only one "end" was in the process of soft handoff ... I think
some combination of also/replace (with same call_id) would
work ... with a codec that knows what do to with two (payload)
redundant streams. The situation gets messy when both ends
are undergoing soft handoff or conferencing cases. I think
this is what Faramak was referring to as being difficult.

Michael Ramalho

At 02:49 PM 4/12/00 -0500, Dean Willis wrote:
>
>One can envision a layer-2 hand off, a layer-3 (mobile-IP) hand off, or a
>layer-4 handoff . . .
>
>This mobility approach seems to me to be appropriate to a layer-4 handoff,
>wherein the IP address actually changes. This has applicability outside
>classic mobilephone. For example, when I undock my PC, I might want to
>switch from my wired 100TX card to my wireless 802.11 card. Both can be
>active during handoff -- then I shut down the wired card and undock.
>
>--
>Dean
>
>> -----Original Message-----
>> From: sip-admin@lists.bell-labs.com
>> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stephen Terrill
>> Sent: Wednesday, April 12, 2000 4:13 AM
>> To: Baba, S.
>> Cc: sip@lists.bell-labs.com
>> Subject: Re: [SIP] SIP and soft hand-off
>>
>>
>> Hi Baba,
>>
>> I am not sure that I understand the requirements as discussed
>> here.  I understand that the technology independance requirement,
>> and quite like that, however I don´t understand the need of the
>> SIP protocol level to be involved in the Soft hand-off.  I would
>> have expected that the soft hand-off would be entirely within the
>> "access network" (the mobile network technology), from the
>> prespective of the SIP applications.  As such, the application
>> shouldn´t even be aware of the hand-overs (won´t even change IP address).
>>
>> Regards,
>>
>> ..//steve
>>
>> "Baba, S." wrote:
>>
>> > Folks,
>> >
>> > Thank you for your attention to my presentation of
>> > our mobility management requirement in Adelaide.
>> >
>> > Let me add a brief explanation about a relation between
>> > SIP and wireless soft hand-off, since I feel I didn't answer
>> > raised questions well. Please read the related part (4.1)
>> > of our revised draft  also.
>> >
>> > First, we believe that the requirement wireless
>> > 'technology-independent" is very important principle.
>> > At the same time, the soft hand-off is one of the key
>> > technology promising high efficiency for the CDMA-based
>> > wireless system. So any protocol on top of the wireless
>> > shall not break the soft hand-off capability in the
>> > wireless part. These are our basic assumptions.
>> >
>> > The soft hand-off has some aspects like giving smooth hand-off
>> > taking several tens seconds or more for the radio path change
>> > and giving more than one radio paths during the hand-off.
>> > If the soft hand-off is handled in the L2 only or below
>> > L3 and doesn't affect the upper layer process, it is no
>> > problem with SIP.
>> >
>> > But if we consider the future RAN using IP transport,
>> > SIP User Agent and/or Proxy Server may need a process
>> > to support the mobility management on top of the soft hand-off.
>> > Because SIP controls smooth hand-off of its IP sessions.
>> >
>> > Although the details are still open issues, this is the
>> > basic consideration about the soft hand-off.
>> > Any questions and comments are welcomed.
>> >
>> > Thank you.
>> >
>> > Baba//
>> > -----
>> > Shinichi Baba
>> > Toshiba America Research, Inc. (TARI)
>> > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
>> > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
>> > Phone: (973) 829-4795/ Fax: (973) 829-5601
>> > Email: sbaba@tari.toshiba.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
>


Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


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


From sip-admin@lists.bell-labs.com  Thu Apr 13 16: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 QAA13715
	for ; Thu, 13 Apr 2000 16: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 C633E44339; Thu, 13 Apr 2000 16:47:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp.tari.toshiba.com (unknown [207.122.4.195])
	by lists.bell-labs.com (Postfix) with SMTP id A750844338
	for ; Thu, 13 Apr 2000 16:47:44 -0400 (EDT)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-000225) with ESMTP id QAA13288
	for ; Thu, 13 Apr 2000 16:51:36 -0400
To: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: 
References: 
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000413155408W.sbaba@tari.toshiba.com>
Date: Thu, 13 Apr 2000 15:54:08 -0500 (EST)
From: "Baba, S." 
X-Dispatcher: imput version 20000228(IM140)
Lines: 115
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

I'm wondering the same thing as what Radhika raised.
Because I think some issues of the mobility management could
have to be discussed in the SIP WG.

Of course, we may be able to discuss whole issues separately first,
then come back to the WG with the related issues only later.
But I don't know if it works effectively or not.
So I would like to hear more suggestions.
That would help me to make my view clear either.

Regards,

baba//

From: "Roy, Radhika R, ALARC" 
Subject: RE: [SIP] SIP and soft hand-off
Date: Thu, 13 Apr 2000 09:51:15 -0400

> Hi, Everyone:
> 
> I feel that it will be conflicting if we discuss this in another WG because
> of the following:
> 
> 1. To support mobility in the application layer for session layer, it will
> require to extend the SIP.
> 2. SIP WG  has the sole authority to see whether the extension for mobility
> in SIP is consistent with the overall architecture.
> 3. SIP is the control protocol for all networking environments.
> 
> The only thing that I can foresee is: To form a separate sub-group within
> the SIP so that SIP WG can see the overall consistency in extensions.
> 
> Best regards,
> 
> Radhika R. Roy
> AT&T
> 
> > -----Original Message-----
> > From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> > Sent:	Thursday, April 13, 2000 9:16 AM
> > To:	sip@lists.bell-labs.com
> > Subject:	RE: [SIP] SIP and soft hand-off
> > 
> > I honestly think this topic should be discussed in another WG, which WG is
> > something for others (IAB, Area Directors) to decide.
> > 
> > 	-----Original Message----- 
> > From:   Larry Cox [SMTP:lcox@neta.com] 
> > Sent:   Wednesday, April 12, 2000 4:20 PM 
> > To:     sip@lists.bell-labs.com 
> > Subject:        RE: [SIP] SIP and soft hand-off 
> > 
> > 	Brian Rosen wrote: 
> > > ... 
> > > 
> > >It is entirely inappropriate for any session level protocol, let alone 
> > >session establishment protocols, to have knowledge that the end 
> > >device is mobile.  It's like having the protocol have to know 
> > >whether they are on a LAN or a WAN.  Somewhere, someone cares, 
> > >but it shouldn't be SIP! 
> > > 
> > >Brian 
> > 
> > 	I am glad that I am not alone. I had begun believing that we had
> > lost sight 
> > of the objective of having a layered protocol. If we cannot localize the 
> > knowledge of delivery addresses, we have probably broken the protocol and 
> > will have to go back and start over as soon as the next major evolutionary
> > 
> > change happens. It appears to me that if we have chosen to use UDP and
> > TCP, 
> > the necessity of having IP and the associated IP addresses underneath it 
> > should be explicitly rejected. Some other protocol should be allowed at 
> > that level if it works better. In the same sense that HDLC works best in 
> > some spaces and Ethernet works better in others. If we are keeping the
> > type 
> > of network hardware separate form the application level, it is highly 
> > illogical that we should expect the app to know about changes required for
> > 
> > mobility. Someone pointed out that simultaneous arrival of duplicate
> > frames 
> > is important for soft handoff. Should the SIP application be tasked with 
> > tracking the transmission delay for multiple routes in order to make this 
> > happen? If we get carried away and make the protocol monolithic there will
> > 
> > be very little chance for it to succeed. 
> > 
> > 	Larry 
> > 
> > 
> > 	====================================== 
> > 
> > 	Larry Cox 
> > Senior Software Engineer 
> > 
> > 	Cirilium Inc.            Phone: (480) 317-1115 
> > 1615 S. 52 St.           Fax:   (480) ???-???? 
> > Tempe, AZ 85281-6233     Web:    www.cirilium.com 
> > USA 
> > 
> > 
> > 	_______________________________________________ 
> > SIP mailing list 
> > SIP@lists.bell-labs.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 Apr 13 23:13: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 XAA19977
	for ; Thu, 13 Apr 2000 23:13: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 5207F44337; Thu, 13 Apr 2000 23:10:58 -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 7CF1844336
	for ; Thu, 13 Apr 2000 23:10:55 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id XAA05618;
	Thu, 13 Apr 2000 23:13:28 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d26.cc.telcordia.com [128.96.11.26] (may be forged))
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id XAA19079;
	Thu, 13 Apr 2000 23:13:24 -0400 (EDT)
Message-ID: <38F68CD0.DCA26C47@research.telcordia.com>
Date: Thu, 13 Apr 2000 23:13:23 -0400
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: Glenn Morrow 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and soft hand-off
References: 
Content-Type: multipart/alternative; boundary="------------61DC697CCB3450F3752321D6"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


--------------61DC697CCB3450F3752321D6
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Glenn Morrow wrote:

>
>
> From my understanding the SIP terminal mobility solution does not
> require changes to every application even without dynamic DNS updates.
> This is a common misconception.
>

Correct!
Dynamic DNS is needed to provide location service to new
inbound connections.

>
> Perhaps Hennning or someone could describe the interactions when
> someone wants to FTP to another IP based terminal with a mobile user.
> Will FTP have to change?

HMMP supports TCP as is and requires no changes to FTP or any other
application
that runs on top of TCP.

Regards, Faramak

>
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@fore.com]
>      Sent:   Wednesday, April 12, 2000 3:50 PM
>      To:     'Dean Willis'; Stephen Terrill; Baba, S.
>      Cc:     sip@lists.bell-labs.com
>      Subject:        RE: [SIP] SIP and soft hand-off
>
>      I understand what you want to do.  I like it.
>      I don't like saying that because your IP address changed,
>      ALL application level protocols have to know about it.
>
>      If that's what you want to do, let's purge the app level
>      protocols of the part that changes, even if we have to add a
>      layer
>      somewhere.  It SHOULD NOT require changes in EVERY protocol
>      to make real mobility work.
>
>      That is the basic issue I see with the flurry of mobility
>      efforts.
>      These guys are EVERYWHERE telling us that we have to change what
>      we
>      are doing in order to accommodate mobility.  There isn't a
>      protocol
>      effort I'm involved in that doesn't have a cadre of people trying
>
>      to get something in it to make mobility work.
>
>      That is just plain wrong.  If mobility is, or is about to be,
>      ubiquitous, then we should change IP if we have to.  We should
>      not
>      change SIP, LDAP, COPS, ISUP, DNS, NTP, HTTP, FTP, RADIUS,
>      and every other protocol we really use.
>
>      It is entirely inappropriate for any session level protocol, let
>      alone
>      session establishment protocols, to have knowledge that the end
>      device is mobile.  It's like having the protocol have to know
>      whether they are on a LAN or a WAN.  Somewhere, someone cares,
>      but it shouldn't be SIP!
>
>      Brian
>      ------------
>      Brian Rosen, Principal Engineer
>      Marconi (Formerly FORE Systems)
>      1000 FORE Drive, Warrendale, PA 15086
>      (724) 742-6826  mailto:brosen@eng.fore.com
>
>
>      > -----Original Message-----
>      > From: Dean Willis [mailto:dean.willis@wcom.com]
>      > Sent: Wednesday, April 12, 2000 3:49 PM
>      > To: Stephen Terrill; Baba, S.
>      > Cc: sip@lists.bell-labs.com
>      > Subject: RE: [SIP] SIP and soft hand-off
>      >
>      >
>      >
>      > One can envision a layer-2 hand off, a layer-3 (mobile-IP)
>      > hand off, or a
>      > layer-4 handoff . . .
>      >
>      > This mobility approach seems to me to be appropriate to a
>      > layer-4 handoff,
>      > wherein the IP address actually changes. This has
>      > applicability outside
>      > classic mobilephone. For example, when I undock my PC, I might
>      want to
>      > switch from my wired 100TX card to my wireless 802.11 card.
>      > Both can be
>      > active during handoff -- then I shut down the wired card and
>      undock.
>      >
>      > --
>      > Dean
>      >
>      > > -----Original Message-----
>      > > From: sip-admin@lists.bell-labs.com
>      > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stephen
>      Terrill
>      > > Sent: Wednesday, April 12, 2000 4:13 AM
>      > > To: Baba, S.
>      > > Cc: sip@lists.bell-labs.com
>      > > Subject: Re: [SIP] SIP and soft hand-off
>      > >
>      > >
>      > > Hi Baba,
>      > >
>      > > I am not sure that I understand the requirements as discussed
>
>      > > here.  I understand that the technology independance
>      requirement,
>      > > and quite like that, however I don´t understand the need of
>      the
>      > > SIP protocol level to be involved in the Soft hand-off.  I
>      would
>      > > have expected that the soft hand-off would be entirely within
>      the
>      > > "access network" (the mobile network technology), from the
>      > > prespective of the SIP applications.  As such, the
>      application
>      > > shouldn´t even be aware of the hand-overs (won´t even
>      > change IP address).
>      > >
>      > > Regards,
>      > >
>      > > ..//steve
>      > >
>      > > "Baba, S." wrote:
>      > >
>      > > > Folks,
>      > > >
>      > > > Thank you for your attention to my presentation of
>      > > > our mobility management requirement in Adelaide.
>      > > >
>      > > > Let me add a brief explanation about a relation between
>      > > > SIP and wireless soft hand-off, since I feel I didn't
>      answer
>      > > > raised questions well. Please read the related part (4.1)
>      > > > of our revised draft 
>      also.
>      > > >
>      > > > First, we believe that the requirement wireless
>      > > > 'technology-independent" is very important principle.
>      > > > At the same time, the soft hand-off is one of the key
>      > > > technology promising high efficiency for the CDMA-based
>      > > > wireless system. So any protocol on top of the wireless
>      > > > shall not break the soft hand-off capability in the
>      > > > wireless part. These are our basic assumptions.
>      > > >
>      > > > The soft hand-off has some aspects like giving smooth
>      hand-off
>      > > > taking several tens seconds or more for the radio path
>      change
>      > > > and giving more than one radio paths during the hand-off.
>      > > > If the soft hand-off is handled in the L2 only or below
>      > > > L3 and doesn't affect the upper layer process, it is no
>      > > > problem with SIP.
>      > > >
>      > > > But if we consider the future RAN using IP transport,
>      > > > SIP User Agent and/or Proxy Server may need a process
>      > > > to support the mobility management on top of the soft
>      hand-off.
>      > > > Because SIP controls smooth hand-off of its IP sessions.
>      > > >
>      > > > Although the details are still open issues, this is the
>      > > > basic consideration about the soft hand-off.
>      > > > Any questions and comments are welcomed.
>      > > >
>      > > > Thank you.
>      > > >
>      > > > Baba//
>      > > > -----
>      > > > Shinichi Baba
>      > > > Toshiba America Research, Inc. (TARI)
>      > > > Mail-To: P.O.Box 136 Convent Station, NJ 07961-0136
>      > > > Location: 445 South St. Suite 1B259B, Morristown, NJ 07960
>      > > > Phone: (973) 829-4795/ Fax: (973) 829-5601
>      > > > Email: sbaba@tari.toshiba.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
>

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



 

Glenn Morrow wrote:

 

From my understanding
the SIP terminal mobility solution does not require changes to every application
even without dynamic DNS updates. This is a common misconception.

 

Correct!

Dynamic DNS is needed to provide location service to new

inbound connections.

 

Perhaps Hennning
or someone could describe the interactions when someone wants to FTP to
another IP based terminal with a mobile user. Will FTP have to change?

HMMP supports TCP as is and requires no changes to FTP or any other application

that runs on top of TCP.

Regards, Faramak

 

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

    From:  
Rosen, Brian [SMTP:brosen@fore.com]

    Sent:  
Wednesday, April 12, 2000 3:50 PM

    To:    
'Dean Willis'; Stephen Terrill; Baba,
S.

    Cc:    
sip@lists.bell-labs.com

    Subject:       
RE: [SIP] SIP and soft hand-off

    I understand what you want to do. 
I like it.

    I don't like saying that because your
IP address changed,

    ALL application level protocols have
to know about it.

    If that's what you want to do, let's
purge the app level

    protocols of the part that changes,
even if we have to add a layer

    somewhere.  It SHOULD NOT require
changes in EVERY protocol

    to make real mobility work.

    That is the basic issue I see with
the flurry of mobility efforts.

    These guys are EVERYWHERE telling
us that we have to change what we

    are doing in order to accommodate
mobility.  There isn't a protocol

    effort I'm involved in that doesn't
have a cadre of people trying

    to get something in it to make mobility
work.

    That is just plain wrong.  If
mobility is, or is about to be,

    ubiquitous, then we should change
IP if we have to.  We should not

    change SIP, LDAP, COPS, ISUP, DNS,
NTP, HTTP, FTP, RADIUS,

    and every other protocol we really
use.

    It is entirely inappropriate for any
session level protocol, let alone

    session establishment protocols, to
have knowledge that the end

    device is mobile.  It's like
having the protocol have to know

    whether they are on a LAN or a WAN. 
Somewhere, someone cares,

    but it shouldn't be SIP!

    Brian

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

    Brian Rosen, Principal Engineer

    Marconi (Formerly FORE Systems)

    1000 FORE Drive, Warrendale, PA 15086

    (724) 742-6826  mailto:brosen@eng.fore.com

     

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

    > From: Dean Willis [mailto:dean.willis@wcom.com]

    > Sent: Wednesday, April 12, 2000
3:49 PM

    > To: Stephen Terrill; Baba, S.

    > Cc: sip@lists.bell-labs.com

    > Subject: RE: [SIP] SIP and soft
hand-off

    >

    >

    >

    > One can envision a layer-2 hand
off, a layer-3 (mobile-IP)

    > hand off, or a

    > layer-4 handoff . . .

    >

    > This mobility approach seems to
me to be appropriate to a

    > layer-4 handoff,

    > wherein the IP address actually
changes. This has

    > applicability outside

    > classic mobilephone. For example,
when I undock my PC, I might want to

    > switch from my wired 100TX card
to my wireless 802.11 card.

    > Both can be

    > active during handoff -- then I
shut down the wired card and undock.

    >

    > --

    > Dean

    >

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

    > > From: sip-admin@lists.bell-labs.com

    > > [mailto:sip-admin@lists.bell-labs.com]On
Behalf Of Stephen Terrill

    > > Sent: Wednesday, April 12, 2000
4:13 AM

    > > To: Baba, S.

    > > Cc: sip@lists.bell-labs.com

    > > Subject: Re: [SIP] SIP and soft
hand-off

    > >

    > >

    > > Hi Baba,

    > >

    > > I am not sure that I understand
the requirements as discussed

    > > here.  I understand that
the technology independance requirement,

    > > and quite like that, however I
don´t understand the need of the

    > > SIP protocol level to be involved
in the Soft hand-off.  I would

    > > have expected that the soft hand-off
would be entirely within the

    > > "access network" (the mobile network
technology), from the

    > > prespective of the SIP applications. 
As such, the application

    > > shouldn´t even be aware
of the hand-overs (won´t even

    > change IP address).

    > >

    > > Regards,

    > >

    > > ..//steve

    > >

    > > "Baba, S." wrote:

    > >

    > > > Folks,

    > > >

    > > > Thank you for your attention
to my presentation of

    > > > our mobility management requirement
in Adelaide.

    > > >

    > > > Let me add a brief explanation
about a relation between

    > > > SIP and wireless soft hand-off,
since I feel I didn't answer

    > > > raised questions well. Please
read the related part (4.1)

    > > > of our revised draft <draft-itsumo-sip-mobility-req-01>
also.

    > > >

    > > > First, we believe that the requirement
wireless

    > > > 'technology-independent" is
very important principle.

    > > > At the same time, the soft hand-off
is one of the key

    > > > technology promising high efficiency
for the CDMA-based

    > > > wireless system. So any protocol
on top of the wireless

    > > > shall not break the soft hand-off
capability in the

    > > > wireless part. These are our
basic assumptions.

    > > >

    > > > The soft hand-off has some aspects
like giving smooth hand-off

    > > > taking several tens seconds
or more for the radio path change

    > > > and giving more than one radio
paths during the hand-off.

    > > > If the soft hand-off is handled
in the L2 only or below

    > > > L3 and doesn't affect the upper
layer process, it is no

    > > > problem with SIP.

    > > >

    > > > But if we consider the future
RAN using IP transport,

    > > > SIP User Agent and/or Proxy
Server may need a process

    > > > to support the mobility management
on top of the soft hand-off.

    > > > Because SIP controls smooth
hand-off of its IP sessions.

    > > >

    > > > Although the details are still
open issues, this is the

    > > > basic consideration about the
soft hand-off.

    > > > Any questions and comments are
welcomed.

    > > >

    > > > Thank you.

    > > >

    > > > Baba//

    > > > -----

    > > > Shinichi Baba

    > > > Toshiba America Research, Inc.
(TARI)

    > > > Mail-To: P.O.Box 136 Convent
Station, NJ 07961-0136

    > > > Location: 445 South St. Suite
1B259B, Morristown, NJ 07960

    > > > Phone: (973) 829-4795/ Fax:
(973) 829-5601

    > > > Email: sbaba@tari.toshiba.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





--------------61DC697CCB3450F3752321D6--



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 16:12:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13848
	for ; Fri, 14 Apr 2000 16:12:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2CB0844337; Fri, 14 Apr 2000 16:09:16 -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 509A244336
	for ; Fri, 14 Apr 2000 16:09:13 -0400 (EDT)
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA03852;
	Fri, 14 Apr 2000 23:12:01 +0300 (EETDST)
From: Basavaraj.Patil@nokia.com
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA11624;
	Fri, 14 Apr 2000 23:11:57 +0300 (EETDST)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0)
	id ; Fri, 14 Apr 2000 15:10:43 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4EC2@daeis07nok>
To: rrroy@att.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Fri, 14 Apr 2000 15:10:30 -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:  
X-BeenThere: sip@lists.bell-labs.com



Comments below:

Radhika wrote:
>Chris:

>Now there are internet-drafts related to SIP mobility as well.
>
The SIP WG charter does not currently include mobility solutions in
it's scope. However mobility support will be a key aspect of evolving
networks and there is a specific WG in the IETF which deals with it -
Mobile IP.

>Let me clarify: If the network point of attachment is NOT changed, there is
>almost (some non-real-time mobility management may be needed) no need to do
>anything in the application layer (e.g., SIP, H.323). But it is only a
>special situation.
>
>In many situations, it may not be possible. We are addressing those from
>mobility management point of view. There can be two aspects of this: 
> 1.Should we consider hand-off in the appln layer? 
No. 

>2. Should we consider NO handoff in the appln layer?
The Mobile IP WG is currently debating multiple I-Ds that propose
handoffs at the network layer. If at all handoffs are to be moved to
upper layers (from link/physical layers) then it may be optimal to do
it at the network layer. 

-Basavaraj

>
>I hope that we could agree that the mobility solution would be transparent
>to the application layer (we could save our time)!
>
>Best regards,
>Radhika



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 16:55: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 QAA14372
	for ; Fri, 14 Apr 2000 16:55: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 E205944336; Fri, 14 Apr 2000 16:52:31 -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 4CA0844336
	for ; Fri, 14 Apr 2000 11:27:00 -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 IAB01564
	for ; Fri, 14 Apr 2000 08:29:49 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02653; Fri, 14 Apr 2000 08:29:48 -0700 (PDT)
Date: Fri, 14 Apr 2000 08:29:48 -0700 (PDT)
Message-Id: <200004141529.IAA02653@thomasm-u1.cisco.com>
From: Michael Thomas 
To: sip@lists.bell-labs.com
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!
Subject: [SIP] end to end key 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:  
X-BeenThere: sip@lists.bell-labs.com


While it's potentially OK to have a pre-shared
secret between a proxy and a UA, it clearly
doesn't scale well to have a mesh of pre-shared
secrets between all of the UA's for end to end
authentication of SIP traffic. As far as I can
remember, there's a way to send a key end to end
in the k: field of SDP, but that suffers from
two problems:

1) the key is intended for what the SDP
   announcement is describing, which is normally
   just a media descriptor. I don't think it
   is intended to be used for SIP session level
   keying. If there's a standard way to describe
   how to tell the UAS that that key ought to
   also be used for, say, http-authenticate's,
   that would probably be a fine solution.

2) the key is shipped in the clear. If there
   is no underlying transport crypto, then
   the key is really in the clear which makes
   the entire use of crypto rather dubious.

Toward the latter, assuming there is no transport
level security, maybe an acceptable alternative is
to use hop-by-hop keying between the UAC->Po Po->Pt
and Pt->UAS. In that case, we could use the
existing pre-shared secret for proxy-authenticate,
say, to encrypt the key itself in the SDP
announcement. 

Has anybody thought about this issue before? Is
this one of those areas where header encryption
might actually be useful, but for hop-by-hop
instead of end to end?

	   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 Apr 14 17:03:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14504
	for ; Fri, 14 Apr 2000 17:02: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 BAAE444342; Fri, 14 Apr 2000 17:00:07 -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 3162A44341
	for ; Fri, 14 Apr 2000 17:00:05 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19099
	for ; Fri, 14 Apr 2000 15:02:54 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA04116;
	Fri, 14 Apr 2000 14:02:51 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA19584;
	Fri, 14 Apr 2000 14:02:51 -0700 (PDT)
Message-Id: <200004142102.OAA19584@nasnfs.eng.sun.com>
Date: Fri, 14 Apr 2000 14:05:11 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
To: sip@lists.bell-labs.com
Cc: erik.guttman@germany.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: TuadCm6A04tLW9D4OwNPhw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Subject: [SIP] SLP Template Standardization for SIP Servers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Sorry for the long hiatus between IETF and this message.

I promised at the SIP working group to talk with Erik Guttman about the
standardization procedure for SLP templates and post the procedure
here.

The procedure does not require that the template be an RFC, only
that it be an Internet draft. Once the template has been finalized,
there is an email address (srvloc-list@iana.org). The list hasn't been 
activated yet, but Erik says that if the template is sent to
him, he'll make sure that it gets into the template repository.
Erik is the "designated export" who is maintaining the repository.

I would suggest that the working group consider submitting the
template after working group last call on any drafts that
may impact the template. In fact, having the template go through
a last call when the drafts do would also help assure that it
accurately reflects the SIP protocol. Naturally, it would help
if the template draft were a working group item, but I'm prepared
to move it along as an individual contribution if the working
group would rather not include it (I should note that the NAT
working group has included the RSIP template as a working group
item).

Comments?

			jak



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 17:14:43 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14597
	for ; Fri, 14 Apr 2000 17: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 38A754433A; Fri, 14 Apr 2000 17:11:51 -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 AA3CD44339
	for ; Fri, 14 Apr 2000 17:11:48 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FT000A05Z0D5J@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 14 Apr 2000 21:14:37 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FT000501Z0D14@dgismtp02.wcomnet.com>;
 Fri, 14 Apr 2000 21:14:37 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FT0003EQZ0D7O@dgismtp02.wcomnet.com>; Fri,
 14 Apr 2000 21:14:37 +0000 (GMT)
Received: from dwillispc8 ([166.35.144.185])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000414211436.WNIC21369@dwillispc8>; Fri,
 14 Apr 2000 21:14:36 +0000
Date: Fri, 14 Apr 2000 16:13:56 -0500
From: Dean Willis 
Subject: RE: [SIP] SIP and soft hand-off
In-reply-to: <14581.5192.635759.512831@thomasm-u1.cisco.com>
To: IETF SIP , Michael Thomas 
Message-id: <002f01bfa656$582ff740$b99023a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Michael said:
> I think the more interesting question is what you
> do when there is no end to end transparency. In
> particular, what do you do when you have non-IP
> mobile devices which are proxied by IP devices
> which terminate the RTP flows into something
> else. Sound like anything familiar?
>

When you put it this way, it sounds pretty much like a call transfer between
UAs . . .

--
dean



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 17:37: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 RAA14819
	for ; Fri, 14 Apr 2000 17:37: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 8BE104433D; Fri, 14 Apr 2000 17:34:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp.tari.toshiba.com (unknown [207.122.4.195])
	by lists.bell-labs.com (Postfix) with SMTP id F2D0044336
	for ; Fri, 14 Apr 2000 17:34:21 -0400 (EDT)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-000225) with ESMTP id RAA16349;
	Fri, 14 Apr 2000 17:37:50 -0400
To: Basavaraj.Patil@nokia.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4EC2@daeis07nok>
References: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4EC2@daeis07nok>
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000414164034S.sbaba@tari.toshiba.com>
Date: Fri, 14 Apr 2000 16:40:34 -0500 (EST)
From: "Baba, S." 
X-Dispatcher: imput version 20000228(IM140)
Lines: 71
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi Basavaraj,

In SIP, there is a 're-invite' scheme which makes
user mobility available. I think this is more powerful
than the network layer hand-off in some cases.
So I'm not sure that all user/application requirement
is satisfied with the network layer hand-off.

Then a question comming up to me is,
Are you suggesting the need of cooperation between
SIP/application layer and the network layer mobility
management protocol?
or the solution in the network layer only for all
problem with mobility?

I just want to understand what you said.
Thank you.

baba//


From: Basavaraj.Patil@nokia.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Fri, 14 Apr 2000 15:10:30 -0500

> 
> 
> Comments below:
> 
> Radhika wrote:
> >Chris:
> 
> >Now there are internet-drafts related to SIP mobility as well.
> >
> The SIP WG charter does not currently include mobility solutions in
> it's scope. However mobility support will be a key aspect of evolving
> networks and there is a specific WG in the IETF which deals with it -
> Mobile IP.
> 
> >Let me clarify: If the network point of attachment is NOT changed, there is
> >almost (some non-real-time mobility management may be needed) no need to do
> >anything in the application layer (e.g., SIP, H.323). But it is only a
> >special situation.
> >
> >In many situations, it may not be possible. We are addressing those from
> >mobility management point of view. There can be two aspects of this: 
> > 1.Should we consider hand-off in the appln layer? 
> No. 
> 
> >2. Should we consider NO handoff in the appln layer?
> The Mobile IP WG is currently debating multiple I-Ds that propose
> handoffs at the network layer. If at all handoffs are to be moved to
> upper layers (from link/physical layers) then it may be optimal to do
> it at the network layer. 
> 
> -Basavaraj
> 
> >
> >I hope that we could agree that the mobility solution would be transparent
> >to the application layer (we could save our time)!
> >
> >Best regards,
> >Radhika
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 14 17:42: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 RAA14866
	for ; Fri, 14 Apr 2000 17:42: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 7C88C4434C; Fri, 14 Apr 2000 17:39:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id BBF9B4434B
	for ; Fri, 14 Apr 2000 17:39:35 -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 OAA10330;
	Fri, 14 Apr 2000 14:42:29 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA02753; Fri, 14 Apr 2000 14:42:25 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14583.37057.336235.50310@thomasm-u1.cisco.com>
Date: Fri, 14 Apr 2000 14:42:25 -0700 (PDT)
To: Dean Willis 
Cc: IETF SIP , Michael Thomas 
Subject: RE: [SIP] SIP and soft hand-off
In-Reply-To: <002f01bfa656$582ff740$b99023a6@mcit.com>
References: <14581.5192.635759.512831@thomasm-u1.cisco.com>
	<002f01bfa656$582ff740$b99023a6@mcit.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Dean Willis writes:
 > 
 > 
 > Michael said:
 > > I think the more interesting question is what you
 > > do when there is no end to end transparency. In
 > > particular, what do you do when you have non-IP
 > > mobile devices which are proxied by IP devices
 > > which terminate the RTP flows into something
 > > else. Sound like anything familiar?
 > >
 > 
 > When you put it this way, it sounds pretty much like a call transfer between
 > UAs . . .

   I think there are actually two things, both
   useful in their own right:

   1) "Call Transfer" where the call state is
      "moved" from one UA to another. This 
      might be how you do hard handoff. (?)

   2) "Conferencing" where a UA decides which
      speakers/microphones to turn on/off at
      any given time based on some feedback.      

   The latter is what I was describing, though
   in the context of mobility. In that case, it's
   a matter of chasing the moving
   speaker/microphone rather than tuning one in at
   a time.

	       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 Apr 14 17:43: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 RAA14878
	for ; Fri, 14 Apr 2000 17:43: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 D1A2144352; Fri, 14 Apr 2000 17:40:04 -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 E78CD4434B
	for ; Fri, 14 Apr 2000 17:40:01 -0400 (EDT)
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA19891;
	Sat, 15 Apr 2000 00:42:51 +0300 (EETDST)
From: Basavaraj.Patil@nokia.com
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id AAA28749;
	Sat, 15 Apr 2000 00:42:50 +0300 (EETDST)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0)
	id ; Fri, 14 Apr 2000 16:41:37 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4ECE@daeis07nok>
To: sbaba@tari.toshiba.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Fri, 14 Apr 2000 16:41:19 -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:  
X-BeenThere: sip@lists.bell-labs.com



Hello Baba,

>Hi Basavaraj,
>
>In SIP, there is a 're-invite' scheme which makes
>user mobility available. I think this is more powerful
>than the network layer hand-off in some cases.
>So I'm not sure that all user/application requirement
>is satisfied with the network layer hand-off.
>
>Then a question comming up to me is,
>Are you suggesting the need of cooperation between
>SIP/application layer and the network layer mobility
>management protocol?
>or the solution in the network layer only for all
>problem with mobility?
>

Thinking aloud, there is definitely a need for cooperation between the 
SIP WG and the Mobile IP WG to arrive at some conclusions regarding
mobility in SIP.

-Basavaraj

>I just want to understand what you said.
>Thank you.
>
>baba//


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


From sip-admin@lists.bell-labs.com  Fri Apr 14 17:56:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14958
	for ; Fri, 14 Apr 2000 17:56:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E376844342; Fri, 14 Apr 2000 17:54:01 -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 3389644339
	for ; Fri, 14 Apr 2000 17:53:59 -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 PAA24437
	for ; Fri, 14 Apr 2000 15:56:48 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA16400
	for ; Fri, 14 Apr 2000 14:56:48 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA25820;
	Fri, 14 Apr 2000 14:56:42 -0700 (PDT)
Message-Id: <200004142156.OAA25820@nasnfs.eng.sun.com>
Date: Fri, 14 Apr 2000 14:59:03 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
To: sip@lists.bell-labs.com
Cc: James.Kempf@Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 68uDXj5Pd9p28L6UZ+EdJA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Subject: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

I'm working on a design for replacing the IS-41 North American cellular
signalling protocol with IP protocols. I had a couple of questions about
how the SIP INFO method, or potentially another SIP method, might
be used.

1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange
of radio signal strength information is explicitly mentioned as
an application of the SIP INFO method. The HandoffMeasurementRequest
and HandoffMeasurementRequest2 messages in IS-41 are sent by the anchor
Mobile Switching Center (MSC) to a potential serving MSC to obtain information 
about the signal strength of a Mobile Station (MS) in order to determine
if the potential serving MSC is a better candidate for handling the
mobile's call (called "hard handoff" in cellular jargon). They could be 
replaced with a SIP INFO method. There are three problems:

	a) The radio information is always solicited by the anchor MSC,
	and from the ID, the SIP INFO method seems like it is 
	sent unsolicted. I suppose one could come up with two INFO
	methods, one to solicit the radio information and one to
	return it, but this seems like a hack somehow.
	
	b) In the ID, it explicitly states that the INFO method is 
	only applicable when there is a call in progress. Problem is,
	there isn't a call in progress between the anchor MSC and
	the serving MSC, that's why the anchor MSC is soliciting
	the radio quality information in the first place.
	
	c) The INFO method seems like it is meant to be sent between 
	SIP UAC's, while the HandoffMeasurementRequest(2) methods
	are primarily designed to be sent between network elements.
	A SIP replacement would probably be sent between the last hop SIP
	proxies acting as Call Agents (CAs) for the call, which replaces
	the MSC in an all IP network.

2) There are a bunch of IS-41 messages that involve transmitting
feature or other information between the MS's Home Location
Register (HLR) and the MS. These are initiated by either the serving
MSC or the HLR. Examples are InformationDirective, which is used
by the HLR to provide notifications to an idle MS, and FeatureRequest,
which sends particular features to a potentially idle MS (features
being things like messages or playing particular tones). Again, these
seem like candidates to replace with the SIP INFO message, but 
the potential lack of any call in progress would prohibit that.

The alternative I could see would be establishing a session in order
to then send the information via the INFO method, but that seems like
overkill. And in the case of HandoffMeasurementRequest(2), the
message isn't intended for a SIP UAC anyway.

Maybe SIP is the wrong protocol to consider, since it is dedicated
to setting up and maintaining sessions, and not to exchanging information
between network elements or between network elements and terminals?

Can anybody provide some guidance?

		jak



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 19:00: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 TAA15457
	for ; Fri, 14 Apr 2000 19:00:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D16B244337; Fri, 14 Apr 2000 18:57:34 -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 022A444336
	for ; Fri, 14 Apr 2000 18:57:31 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03833
	for ; Fri, 14 Apr 2000 17:00:21 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA20938
	for ; Fri, 14 Apr 2000 16:00:20 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA27038;
	Fri, 14 Apr 2000 16:00:18 -0700 (PDT)
Message-Id: <200004142300.QAA27038@nasnfs.eng.sun.com>
Date: Fri, 14 Apr 2000 16:02:39 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
Subject: RE: [SIP] SIP and soft hand-off
To: sip@lists.bell-labs.com
Cc: James.Kempf@Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Zhdgemo4zLlC4IXIvCiBJA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

I'm coming into this discussion late so please excuse me if I'm repeating
anything. I've just spent the last three months working with the
Mobile Wireless Internet Forum on how to introduce IP into the radio
access network (RAN) in 3G CDMA systems, and we will be continuing this
discussion until a concluding report is made in August. In March, I
posted some notes to the mobile IP mailing list where a discussion
of "micro-mobility" was underway. I`ve been planning to write up these thoughts 
in an ID sometime soon, since the question of replacing soft handoff with IP 
mobility solutions keeps coming up, but in the interim, here is a summary.

Within the RAN, there is no one to one mapping between
the octet stream of a call coming into the RAN and the octet stream
coming out into the IP stack on the mobile. The RAN controller
breaks the incoming octet stream into multiple (up to 6) streams that are
then sent to multiple base stations. In the mobile, the multiple
incoming radio signals are combined at L1 to produce the packet
that appears in the IP stack. Similarly, on return, multiple copies of
a packet from the mobile flow from the multiple base stations to the
RAN controller where the best one is selected (called frame selection or 
macrodiversity combination). So it is not possible to assign a single base 
station (and thus a single SIP registrar server or mobile IP FA in
the RAN) to the mobile. 

Exactly how to utilize IP in the RAN is an open question, but nobody
I've talked to thinks that the IP packets coming out of the mobile
will be running directly on L2 over the RAN anytime soon. In current
networks, the RAN controller takes the incoming voice and shapes
it into packets that the base station can quickly take out and
send over the air. Similarly, in the other direction, the base
station takes packets off the air and sends them largely unmodified
to the RAN controller. So the traffic in the RAN looks like radio packets. 
There is alot of very sophisticated (and proprietary) control protocol
between the base stations and the RAN controller, involving signal
processing, for doing soft handoff. There are also very tight
delay and jitter constraints. The RAN controller has time slots
between 5 and 80 ms to reach the base station, if it misses a time
slot, the base station tells it that it needs to do better, and the
packet may be dropped, potentially resulting in a degradation of
call quality. Most proposals for using IP in the RAN involve simply
replacing the L2 transport as specified with IP, so the current
proprietary RAN signalling and data protocols would run over IP
unmodified. Indeed, both 3GPP and 3GPP2 (European and North American
3rd generation) cellular designs have hooks for IP as control transport 
in the RAN, though not for IP data transport.

Given these constraints, I am skeptical about replacing soft handoff
with either L3 (mobile IP or any of the pre-frame selection
micromobility proposals) or L7 (SIP) mechanisms. Should the radio
manufacturers and cellular operators desire it, it would be interesting to look
at an Open RAN protocol that would take the current proprietary soft handoff 
mechanisms and standardize them. But, for now, I think any IP mobility 
solutions need to be restricted to post frame selection, i.e. hard handoff 
only.

Note that the situation is different in TDMA systems like GSM. In that
case, there is no soft handoff and I believe that the mobile can
only be in contact with a maximum of two base stations at a time, and then only
until handoff is complete between one and the other.

		jak




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


From sip-admin@lists.bell-labs.com  Fri Apr 14 19:03:24 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15526
	for ; Fri, 14 Apr 2000 19:03:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6442744342; Fri, 14 Apr 2000 19:00:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32])
	by lists.bell-labs.com (Postfix) with ESMTP id A7B4944341
	for ; Fri, 14 Apr 2000 19:00:27 -0400 (EDT)
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id TAA24884;
	Fri, 14 Apr 2000 19:02:30 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852568C1.007E8C91 ; Fri, 14 Apr 2000 19:02:15 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Ashutosh Dutta" 
To: Stephen Terrill 
Cc: "Baba, S." , sip@lists.bell-labs.com
Message-ID: <852568C1.007E8C11.00@notes949.cc.telcordia.com>
Date: Fri, 14 Apr 2000 19:01:01 -0400
Subject: Re: [SIP] SIP and soft hand-off
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=40YeCzMBWdjiW7eBtiy8itPVa9nCSli7NfLsgoSNS3Qt4oNPruQFtdan"
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:  
X-BeenThere: sip@lists.bell-labs.com

--0__=40YeCzMBWdjiW7eBtiy8itPVa9nCSli7NfLsgoSNS3Qt4oNPruQFtdan
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Stephen, agreed that soft-hand  is mostly dealt with  at layer two, however if
the IP-enabled Mobile station  is moving between adjacent cells where each cell
belongs to a different subnet (subnet mobility) within a domain, soft-hand off
can be emulated (achieved) at layer 3 by using IP multicast from the immediate
first hop router within a domain, and layer two soft handoff may not be needed
at that point. Things would be bit different if each adjacent cell belongs to a
different domain however.

If we are using using SIP as a signaling mechanism for wireless end-points, it
could be used to trigger that soft-hand off emulation at the first hop router
level.

Regards
Ashutosh




Stephen Terrill  on 04/13/2000 03:37:31 AM

To:   "Baba, S." 
cc:   sip@lists.bell-labs.com, itsumo@research.telcordia.com (bcc: Ashutosh
      Dutta/Telcordia)
Subject:  Re: [SIP] SIP and soft hand-off




Hi,

Perhaps out of all of the replies, this is the most appropriate to respond to.

It is interesting that it is pointed out here that for some of the popular
archectures where this is being considered that the soft hand-over doesn
--0__=40YeCzMBWdjiW7eBtiy8itPVa9nCSli7NfLsgoSNS3Qt4oNPruQFtdan
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=B4t come
into the process as it happens at layer 2.  It is also interesting to n=
ot that a
significant portion of those archectures do run on top of IP.  I think =
that it
is required to remember where the IP network that the Application in th=
e mobile
terminal sees actually is - it is not necessary the IP network that is =
used to
run the RAN.

Regards,

..//steve

"Baba, S." wrote:

> Hi Steve and Radhika,
>
> Thank you for your comments.
>
> First of all, I agree with you that SIP needs to do nothing in
> any case if IP address of Mobile Station (MS) is not changed.
>
> And I also agree with both of you in the case of certain (and maybe
> popular) architecture, e.g. the one on which 3GPP or 3GPP2 is
> working right now. Because in this case the soft hand-off is
> completely processed in or under the layer 2 and MS can not
> distinguish if it is the hard hand-off or the soft hand-off from
> upper layers.
>
> As Faramak mentioned in his reply, we are looking at the future RAN
> which will use the IP even for its transport method, i.e. IP
> in the RAN or IP to the BTS, at the same time. Even in this case,
> the mobility management by SIP shall not break the soft hand-off
> process using IP communication. That is the point where we are
> thinking as one of the important principles.
>
> Regards,
>
> baba//
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip



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


=

--0__=40YeCzMBWdjiW7eBtiy8itPVa9nCSli7NfLsgoSNS3Qt4oNPruQFtdan--



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


From sip-admin@lists.bell-labs.com  Fri Apr 14 20:40:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16245
	for ; Fri, 14 Apr 2000 20:40: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 4323944337; Fri, 14 Apr 2000 20:37:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id DD6D744336
	for ; Fri, 14 Apr 2000 20:37:08 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id UAA24569;
	Fri, 14 Apr 2000 20:39:59 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id UAA10041; Fri, 14 Apr 2000 20:39:08 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <2ZA5W2K2>; Fri, 14 Apr 2000 20:39:59 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Basavaraj.Patil@nokia.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Fri, 14 Apr 2000 20:39:56 -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:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Everyone:

My comments are as follows:

1. We are extending SIP to support mobility in the application layer. So,
SIP WG is the right place. The SIP WG is the only group that knows what to
do the SIP protocol in the application layer.

Let me provide another analogy. We are extending SIP to support QOS. That
does not mean that extension of SIP has to be done in the QOS WGs (DiffServ,
MPLS, etc).

Only SIP WG can ensure whether the extension of SIP to support mobility
remains within the framework SIP architecture because they are the expert in
this application layer protocol (not mobile IP or other WGs).

2. For other points, the technical justifications and contributions will
proof the fact. No personal opinion will help unless it is justified from
technical point of view. (Personally, I would be happy to do as much less
work as we could do to support mobility in SIP.)

Hope this will clarify further.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
Sent: Friday, April 14, 2000 4:11 PM
To: Roy, Radhika R, ALARC
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off




Comments below:

Radhika wrote:
>Chris:

>Now there are internet-drafts related to SIP mobility as well.
>
The SIP WG charter does not currently include mobility solutions in
it's scope. However mobility support will be a key aspect of evolving
networks and there is a specific WG in the IETF which deals with it -
Mobile IP.

>Let me clarify: If the network point of attachment is NOT changed, there is
>almost (some non-real-time mobility management may be needed) no need to do
>anything in the application layer (e.g., SIP, H.323). But it is only a
>special situation.
>
>In many situations, it may not be possible. We are addressing those from
>mobility management point of view. There can be two aspects of this: 
> 1.Should we consider hand-off in the appln layer? 
No. 

>2. Should we consider NO handoff in the appln layer?
The Mobile IP WG is currently debating multiple I-Ds that propose
handoffs at the network layer. If at all handoffs are to be moved to
upper layers (from link/physical layers) then it may be optimal to do
it at the network layer. 

-Basavaraj

>
>I hope that we could agree that the mobility solution would be transparent
>to the application layer (we could save our time)!
>
>Best regards,
>Radhika



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr 14 20:43: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 UAA16281
	for ; Fri, 14 Apr 2000 20:43: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 18D6844341; Fri, 14 Apr 2000 20:40:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83])
	by lists.bell-labs.com (Postfix) with ESMTP id 389FC44340
	for ; Fri, 14 Apr 2000 20:40:36 -0400 (EDT)
Received: from localhost (mwisdom@localhost) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id RAA07240 for ; Fri, 14 Apr 2000 17:43:26 -0700 (PDT)
Date: Fri, 14 Apr 2000 17:43:26 -0700 (PDT)
From: Mark Wisdom 
To: sip@lists.bell-labs.com
Subject: [SIP] OPTIONS behaviour with forking proxy
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:  
X-BeenThere: sip@lists.bell-labs.com

What should a registration server acting as a forking proxy do when it
receives a SIP OPTIONS message which resolves to 2 or more contacts?

Should it:

A. Respond with "300 Multiple Choices".
B. Fork the request off to the multiple choices and then relay the
   first received response back to the original requester?
C. Something else.

I suspect A, but I can't seem to find enough information in
RFC2543 to be certain.

Thanks,
Mark




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


From sip-admin@lists.bell-labs.com  Fri Apr 14 20: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 UAA16376
	for ; Fri, 14 Apr 2000 20: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 D2AA344341; Fri, 14 Apr 2000 20:48:50 -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 634834433B
	for ; Fri, 14 Apr 2000 20:48:48 -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 UAA05028;
	Fri, 14 Apr 2000 20:51:39 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id UAA10528; Fri, 14 Apr 2000 20:50:48 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <249MPNTR>; Fri, 14 Apr 2000 20:51:39 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Basavaraj.Patil@nokia.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Fri, 14 Apr 2000 20:51:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Please see my comments below :

-----Original Message-----
From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
Sent: Friday, April 14, 2000 4:11 PM
To: Roy, Radhika R, ALARC
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off




Comments below:

Radhika wrote:
>Chris:

>Now there are internet-drafts related to SIP mobility as well.
>
The SIP WG charter does not currently include mobility solutions in
it's scope. However mobility support will be a key aspect of evolving
networks and there is a specific WG in the IETF which deals with it -
Mobile IP.
 Please see my earlier email why this work should be done in the SIP
WG.

>Let me clarify: If the network point of attachment is NOT changed, there is
>almost (some non-real-time mobility management may be needed) no need to do
>anything in the application layer (e.g., SIP, H.323). But it is only a
>special situation.
>
>In many situations, it may not be possible. We are addressing those from
>mobility management point of view. There can be two aspects of this: 
> 1.Should we consider hand-off in the appln layer? 
No. 

 I would be happy to do so if possible because the less work is better.
Do the technical contributions support this?

>2. Should we consider NO handoff in the appln layer?
The Mobile IP WG is currently debating multiple I-Ds that propose
handoffs at the network layer. If at all handoffs are to be moved to
upper layers (from link/physical layers) then it may be optimal to do
it at the network layer. 
 I would be happy to see the technical contributions how they provide
the solution in the link and/or application layer without affecting the SIP
layer. Even if the hand-off is provided in the lower layer, there are other
things as well - location updates. How this affects the SIP application
layer need to be seen. It appears the SIP layer will be involved as it is
seen from the present contributions.

-Basavaraj

>
>I hope that we could agree that the mobility solution would be transparent
>to the application layer (we could save our time)!
>
>Best regards,
>Radhika


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


From sip-admin@lists.bell-labs.com  Fri Apr 14 20:58:15 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16425
	for ; Fri, 14 Apr 2000 20:58: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 248BE4434E; Fri, 14 Apr 2000 20:55: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 CA41944337
	for ; Fri, 14 Apr 2000 20:55:12 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2JR0KJVC>; Fri, 14 Apr 2000 17:58:55 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'James Kempf'" , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol
Date: Fri, 14 Apr 2000 17:58:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi James,

Have you considered the SUBSCRIBE & NOTIFY methods ("SIP for Presence"
draft)? These methods can be used by a UA to request future notification of
specified asynchronous events (according to my understanding of it).  This
seems to be what you are wanting in a least a few of your bullets.

Cheers,

Robert.

-----Original Message-----
From:	James Kempf [mailto:James.Kempf@Eng.Sun.COM]
Sent:	Saturday, April 15, 2000 5:59 AM
To:	sip@lists.bell-labs.com
Cc:	James.Kempf@Eng.Sun.COM
Subject:	[SIP] SIP Info Method and IS-41 Cellular Signalling Protocol

I'm working on a design for replacing the IS-41 North American cellular
signalling protocol with IP protocols. I had a couple of questions about
how the SIP INFO method, or potentially another SIP method, might
be used.

1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange
of radio signal strength information is explicitly mentioned as
an application of the SIP INFO method. The HandoffMeasurementRequest
and HandoffMeasurementRequest2 messages in IS-41 are sent by the anchor
Mobile Switching Center (MSC) to a potential serving MSC to obtain
information 
about the signal strength of a Mobile Station (MS) in order to determine
if the potential serving MSC is a better candidate for handling the
mobile's call (called "hard handoff" in cellular jargon). They could be 
replaced with a SIP INFO method. There are three problems:

	a) The radio information is always solicited by the anchor MSC,
	and from the ID, the SIP INFO method seems like it is 
	sent unsolicted. I suppose one could come up with two INFO
	methods, one to solicit the radio information and one to
	return it, but this seems like a hack somehow.
	
	b) In the ID, it explicitly states that the INFO method is 
	only applicable when there is a call in progress. Problem is,
	there isn't a call in progress between the anchor MSC and
	the serving MSC, that's why the anchor MSC is soliciting
	the radio quality information in the first place.
	
	c) The INFO method seems like it is meant to be sent between 
	SIP UAC's, while the HandoffMeasurementRequest(2) methods
	are primarily designed to be sent between network elements.
	A SIP replacement would probably be sent between the last hop SIP
	proxies acting as Call Agents (CAs) for the call, which replaces
	the MSC in an all IP network.

2) There are a bunch of IS-41 messages that involve transmitting
feature or other information between the MS's Home Location
Register (HLR) and the MS. These are initiated by either the serving
MSC or the HLR. Examples are InformationDirective, which is used
by the HLR to provide notifications to an idle MS, and FeatureRequest,
which sends particular features to a potentially idle MS (features
being things like messages or playing particular tones). Again, these
seem like candidates to replace with the SIP INFO message, but 
the potential lack of any call in progress would prohibit that.

The alternative I could see would be establishing a session in order
to then send the information via the INFO method, but that seems like
overkill. And in the case of HandoffMeasurementRequest(2), the
message isn't intended for a SIP UAC anyway.

Maybe SIP is the wrong protocol to consider, since it is dedicated
to setting up and maintaining sessions, and not to exchanging information
between network elements or between network elements and terminals?

Can anybody provide some guidance?

		jak



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr 14 23:39:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19645
	for ; Fri, 14 Apr 2000 23:39: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 34AEC44338; Fri, 14 Apr 2000 23:36:01 -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 2C7BC44336
	for ; Fri, 14 Apr 2000 23:35:59 -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 UAA25382;
	Fri, 14 Apr 2000 20:38:54 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ACV01410;
	Fri, 14 Apr 2000 20:37:12 -0700 (PDT)
Message-Id: <4.2.0.58.20000414201955.00c3e150@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 14 Apr 2000 20:23:53 -0700
To: Michael Thomas 
From: Rohan Mahy 
Subject: Re: [SIP] end to end key transport
Cc: sip@lists.bell-labs.com
In-Reply-To: <200004141529.IAA02653@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi,

I wanted to point out that you can use k= is a few different ways:

k=base64:   which suffers from the problem your mention
k=prompt:  i don't know how this is supposed to work
k=:

the URL could use the https: scheme to grab a key.  while clearly 
suboptimal, this could work in a relatively secure fashion.  sorry that i 
don't remember what  is off the top of my head.

thanks,
-rohan




At 08:29 AM 4/14/00 , Michael Thomas wrote:

>While it's potentially OK to have a pre-shared
>secret between a proxy and a UA, it clearly
>doesn't scale well to have a mesh of pre-shared
>secrets between all of the UA's for end to end
>authentication of SIP traffic. As far as I can
>remember, there's a way to send a key end to end
>in the k: field of SDP, but that suffers from
>two problems:
>
>1) the key is intended for what the SDP
>    announcement is describing, which is normally
>    just a media descriptor. I don't think it
>    is intended to be used for SIP session level
>    keying. If there's a standard way to describe
>    how to tell the UAS that that key ought to
>    also be used for, say, http-authenticate's,
>    that would probably be a fine solution.
>
>2) the key is shipped in the clear. If there
>    is no underlying transport crypto, then
>    the key is really in the clear which makes
>    the entire use of crypto rather dubious.
>
>Toward the latter, assuming there is no transport
>level security, maybe an acceptable alternative is
>to use hop-by-hop keying between the UAC->Po Po->Pt
>and Pt->UAS. In that case, we could use the
>existing pre-shared secret for proxy-authenticate,
>say, to encrypt the key itself in the SDP
>announcement.
>
>Has anybody thought about this issue before? Is
>this one of those areas where header encryption
>might actually be useful, but for hop-by-hop
>instead of end to end?
>
>            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 Apr 14 23:39: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 XAA19656
	for ; Fri, 14 Apr 2000 23:39: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 6D18344336; Fri, 14 Apr 2000 23:36:07 -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 65C654433B
	for ; Fri, 14 Apr 2000 23:36:02 -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 UAA25385;
	Fri, 14 Apr 2000 20:38:54 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ACV01411;
	Fri, 14 Apr 2000 20:37:12 -0700 (PDT)
Message-Id: <4.2.0.58.20000414203409.00c2d4d0@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 14 Apr 2000 20:37:56 -0700
To: "Roy, Radhika R, ALARC" 
From: Rohan Mahy 
Subject: RE: [SIP] SIP and soft hand-off
Cc: Basavaraj.Patil@nokia.com, 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:  
X-BeenThere: sip@lists.bell-labs.com

At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a 
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff 
would be considered as part of the scope of "mobility".

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  Sun Apr 16 18: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 SAA10880
	for ; Sun, 16 Apr 2000 18:41:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 888E944336; Sun, 16 Apr 2000 18:37:52 -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 176A444336
	for ; Sat, 15 Apr 2000 17:33:03 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Sat Apr 15 17:34:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 3B3B444344; Sat, 15 Apr 2000 17:21:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id A0CB344341
	for ; Sat, 15 Apr 2000 17:21:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3EFD952BB; Sat, 15 Apr 2000 17:21:07 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6E2AF52AB
	for ; Sat, 15 Apr 2000 17:21:04 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sat Apr 15 17:20:53 EDT 2000
Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Sat Apr 15 17:20:53 EDT 2000
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id XAA13635
	for ; Sat, 15 Apr 2000 23:20:51 +0200 (MET DST)
Received: from uabs28 (uabs28i3 [134.138.201.3])
	by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.25) with ESMTP id e3FLKob29750
	for ; Sat, 15 Apr 2000 23:20:51 +0200 (MET DST)
Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2)
	id XAA16793; Sat, 15 Apr 2000 23:20:46 +0200 (MET DST)
Message-ID: <38F8DD2D.911858AA@uab.ericsson.se>
Date: Sat, 15 Apr 2000 23:20:45 +0200
From: Rabbe Fogelholm 
Organization: Ericsson Utvecklings AB
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id XAA13635
Subject: [SIP] Re: Availability of RFC2543bis in 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10880

> Mark Wisdom wrote:
> > 
> > RFC2543bis is available in PDF and PostScript formats, i.e.:
> > 
> > But I can't find a plain ASCII version anywhere. If an ASCII version
> > exists, can someone please tell us where we can find it (some of you
> > have been referring to sip_2543bis_00.txt). If not, can one please be
> > made available. I like having an ASCII version for quick grep-style
> > scanning of information.
> 
> Since conversion of a document of that size takes some of (my) time, it
> will happen when it is submitted as an Internet draft in a week or two.
> Your patience is appreciated.
>
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

I am quite pleased with the PDF version for its general readability.
However, there is one line in the PDF version of RFC2543bis which has me
confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
- hexseq ”::” [ hexseq ] - ”::” [ hexseq ]', although the hyphens are
actually elongated ones (octal code 227, outside the 7-bit ASCII
alphabet). Should there simply be vertical bars here?

--Rabbe Fogelholm, Ericsson Network Core Products



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


From sip-admin@lists.bell-labs.com  Sun Apr 16 21:13:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11781
	for ; Sun, 16 Apr 2000 21:13:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4283A44339; Sun, 16 Apr 2000 21:09:50 -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 9FD7E44337
	for ; Sun, 16 Apr 2000 21:09:47 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id VAA11465;
	Sun, 16 Apr 2000 21:12:44 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d22.cc.telcordia.com [128.96.11.22] (may be forged))
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id VAA02346;
	Sun, 16 Apr 2000 21:12:42 -0400 (EDT)
Message-ID: <38FA6414.59FF73FE@research.telcordia.com>
Date: Sun, 16 Apr 2000 21:08:36 -0400
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: James Kempf 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and soft hand-off
References: <200004142300.QAA27038@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

James Kempf wrote:

> Given these constraints, I am skeptical about replacing soft handoff
> with either L3 (mobile IP or any of the pre-frame selection
> micromobility proposals) or L7 (SIP) mechanisms. Should the radio
> manufacturers and cellular operators desire it, it would be interesting to look
> at an Open RAN protocol that would take the current proprietary soft handoff
> mechanisms and standardize them.

The goal is NOT to replace soft hand-off with any L3 or L7 mechanisms,
but to devise L3 and/or L7 mobility mechanisms that utilize the soft hand-off
mechanism correctly (i.e., create multiple streams that satisfy delay jitter
requirements and contain identical information).

> But, for now, I think any IP mobility
> solutions need to be restricted to post frame selection, i.e. hard handoff
> only.

More work is needed before arriving at a conclusion.

Regards, Faramak


>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 17 05:24:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27879
	for ; Mon, 17 Apr 2000 05:24: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 E71294433A; Mon, 17 Apr 2000 05:20:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from felix.intertex.se (unknown [195.22.82.2])
	by lists.bell-labs.com (Postfix) with ESMTP id BCBB144337
	for ; Mon, 17 Apr 2000 05:20:40 -0400 (EDT)
Date: Mon, 17 Apr 2000 11:23:39 +0200 (CEST)
From: Lars Berggren 
To: Anders Clausen 
Cc: sip@lists.bell-labs.com, confctrl@isi.edu
Subject: Re: [SIP] Key agreement using SIP/SDP?
In-Reply-To: <4.3.1.0.20000410150556.00a76ae0@pop3.intertex.se>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


Anders and Thomas,

I am cc-ing this to the mmusic list since SDP is involved here.

First, I would say that you probably shouldn't say that it is the 180
response that contains the key agreement information, as I think that any 
response containing SDP is likely to be suitable. (183 and 200)

Second, I like the mechanism described here regarding agreement on keys
for RTP level encryption. However, as there has been no responses in this
thread from the WG, I would like to bring attention from the WG to this
topic again, hoping for more interest this time.

Does anyone else have comments on this? I really would like to see some
more discussion in this topic. What about the SIP security team, any
thoughts in this direction?

How about writing an ID on this to specify it clearer?


The advantages I can see with the proposal are:
1) Works through NATs.
2) It could be made generic. I believe any need for negotiation between
caller and callee when agreeing on a session key or shared secret (like 
diffie-hellman) could be signaled this way.
3) No need to rely on an infra-structure for fetching of public keys.

Disadvantages:
1) Another extension to SIP/SDP ?
2) The same key is used in the streams caller->callee and 
callee->caller. There may be applications that need to have different
keys in each stream.


Regards
Lars


On Mon, 10 Apr 2000, Anders Clausen wrote:
> Hello,
> 
> We are two students writing on a graduate thesis about VoIP security
> with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> new to this, and would be grateful for help on this subject.
> 
> There are some problems transferring or agreeing on a session
> encryption key using the k= field in SDP, if one are to send it in a
> SIP INVITE through a NAT. Since the NAT needs to change some fields in
> the SDP description, the SDP must not be encrypted.
> 
> The end user should be oblivious of the FW/NAT and thus should neither
> query it for the adresses to enter into the SDP, nor depend on the FW
> to encrypt anything.
> 
> A couple of possible solutions (?).
> 
> The simplest (and least secure) way to transfer a symmetric key would
> be that the caller enters his public key (or Diffie-Hellman "A") into
> the k= field of the SDP.
> 
> "k=base64:"
> 
> together with a couple of attributes that could look something like
> 
> "a=key-encr-alg:RSA"
> or
> "a=key-encr-alg:D-H"
> 
> for describing the algorithm the key in the k= field corresponds to,
> and
> 
> "a=media-encr-alg:3DES-CBC"
> 
> for describing preferred media encryption algorithm.
> 
> In case of RSA, the "callers key" is the public key, corresponding to
> a private key only known by him. In case of Diffie-Hellman the
> "callers key" is the "A"-part of the partly built media key.
> 
> The callee then generates a "callee key". In case of RSA, this is the
> symmetric media key, encrypted using the callers public key. In case
> of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> built symmetric media key. The callee sends this back in the k= field
> in the SDP of the 180 response. Should the callee fail to meet the
> specific security wishes of the caller, it could simply omit the k=
> field in the response, and the caller could choose to proceed and not
> encrypt the media or just hang up.
> 
>   CALLER		          SIP-PROXY(s)                   CALLEE
>     |                           |                           |
>     | INVITE w/SDP(caller's key)|                           |
>     |-------------------------->| INVITE w/SDP(caller's key)|
>     |                           |-------------------------->|
>     |                           |                           |
>     |                           |   100                     |
>     |   100                     |<--------------------------|
>     |<--------------------------|                      Key generation
>     |                           |   180 w/SDP(callee's key) |
>     |   180 w/SDP(callee's key) |<--------------------------|
>     |<--------------------------|                           |
> 
> Another way could be to insert something similar to a TLS handshake
> (or some other more secure way of agreeing on or transferring keys)
> into the Reservation stage in the QoS/security negotiation described
> in draft-manyfolks-sip-resource-00.txt.
> 
> This would probably also need a couple of attributes to tell the
> callee which handshake protocol should be used.
> 
> Comments?
> 
> (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> number of drafts, we have not found any solutions to the problems
> described above.)
> 
> ---
> Anders Clausen 
> Thomas Karlsson 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

Lars Berggren       
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414



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


From sip-admin@lists.bell-labs.com  Mon Apr 17 08:14:07 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00340
	for ; Mon, 17 Apr 2000 08:14:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D07A4433C; Mon, 17 Apr 2000 08:10:53 -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 94A0444337
	for ; Mon, 17 Apr 2000 08:10:50 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 17 08:12:18 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id C2C2044344; Mon, 17 Apr 2000 07:59:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 8FBCE44341
	for ; Mon, 17 Apr 2000 07:59:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 4351C52BB; Mon, 17 Apr 2000 07:59:07 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 77E7F52B6
	for ; Mon, 17 Apr 2000 07:59:04 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Apr 17 07:57:35 EDT 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Apr 17 07:57:34 EDT 2000
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA17348;
	Mon, 17 Apr 2000 07:57:28 -0400 (EDT)
Message-ID: <38FAFC28.BABBC52D@cs.columbia.edu>
Date: Mon, 17 Apr 2000 07:57:28 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Rabbe Fogelholm 
Cc: sip@lists.research.bell-labs.com
Subject: Re: [SIP] Re: Availability of RFC2543bis in ASCII
References: <38F8DD2D.911858AA@uab.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Rabbe Fogelholm wrote:
> 

> I am quite pleased with the PDF version for its general readability.
> However, there is one line in the PDF version of RFC2543bis which has me
> confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
> - hexseq ?::? [ hexseq ] - ?::? [ hexseq ]', although the hyphens are
> actually elongated ones (octal code 227, outside the 7-bit ASCII
> alphabet). Should there simply be vertical bars here?

Yes; LaTeX error of omitting $'s...


-- 
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 Apr 17 09:15: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 JAA02017
	for ; Mon, 17 Apr 2000 09:15: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 7BCF64433B; Mon, 17 Apr 2000 09:12:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 5128B44337
	for ; Mon, 17 Apr 2000 09:12:08 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA00225;
	Mon, 17 Apr 2000 09:15:12 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA12981; Mon, 17 Apr 2000 09:16:29 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 17 Apr 2000 09:15:10 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Rohan Mahy 
Cc: Basavaraj.Patil@nokia.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Mon, 17 Apr 2000 09:15:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Rohan:

Pl. see my comments below .

Thanks,
Radhika R. Roy
AT&T

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, April 14, 2000 11:38 PM
To: Roy, Radhika R, ALARC
Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off


At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a 
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff 
would be considered as part of the scope of "mobility".

 "We" means the members who are interested for extension of SIP to
support mobility as some discussion was held based on the internet draft in
the last IETF meeting. Yes, "soft-handoff" may not be a part of SIP mobility
if it does not affect the application (i.e., SIP) layer resources.

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 Apr 17 09:35: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 JAA02549
	for ; Mon, 17 Apr 2000 09:35:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8E9A944344; Mon, 17 Apr 2000 09:32:24 -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 2B95E44343
	for ; Mon, 17 Apr 2000 09:32:22 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id B0D184CE19
	for ; Mon, 17 Apr 2000 09:35:28 -0400 (EDT)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA15841
	for ; Mon, 17 Apr 2000 09:35:27 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id JAA11105
	for sip@lists.bell-labs.com; Mon, 17 Apr 2000 09:35:26 -0400 (EDT)
Date: Mon, 17 Apr 2000 09:35:26 -0400 (EDT)
Message-Id: <200004171335.JAA11105@fish-ha.research.att.com>
To: sip@lists.bell-labs.com
Subject: [SIP] QoS-Enabled and manyfolks 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:  
X-BeenThere: sip@lists.bell-labs.com

The following message was sent to the list on April 6,
but I never received it back.  Apologies to all who
got it then, and have to read it again.

Bill Marshall
wtm@research.att.com

> To: sip@lists.bell-labs.com
> Subject: QoS-Enabled and manyfolks draft
> 
> Henry Sinnreich and I have been looking into whether the
> manyfolks draft covers QoS-Enabled as well as QoS-Assured.
> Our conclusion is that the mechanism described covers it,
> but that some additional text describing the procedures
> is needed.
> 
> The procedures for QoS-Enabled would be like this:
> 
> The caller sends an INVITE, with a line in SDP that says
> a=qos:optional sendrecv.  UAS gets that and sends back a 183
> (acording to manyfolks draft) that includes an SDP, with a line
> a=qos:optional sendrecv confirm.  Originator tries and fails
> to get qos, but that is OK since qos was only optional, so its
> PRECONDITION-MET message says a=qos:failure sendrecv.  UAC
> obviously made a decision to proceed, in that it sent
> the PRECONDITION-MET message.
> 
> Maybe UAC asked the originating user before deciding this, like
> a "can't get QoS.  Proceed? (y or n)?"
> 
> UAS then makes the choice of whether to proceed or not, and
> sends either 180-Ringing or 580-Precondition-Failure.  Maybe it
> asked the destination user the same question, but with a
> distinct ringing sequence.  If lack of QoS is accepted, UAS
> sends the 200-OK and call completes with best-effort.
> 
> Comments?
> 
> Bill Marshall
> wtm@research.att.com


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


From sip-admin@lists.bell-labs.com  Mon Apr 17 10: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 KAA03755
	for ; Mon, 17 Apr 2000 10:57: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 6215F4433E; Mon, 17 Apr 2000 10:54:28 -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 2BD2D44337
	for ; Mon, 17 Apr 2000 10:54:25 -0400 (EDT)
Received: from provin-pc (provin-pc [192.4.8.117])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with SMTP id KAA09386
	for ; Mon, 17 Apr 2000 10:57:36 -0400 (EDT)
From: "Provin Gurung" 
To: 
Date: Mon, 17 Apr 2000 10:57:37 -0400
Message-ID: <004601bfa87d$45844d20$750804c0@provin-pc.research.telcordia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: 
Subject: [SIP] Proxy behavior for 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,
 I have a question regarding the behavior of proxy on receiving a CANCEL.
Consider, a forking Proxy received an INVITE and it forked and forwarded the
INVITE to multiple servers downstream, Now along comes a CANCEL from an
upstream client.  The proxy is supposed to fork and send the CANCEL to the
branches which have not yet responded.

How should the proxy react,
(a) if it already received a 2xx response from one of the downstream
branches, (This would be if the final response from the proxy to the
upstream client and the CANCEL crossed over each other.)
- I guess it should be 481 (Transaction not found)

(b) The proxy has not received  2xx nor 6xx from any branches.
Should the proxy send back a 2xx for the CANCEL  immediately and not care
how the downstream servers respond to the CANCEL that is forked by this
proxy, or should it wait till the unfinished branches respond to the forked
CANCEL and then depending on this result send back a CANCEL, i.e. the proxy
send back a 200 CANCEL upstream if the proxy receives a 2xx for all the
forked CANCEL from all it's branches, or maybe proxy the 2xx for INVITE, if
one of the branches respond with 200 for INVITE  ( cross over for the forked
INVITE and forked CANCEL in one of the proxy) and resonpond say 481 for the
CANCEL.

If the proxy responds immediately with 2xx for CANCEL, it is possible that
the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE
(Taking into consideration , that if a Proxy receives a 2xx for INVITE from
one of the branches, after it has sent a 2xx for CANCEL upstream, it still
forwards the 2xx for the CANCEL to the upstream client). How does the UA
handle this case.


Sorry for not keeping it short, I tried to look up the rfc but could not
find it discussing the above scenario.

Thanks in advance,
Provin

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Roy, Radhika R, ALARC
> Sent: Monday, April 17, 2000 9:15 AM
> To: Rohan Mahy
> Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> Hi, Rohan:
>
> Pl. see my comments below .
>
> Thanks,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Friday, April 14, 2000 11:38 PM
> To: Roy, Radhika R, ALARC
> Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
> >Hi, Everyone:
> >
> >My comments are as follows:
> >
> >1. We are extending SIP to support mobility in the application layer. So,
> >SIP WG is the right place. The SIP WG is the only group that
> knows what to
> >do the SIP protocol in the application layer.
>
> Hi,
>
> Who is the "we" here?  To be specific, has this been formally
> included as a
> topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff
> would be considered as part of the scope of "mobility".
>
>  "We" means the members who are interested for extension of SIP to
> support mobility as some discussion was held based on the
> internet draft in
> the last IETF meeting. Yes, "soft-handoff" may not be a part of
> SIP mobility
> if it does not affect the application (i.e., SIP) layer resources.
>
> thanks,
> -rohan
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>



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


From sip-admin@lists.bell-labs.com  Mon Apr 17 13:41:55 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06638
	for ; Mon, 17 Apr 2000 13:41:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3245044337; Mon, 17 Apr 2000 13:38:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 5110244336
	for ; Mon, 17 Apr 2000 13:38:36 -0400 (EDT)
Received: from pc64 (pc64.tct.hut.fi [130.233.154.64])
	by keskus.tct.hut.fi (8.10.0/8.10.0) with SMTP id e3HHg1M02090;
	Mon, 17 Apr 2000 20:42:01 +0300 (EET DST)
Date: Mon, 17 Apr 2000 20:42:01 +0300 (EET DST)
From: jose 
Message-Id: <20000417204431jose@tct.hut.fi@pc64>
Content-Type: text/plain
To: dean.willis@wcom.com, sip@lists.bell-labs.com, mat@cisco.com
Subject: Re:[SIP] SIP and soft hand-off
X-Mailer: Pronto E-Mail [ver 4.0.2.6]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi all,


Dear colleagues, I am following the SIP development and now regarding the 
mobility problem I would like to point out some situations in a SIP 
environment.

In all the cases treated till now all the SIP UA have the REGISTER 
capability and they can find using one or other way (DHCP, SLP) the closest 
registrar server to make the registration.

The problem here arise when we are dealing with a plain UA with the simplest 
capabilities (not including REGISTER). In this case how could notify the UA 
its location to other entities. How can be that UA available to others UA or 
proxies if it has not been registered anywhere?
This is the specific case when an IP device obtain its mobile address starts 
using it for other needs. Initially, it has assigned a mobile IP address for 
other matters and afterwards it launch the SIP UA in case someone wants to 
call him, but that UA has not been registered anywhere.

In the case that we have a complete implementation of the UA including the 
registration feature but the nearest SIP proxy does not have that 
capability, we find the same problem again.

In resume, I am wondering if there is any mean to locate an IP device 
independently if is for IP telephony, mail service, or whatever?

Any suggestion about any solution or clue about any working group related to 
these problems would be welcome.

Thanks
Best Regards
Jose


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


From sip-admin@lists.bell-labs.com  Mon Apr 17 20:19: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 UAA11892
	for ; Mon, 17 Apr 2000 20:19: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 7533F44337; Mon, 17 Apr 2000 20:16:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id D2C0444336
	for ; Mon, 17 Apr 2000 20:16:36 -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 RAA26205;
	Mon, 17 Apr 2000 17:19:53 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ACY05283;
	Mon, 17 Apr 2000 17:18:11 -0700 (PDT)
Message-Id: <4.2.0.58.20000417112012.00c6d4f0@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 17 Apr 2000 11:22:11 -0700
To: sip@lists.bell-labs.com
From: Rohan Mahy 
Cc: Mark Handley 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Fwd: Inconsistency between SIP and SDP (was Re: Setting SDP
 values for Unicast)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

FYI:

seemed pertinent to the SIP list as well....

>From: Mark Handley 
>X-Organisation: ACIRI
>To: Henning Schulzrinne 
>cc: Nicolas Quartier , confctrl@ISI.EDU
>Subject: Re: Setting SDP values for Unicast
>Date: Sun, 16 Apr 2000 15:04:03 -0700
>Sender: owner-confctrl@ISI.EDU
>X-SMTP-HELO: zephyr.isi.edu
>X-SMTP-MAIL-FROM: confctrl-owner@ISI.EDU
>X-SMAP-Received-From: outside
>X-SMTP-PEER-INFO: zephyr.isi.edu [128.9.160.160]
>
>
> >> I think I found an inconsistency between RFC2543(SIP) and RFC2327
> >> (SDP).
> >> Section B2 of RFC2543 deals with the setting of SDP values for Unicast
> >> and there it
> >> is mentioned that:
> >>
> >> If caller and callee have no media formats in common for a particular
> >> stream, the callee MUST return a session description containing the
> >> particular "m=" line, but with the port number set to zero, and no
> >> payload types listed.
> >>
> >> But according to RFC2327, at least 1 payload type should be present
> >> in the "m=" line.
> >
> >This should probably be brought to the attention of the SDP authors, to
> >be either fixed in the next version or otherwise resolved. Thanks.
>
>Actually this sounds more like an SIP spec bug in its usage of SDP
>than an SDP spec bug.  This usage is pushing the envelope of the
>semantics of what SDP was defined for, but even so, the SIP spec
>should not have stepped outside of valid SDP syntax.  A simple
>solution would be to define in the SIP spec that in this context "-"
>as a format means no formats in common.
>
>Thanks to Nicholas for pointing this out - we definitely need to
>decide on a single solution for this before we take SDP and SIP to
>draft standard.
>
>Cheers,
>         Mark



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


From sip-admin@lists.bell-labs.com  Mon Apr 17 23:36: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 XAA15441
	for ; Mon, 17 Apr 2000 23:36: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 6AD4044337; Mon, 17 Apr 2000 23:33:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E41F244336
	for ; Mon, 17 Apr 2000 23:33:00 -0400 (EDT)
Received: from dynamicsoft.com ([63.38.191.103])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA26110;
	Mon, 17 Apr 2000 23:37:17 -0400 (EDT)
Message-ID: <38FBDA51.E6925FA4@dynamicsoft.com>
Date: Mon, 17 Apr 2000 23:45:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren 
Cc: Anders Clausen , sip@lists.bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: [SIP] Key agreement using SIP/SDP?
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

My general feeling is queasiness. Security protocols are hard to get
right. In general, wherever possible, I would prefer to use a real,
established, tested, and understood security protocol rather than try to
add one into SIP itself. In this case, we have numerous key exchange
protocols at our disposal, including IKE and kerberos. 

-Jonathan R.

Lars Berggren wrote:
> 
> Anders and Thomas,
> 
> I am cc-ing this to the mmusic list since SDP is involved here.
> 
> First, I would say that you probably shouldn't say that it is the 180
> response that contains the key agreement information, as I think that any
> response containing SDP is likely to be suitable. (183 and 200)
> 
> Second, I like the mechanism described here regarding agreement on keys
> for RTP level encryption. However, as there has been no responses in this
> thread from the WG, I would like to bring attention from the WG to this
> topic again, hoping for more interest this time.
> 
> Does anyone else have comments on this? I really would like to see some
> more discussion in this topic. What about the SIP security team, any
> thoughts in this direction?
> 
> How about writing an ID on this to specify it clearer?
> 
> The advantages I can see with the proposal are:
> 1) Works through NATs.
> 2) It could be made generic. I believe any need for negotiation between
> caller and callee when agreeing on a session key or shared secret (like
> diffie-hellman) could be signaled this way.
> 3) No need to rely on an infra-structure for fetching of public keys.
> 
> Disadvantages:
> 1) Another extension to SIP/SDP ?
> 2) The same key is used in the streams caller->callee and
> callee->caller. There may be applications that need to have different
> keys in each stream.
> 
> Regards
> Lars
> 
> On Mon, 10 Apr 2000, Anders Clausen wrote:
> > Hello,
> >
> > We are two students writing on a graduate thesis about VoIP security
> > with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> > new to this, and would be grateful for help on this subject.
> >
> > There are some problems transferring or agreeing on a session
> > encryption key using the k= field in SDP, if one are to send it in a
> > SIP INVITE through a NAT. Since the NAT needs to change some fields in
> > the SDP description, the SDP must not be encrypted.
> >
> > The end user should be oblivious of the FW/NAT and thus should neither
> > query it for the adresses to enter into the SDP, nor depend on the FW
> > to encrypt anything.
> >
> > A couple of possible solutions (?).
> >
> > The simplest (and least secure) way to transfer a symmetric key would
> > be that the caller enters his public key (or Diffie-Hellman "A") into
> > the k= field of the SDP.
> >
> > "k=base64:"
> >
> > together with a couple of attributes that could look something like
> >
> > "a=key-encr-alg:RSA"
> > or
> > "a=key-encr-alg:D-H"
> >
> > for describing the algorithm the key in the k= field corresponds to,
> > and
> >
> > "a=media-encr-alg:3DES-CBC"
> >
> > for describing preferred media encryption algorithm.
> >
> > In case of RSA, the "callers key" is the public key, corresponding to
> > a private key only known by him. In case of Diffie-Hellman the
> > "callers key" is the "A"-part of the partly built media key.
> >
> > The callee then generates a "callee key". In case of RSA, this is the
> > symmetric media key, encrypted using the callers public key. In case
> > of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> > built symmetric media key. The callee sends this back in the k= field
> > in the SDP of the 180 response. Should the callee fail to meet the
> > specific security wishes of the caller, it could simply omit the k=
> > field in the response, and the caller could choose to proceed and not
> > encrypt the media or just hang up.
> >
> >   CALLER                        SIP-PROXY(s)                   CALLEE
> >     |                           |                           |
> >     | INVITE w/SDP(caller's key)|                           |
> >     |-------------------------->| INVITE w/SDP(caller's key)|
> >     |                           |-------------------------->|
> >     |                           |                           |
> >     |                           |   100                     |
> >     |   100                     |<--------------------------|
> >     |<--------------------------|                      Key generation
> >     |                           |   180 w/SDP(callee's key) |
> >     |   180 w/SDP(callee's key) |<--------------------------|
> >     |<--------------------------|                           |
> >
> > Another way could be to insert something similar to a TLS handshake
> > (or some other more secure way of agreeing on or transferring keys)
> > into the Reservation stage in the QoS/security negotiation described
> > in draft-manyfolks-sip-resource-00.txt.
> >
> > This would probably also need a couple of attributes to tell the
> > callee which handshake protocol should be used.
> >
> > Comments?
> >
> > (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> > number of drafts, we have not found any solutions to the problems
> > described above.)
> >
> > ---
> > Anders Clausen 
> > Thomas Karlsson 
> >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> 
> Lars Berggren       
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

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


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


From sip-admin@lists.bell-labs.com  Tue Apr 18 02:31: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 CAA28551
	for ; Tue, 18 Apr 2000 02:31: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 72C4744342; Tue, 18 Apr 2000 02:28:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from eins.siemens.at (eins.siemens.at [193.81.246.11])
	by lists.bell-labs.com (Postfix) with ESMTP id BE0164433E
	for ; Tue, 18 Apr 2000 02:28:18 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix-hme0 [10.1.140.2])
	by eins.siemens.at  with ESMTP id IAA18606
	for ; Tue, 18 Apr 2000 08:24:40 +0200 (MET DST)
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id IAA17821
	for ; Tue, 18 Apr 2000 08:31:30 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(195.1.196.94) by scesie13 via smap (V2.0beta)
	id xma017637; Tue, 18 Apr 00 08:31:04 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2650.21)
	id ; Tue, 18 Apr 2000 08:31:44 +0200
Message-ID: 
From: Postmann Erwin 
To: "'sip@lists.bell-labs.com'" 
Date: Tue, 18 Apr 2000 08:31:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
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:  
X-BeenThere: sip@lists.bell-labs.com

Dear all,

I am new on the list and have a question regarding the status of the
following internet draft "SIP call control services"
(draft-ietf-mmusic-sip-cc-01.txt), which is  expired December 1999.

Is there a new version of the draft (or maybe other drafts covering the
ideas) planed or even already available?


Best regards


Erwin Postmann
SIEMENS AG Austria
Program and System Engineering
Mobile Networks Solutions - Product Marketing 

Autokaderstrasse 29
A-1210 Vienna

Tel:	+43.5.1707.21398
Fax:	+43.5.1707.51924
GSM:	+43.664.1010034
email:	erwin.postmann@siemens.at 





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


From sip-admin@lists.bell-labs.com  Tue Apr 18 03: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 DAA28843
	for ; Tue, 18 Apr 2000 03:24: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 064BD44339; Tue, 18 Apr 2000 03:20:50 -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 770C544336
	for ; Tue, 18 Apr 2000 03:20:47 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2JR0KNMK>; Tue, 18 Apr 2000 00:25:07 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'alan.johnston@wcom.com'" 
Cc: "'sip@lists.bell-labs.com'" 
Date: Tue, 18 Apr 2000 00:25:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] SIP Call Flows and 487 Request Cancelled
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


I noticed that response 487 Request Cancelled is missing from the CANCEL
examples of the SIP Call Flows draft. I'm not sure whether this because the
call flows does not incorporate RFC2543bis or whether this is a genuine
omission.

Cheers,

Robert.


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


From sip-admin@lists.bell-labs.com  Tue Apr 18 04:43: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 EAA29330
	for ; Tue, 18 Apr 2000 04: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 EFCDE44342; Tue, 18 Apr 2000 04:40:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id BE84E44336
	for ; Tue, 18 Apr 2000 04:40:08 -0400 (EDT)
Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id  for ;
 Tue, 18 Apr 2000 09:37:16 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-24) id JAA05164; Tue, 18 Apr 2000 09:38:13 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 802568C5.002F681A ; Tue, 18 Apr 2000 09:37:48 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Surinder Ubhi" 
Reply-To: sip@lists.bell-labs.com
To: sip@lists.bell-labs.com
Message-ID: <802568C5.002F6480.00@marconicomms.com>
Date: Tue, 18 Apr 2000 09:37:31 +0100
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa"
Content-Disposition: inline
Subject: [SIP] SIP digest, Vol 1 #21 - 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:  
X-BeenThere: sip@lists.bell-labs.com

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





Send SIP mailing list submissions to
     sip@lists.bell-labs.com

To subscribe or unsubscribe via the web, visit
     http://lists.bell-labs.com/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
     sip-request@lists.bell-labs.com
You can reach the person managing the list at
     sip-admin@lists.bell-labs.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of SIP digest..."




Today's Topics:

  1. Re: Availability of RFC2543bis in ASCII (Rabbe Fogelholm)
  2. Re: SIP and soft hand-off (Faramak Vakil)
  3. Re: Key agreement using SIP/SDP? (Lars Berggren)
  4. Re: Re: Availability of RFC2543bis in ASCII (Henning Schulzrinne)
  5. RE: SIP and soft hand-off (Roy, Radhika R, ALARC)
  6. QoS-Enabled and manyfolks draft (William Marshall)
  7. Proxy behavior for CANCEL (Provin Gurung)



Message: 1
Return-Path: 
Delivered-To: sip@share.research.bell-labs.com
Delivered-To: sip@lists.bell-labs.com
Delivered-To: sip@lists.research.bell-labs.com
Message-ID: <38F8DD2D.911858AA@uab.ericsson.se>
Date: Sat, 15 Apr 2000 23:20:45 +0200
From: Rabbe Fogelholm 
Organization: Ericsson Utvecklings AB
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-sip@lists.bell-labs.com
Subject: [SIP] Re: Availability of RFC2543bis in ASCII



> Mark Wisdom wrote:
> >
> > RFC2543bis is available in PDF and PostScript formats, i.e.:
> >
> > But I can't find a plain ASCII version anywhere. If an ASCII version
> > exists, can someone please tell us where we can find it (some of you
> > have been referring to sip_2543bis_00.txt). If not, can one please be
> > made available. I like having an ASCII version for quick grep-style
> > scanning of information.
>
> Since conversion of a document of that size takes some of (my) time, it
> will happen when it is submitted as an Internet draft in a week or two.
> Your patience is appreciated.
>
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

I am quite pleased with the PDF version for its general readability.
However, there is one line in the PDF version of RFC2543bis which has me
confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
- hexseq 

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6::=

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6 [ hexseq ] - =

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6::=

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6 [ hexseq ]', although the hyphens
 are
actually elongated ones (octal code 227, outside the 7-bit ASCII
alphabet). Should there simply be vertical bars here?

--Rabbe Fogelholm, Ericsson Network Core Products


=

--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


Message: 2
Return-Path: 
Delivered-To: sip@lists.bell-labs.com
Message-ID: <38FA6414.59FF73FE@research.telcordia.com>
Date: Sun, 16 Apr 2000 21:08:36 -0400
From: Faramak Vakil 
Organization: Telcordia Technologies
MIME-Version: 1.0
To: James Kempf 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and soft hand-off
References: <200004142300.QAA27038@nasnfs.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



James Kempf wrote:

> Given these constraints, I am skeptical about replacing soft handoff
> with either L3 (mobile IP or any of the pre-frame selection
> micromobility proposals) or L7 (SIP) mechanisms. Should the radio
> manufacturers and cellular operators desire it, it would be interesting to
look
> at an Open RAN protocol that would take the current proprietary soft handoff
> mechanisms and standardize them.

The goal is NOT to replace soft hand-off with any L3 or L7 mechanisms,
but to devise L3 and/or L7 mobility mechanisms that utilize the soft hand-off
mechanism correctly (i.e., create multiple streams that satisfy delay jitter
requirements and contain identical information).

> But, for now, I think any IP mobility
> solutions need to be restricted to post frame selection, i.e. hard handoff
> only.

More work is needed before arriving at a conclusion.

Regards, Faramak


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





Message: 3
Return-Path: 
Delivered-To: sip@lists.bell-labs.com
Date: Mon, 17 Apr 2000 11:23:39 +0200 (CEST)
From: Lars Berggren 
To: Anders Clausen 
Cc: sip@lists.bell-labs.com, confctrl@isi.edu
Subject: Re: [SIP] Key agreement using SIP/SDP?
In-Reply-To: <4.3.1.0.20000410150556.00a76ae0@pop3.intertex.se>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII




Anders and Thomas,

I am cc-ing this to the mmusic list since SDP is involved here.

First, I would say that you probably shouldn't say that it is the 180
response that contains the key agreement information, as I think that any
response containing SDP is likely to be suitable. (183 and 200)

Second, I like the mechanism described here regarding agreement on keys
for RTP level encryption. However, as there has been no responses in this
thread from the WG, I would like to bring attention from the WG to this
topic again, hoping for more interest this time.

Does anyone else have comments on this? I really would like to see some
more discussion in this topic. What about the SIP security team, any
thoughts in this direction?

How about writing an ID on this to specify it clearer?


The advantages I can see with the proposal are:
1) Works through NATs.
2) It could be made generic. I believe any need for negotiation between
caller and callee when agreeing on a session key or shared secret (like
diffie-hellman) could be signaled this way.
3) No need to rely on an infra-structure for fetching of public keys.

Disadvantages:
1) Another extension to SIP/SDP ?
2) The same key is used in the streams caller->callee and
callee->caller. There may be applications that need to have different
keys in each stream.


Regards
Lars


On Mon, 10 Apr 2000, Anders Clausen wrote:
> Hello,
>
> We are two students writing on a graduate thesis about VoIP security
> with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> new to this, and would be grateful for help on this subject.
>
> There are some problems transferring or agreeing on a session
> encryption key using the k= field in SDP, if one are to send it in a
> SIP INVITE through a NAT. Since the NAT needs to change some fields in
> the SDP description, the SDP must not be encrypted.
>
> The end user should be oblivious of the FW/NAT and thus should neither
> query it for the adresses to enter into the SDP, nor depend on the FW
> to encrypt anything.
>
> A couple of possible solutions (?).
>
> The simplest (and least secure) way to transfer a symmetric key would
> be that the caller enters his public key (or Diffie-Hellman "A") into
> the k= field of the SDP.
>
> "k=base64:"
>
> together with a couple of attributes that could look something like
>
> "a=key-encr-alg:RSA"
> or
> "a=key-encr-alg:D-H"
>
> for describing the algorithm the key in the k= field corresponds to,
> and
>
> "a=media-encr-alg:3DES-CBC"
>
> for describing preferred media encryption algorithm.
>
> In case of RSA, the "callers key" is the public key, corresponding to
> a private key only known by him. In case of Diffie-Hellman the
> "callers key" is the "A"-part of the partly built media key.
>
> The callee then generates a "callee key". In case of RSA, this is the
> symmetric media key, encrypted using the callers public key. In case
> of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> built symmetric media key. The callee sends this back in the k= field
> in the SDP of the 180 response. Should the callee fail to meet the
> specific security wishes of the caller, it could simply omit the k=
> field in the response, and the caller could choose to proceed and not
> encrypt the media or just hang up.
>
>   CALLER                    SIP-PROXY(s)                   CALLEE
>     |                           |                           |
>     | INVITE w/SDP(caller's key)|                           |
>     |-------------------------->| INVITE w/SDP(caller's key)|
>     |                           |-------------------------->|
>     |                           |                           |
>     |                           |   100                     |
>     |   100                     |<--------------------------|
>     |<--------------------------|                      Key generation
>     |                           |   180 w/SDP(callee's key) |
>     |   180 w/SDP(callee's key) |<--------------------------|
>     |<--------------------------|                           |
>
> Another way could be to insert something similar to a TLS handshake
> (or some other more secure way of agreeing on or transferring keys)
> into the Reservation stage in the QoS/security negotiation described
> in draft-manyfolks-sip-resource-00.txt.
>
> This would probably also need a couple of attributes to tell the
> callee which handshake protocol should be used.
>
> Comments?
>
> (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> number of drafts, we have not found any solutions to the problems
> described above.)
>
> ---
> Anders Clausen 
> Thomas Karlsson 
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

Lars Berggren       
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414





Message: 4
Return-Path: 
Delivered-To: sip@share.research.bell-labs.com
Delivered-To: sip@lists.bell-labs.com
Delivered-To: sip@lists.research.bell-labs.com
Sender: hgs@cs.columbia.edu
Message-ID: <38FAFC28.BABBC52D@cs.columbia.edu>
Date: Mon, 17 Apr 2000 07:57:28 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
MIME-Version: 1.0
To: Rabbe Fogelholm 
Cc: sip@lists.research.bell-labs.com
Subject: Re: [SIP] Re: Availability of RFC2543bis in ASCII
References: <38F8DD2D.911858AA@uab.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Rabbe Fogelholm wrote:
>

> I am quite pleased with the PDF version for its general readability.
> However, there is one line in the PDF version of RFC2543bis which has me
> confused. The definition of "hexpart" on page 18 goes `hexpart = hexseq
> - hexseq ?::? [ hexseq ] - ?::? [ hexseq ]', although the hyphens are
> actually elongated ones (octal code 227, outside the 7-bit ASCII
> alphabet). Should there simply be vertical bars here?

Yes; LaTeX error of omitting $'s...


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




Message: 5
Return-Path: 
Delivered-To: sip@lists.bell-labs.com
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Rohan Mahy 
Cc: Basavaraj.Patil@nokia.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Mon, 17 Apr 2000 09:15:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;     charset="iso-8859-1"



Hi, Rohan:

Pl. see my comments below .

Thanks,
Radhika R. Roy
AT&T

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, April 14, 2000 11:38 PM
To: Roy, Radhika R, ALARC
Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off


At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff
would be considered as part of the scope of "mobility".

 "We" means the members who are interested for extension of SIP to
support mobility as some discussion was held based on the internet draft in
the last IETF meeting. Yes, "soft-handoff" may not be a part of SIP mobility
if it does not affect the application (i.e., SIP) layer resources.

thanks,
-rohan


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




Message: 6
Return-Path: 
Delivered-To: sip@lists.bell-labs.com
From: William Marshall 
Date: Mon, 17 Apr 2000 09:35:26 -0400 (EDT)
Message-Id: <200004171335.JAA11105@fish-ha.research.att.com>
To: sip@lists.bell-labs.com
Subject: [SIP] QoS-Enabled and manyfolks draft



The following message was sent to the list on April 6,
but I never received it back.  Apologies to all who
got it then, and have to read it again.

Bill Marshall
wtm@research.att.com

> To: sip@lists.bell-labs.com
> Subject: QoS-Enabled and manyfolks draft
>
> Henry Sinnreich and I have been looking into whether the
> manyfolks draft covers QoS-Enabled as well as QoS-Assured.
> Our conclusion is that the mechanism described covers it,
> but that some additional text describing the procedures
> is needed.
>
> The procedures for QoS-Enabled would be like this:
>
> The caller sends an INVITE, with a line in SDP that says
> a=qos:optional sendrecv.  UAS gets that and sends back a 183
> (acording to manyfolks draft) that includes an SDP, with a line
> a=qos:optional sendrecv confirm.  Originator tries and fails
> to get qos, but that is OK since qos was only optional, so its
> PRECONDITION-MET message says a=qos:failure sendrecv.  UAC
> obviously made a decision to proceed, in that it sent
> the PRECONDITION-MET message.
>
> Maybe UAC asked the originating user before deciding this, like
> a "can't get QoS.  Proceed? (y or n)?"
>
> UAS then makes the choice of whether to proceed or not, and
> sends either 180-Ringing or 580-Precondition-Failure.  Maybe it
> asked the destination user the same question, but with a
> distinct ringing sequence.  If lack of QoS is accepted, UAS
> sends the 200-OK and call completes with best-effort.
>
> Comments?
>
> Bill Marshall
> wtm@research.att.com




Message: 7
Return-Path: 
Delivered-To: sip@lists.bell-labs.com
From: "Provin Gurung" 
To: 
Date: Mon, 17 Apr 2000 10:57:37 -0400
Message-ID: <004601bfa87d$45844d20$750804c0@provin-pc.research.telcordia.com>
MIME-Version: 1.0
Content-Type: text/plain;     charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: 
Subject: [SIP] Proxy behavior for CANCEL



Hi,
 I have a question regarding the behavior of proxy on receiving a CANCEL.
Consider, a forking Proxy received an INVITE and it forked and forwarded the
INVITE to multiple servers downstream, Now along comes a CANCEL from an
upstream client.  The proxy is supposed to fork and send the CANCEL to the
branches which have not yet responded.

How should the proxy react,
(a) if it already received a 2xx response from one of the downstream
branches, (This would be if the final response from the proxy to the
upstream client and the CANCEL crossed over each other.)
- I guess it should be 481 (Transaction not found)

(b) The proxy has not received  2xx nor 6xx from any branches.
Should the proxy send back a 2xx for the CANCEL  immediately and not care
how the downstream servers respond to the CANCEL that is forked by this
proxy, or should it wait till the unfinished branches respond to the forked
CANCEL and then depending on this result send back a CANCEL, i.e. the proxy
send back a 200 CANCEL upstream if the proxy receives a 2xx for all the
forked CANCEL from all it's branches, or maybe proxy the 2xx for INVITE, if
one of the branches respond with 200 for INVITE  ( cross over for the forked
INVITE and forked CANCEL in one of the proxy) and resonpond say 481 for the
CANCEL.

If the proxy responds immediately with 2xx for CANCEL, it is possible that
the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE
(Taking into consideration , that if a Proxy receives a 2xx for INVITE from
one of the branches, after it has sent a 2xx for CANCEL upstream, it still
forwards the 2xx for the CANCEL to the upstream client). How does the UA
handle this case.


Sorry for not keeping it short, I tried to look up the rfc but could not
find it discussing the above scenario.

Thanks in advance,
Provin

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Roy, Radhika R, ALARC
> Sent: Monday, April 17, 2000 9:15 AM
> To: Rohan Mahy
> Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> Hi, Rohan:
>
> Pl. see my comments below .
>
> Thanks,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Friday, April 14, 2000 11:38 PM
> To: Roy, Radhika R, ALARC
> Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
> >Hi, Everyone:
> >
> >My comments are as follows:
> >
> >1. We are extending SIP to support mobility in the application layer. So,
> >SIP WG is the right place. The SIP WG is the only group that
> knows what to
> >do the SIP protocol in the application layer.
>
> Hi,
>
> Who is the "we" here?  To be specific, has this been formally
> included as a
> topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff
> would be considered as part of the scope of "mobility".
>
>  "We" means the members who are interested for extension of SIP to
> support mobility as some discussion was held based on the
> internet draft in
> the last IETF meeting. Yes, "soft-handoff" may not be a part of
> SIP mobility
> if it does not affect the application (i.e., SIP) layer resources.
>
> thanks,
> -rohan
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>







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


--0__=VF011pRZ0AQ9QPGDwHHk9g9zckhh5p52pFBHxWbT9pusP9bLJGESJKIa--



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


From sip-admin@lists.bell-labs.com  Tue Apr 18 05:06: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 FAA29493
	for ; Tue, 18 Apr 2000 05:06: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 167224433A; Tue, 18 Apr 2000 05:03:22 -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 489CF44339
	for ; Tue, 18 Apr 2000 05:03:19 -0400 (EDT)
Received: by SPEED01 with Internet Mail Service (5.5.2650.21)
	id <2XP53MSG>; Tue, 18 Apr 2000 11:03:22 +0200
Message-ID: <2160ABC55998D311821900508B2C14BB269CE0@SPEED01>
From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= 
To: "'jose'" , sip@lists.bell-labs.com
Subject: SV: [SIP] SIP and soft hand-off
Date: Tue, 18 Apr 2000 11:03:21 +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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA29493

Hi,
My assumption is that a user "belongs" to a registrar server, the "home"
registrar server", that is operated by a service provider that is providing
the users SIP address. The SIP address points out the registrar server
through DNS for incoming INVITE messages. The problem is now how to forward
these messages to the users current location. This is done to by using the
information from for example a REGISTER message from the user. 

DHCP could be used to find registrar servers within the domain where the
user's phone currently is present. A useful scenario for this is when an ISP
is also acting as SIP service provider and wants to deploy phones to be used
on their access. Then could these phones get automatically configured via
the DHCP options and thereby get the address of their registrar server.

In the case when you have a UA implementing the REGISTER method but doesn't
know the nearest proxy you could assume that you know the address of your
home registrar server, analogous how you know about your mail server. This
information could be sent to you when you got the subscription, or
information on a SIM card etc. The register messages could be sent directly
to this network assumed that there is no firewalls in between. 

In the case of firewalls you first might have to contact a SIP server in the
domain where you currently are for authorization to let you through the
firewall. This server would then act as a proxy and forward your
registration message to your home registrar server. The proxy server in the
visited domain might be found with SLP or DHCP if you got the IP address
from this domain.

The case with a simple UA not implementing REGISTER could be solved if SIP
and mobile IP are provided by the same service provider. I am not a mobile
IP expert, so correct me if I am wrong...
The solution relies on either static mobile addresses per user or that there
is a server providing a dynamic mobile address that is fixed through the
whole mobile session, even when the user is moving around between networks.
In the first case could this static address be hard wired into the users
home registrar server the time the account is set up. In the second case
could the entity providing mobile addresses update the registrar server with
the current mobile address that an user is available on.

//Jörgen



-----Ursprungligt meddelande-----
Från: jose [mailto:jose@tct.hut.fi]
Skickat: den 17 april 2000 19:42
Till: dean.willis@wcom.com; sip@lists.bell-labs.com; mat@cisco.com
Ämne: Re:[SIP] SIP and soft hand-off


Hi all,


Dear colleagues, I am following the SIP development and now regarding the 
mobility problem I would like to point out some situations in a SIP 
environment.

In all the cases treated till now all the SIP UA have the REGISTER 
capability and they can find using one or other way (DHCP, SLP) the closest 
registrar server to make the registration.

The problem here arise when we are dealing with a plain UA with the simplest

capabilities (not including REGISTER). In this case how could notify the UA 
its location to other entities. How can be that UA available to others UA or

proxies if it has not been registered anywhere?
This is the specific case when an IP device obtain its mobile address starts

using it for other needs. Initially, it has assigned a mobile IP address for

other matters and afterwards it launch the SIP UA in case someone wants to 
call him, but that UA has not been registered anywhere.

In the case that we have a complete implementation of the UA including the 
registration feature but the nearest SIP proxy does not have that 
capability, we find the same problem again.

In resume, I am wondering if there is any mean to locate an IP device 
independently if is for IP telephony, mail service, or whatever?

Any suggestion about any solution or clue about any working group related to

these problems would be welcome.

Thanks
Best Regards
Jose


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/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 Apr 18 07:48: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 HAA01353
	for ; Tue, 18 Apr 2000 07:48: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 78F7944337; Tue, 18 Apr 2000 07:45:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id CF65444336
	for ; Tue, 18 Apr 2000 07:45:11 -0400 (EDT)
Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id  for ;
 Tue, 18 Apr 2000 12:46:17 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-24) id MAA05907; Tue, 18 Apr 2000 12:47:14 +0100 (BST)
From: Surinder.Ubhi@marconicomms.com
Received: by marconicomms.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 802568C5.0040B74C ; Tue, 18 Apr 2000 12:46:52 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
To: sip@lists.bell-labs.com
Message-ID: <802568C5.0040B60D.00@marconicomms.com>
Date: Tue, 18 Apr 2000 12:46:47 +0100
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Re: SIP digest, Vol 1 #21 - 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:  
X-BeenThere: sip@lists.bell-labs.com



I accidentally caused this reply, my apologies.




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


From sip-admin@lists.bell-labs.com  Tue Apr 18 08:02: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 IAA01733
	for ; Tue, 18 Apr 2000 08:02: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 69D6844339; Tue, 18 Apr 2000 07:59:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 393E144337
	for ; Tue, 18 Apr 2000 07:59:01 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id IAA21315;
	Tue, 18 Apr 2000 08:02:20 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id IAA29864; Tue, 18 Apr 2000 08:03:37 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 18 Apr 2000 08:02:18 -0400
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Rohan Mahy 
Cc: Basavaraj.Patil@nokia.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off
Date: Tue, 18 Apr 2000 08:02:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Hi, Rohan:

Pl. see my comments below .

Thanks,
Radhika R. Roy
AT&T

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, April 14, 2000 11:38 PM
To: Roy, Radhika R, ALARC
Cc: Basavaraj.Patil@nokia.com; sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and soft hand-off


At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a 
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff 
would be considered as part of the scope of "mobility".

 "We" means the members who are interested for extension of SIP to
support mobility as some discussion was held based on the internet draft in
the last IETF meeting. Yes, "soft-handoff" may not be a part of SIP mobility
if it does not affect the application (i.e., SIP) layer.

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  Tue Apr 18 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 KAA05384
	for ; Tue, 18 Apr 2000 10:40: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 56DD144337; Tue, 18 Apr 2000 10:36:49 -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 9996B44336
	for ; Tue, 18 Apr 2000 10:36:46 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FT700HBOVET4P@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 18 Apr 2000 14:40:06 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FT700C01VETCI@dgismtp02.wcomnet.com>;
 Tue, 18 Apr 2000 14:40:05 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FT7008P6VETMD@dgismtp02.wcomnet.com>; Tue,
 18 Apr 2000 14:40:05 +0000 (GMT)
Received: from wcom.com ([166.44.153.154])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000418144004.DDOR11405@wcom.com>; Tue,
 18 Apr 2000 14:40:04 +0000
Date: Mon, 17 Apr 2000 09:43:24 -0500
From: Alan Johnston 
Subject: Re: [SIP] SIP Call Flows and 487 Request Cancelled
To: "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.bell-labs.com'" 
Message-id: <38FB230A.6A5740F4@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Robert,

Thanks for the feedback - you are correct.  The 487 Request Cancelled response
to the INVITE should be added to scenarios 3.2.1, 4.2.1, 5.2.6, 7.7, and 7.10.

Thanks,
Alan Johnston
MCI WorldCom

Fairlie-Cuninghame, Robert wrote:

> I noticed that response 487 Request Cancelled is missing from the CANCEL
> examples of the SIP Call Flows draft. I'm not sure whether this because the
> call flows does not incorporate RFC2543bis or whether this is a genuine
> omission.
>
> Cheers,
>
> Robert.
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 18 11:24:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06205
	for ; Tue, 18 Apr 2000 11:24: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 ABCEF44337; Tue, 18 Apr 2000 11:20:40 -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 4E0D944336
	for ; Tue, 18 Apr 2000 11:20:38 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FT700M5QXFLZG@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 18 Apr 2000 15:23:46 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FT700L01XF39Y@pmismtp03.wcomnet.com>;
 Tue, 18 Apr 2000 15:23:27 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FT700K1NXF2WO@pmismtp03.wcomnet.com>; Tue,
 18 Apr 2000 15:23:26 +0000 (GMT)
Received: from dwillispc8 ([166.35.150.75])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000418152342.DWYV13901@[166.35.150.75]>; Tue,
 18 Apr 2000 15:23:42 +0000
Date: Tue, 18 Apr 2000 10:23:04 -0500
From: Dean Willis 
Subject: RE: [SIP] SIP call control services
In-reply-to: 
To: Postmann Erwin , sip@lists.bell-labs.com
Message-id: <009801bfa949$fd90df60$4b9623a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


There are several new drafts indexed at

http://www.softarmor.com/sipwg/teams/callcontrol/index.html/

including:

draft-campbell-sip-cc-framework-00.txt (Campbell) published 3/9/00
draft-sparks-sip-cc-transfer-00.txt (Sparks) published 3/9/00
draft-rosenberg-sip-3pcc-00.txt (Rosenberg) published 3/13/00
draft-mark-sip-dmcs-00.txt (Mark) published 3/15/00, see also IPR statement
at http://www.ietf.org/ietf/IPR/DIALOGIC-SIP-DMCS

--
dean


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Postmann Erwin
> Sent: Tuesday, April 18, 2000 1:32 AM
> To: 'sip@lists.bell-labs.com'
> Subject: [SIP] SIP call control services
>
>
> Dear all,
>
> I am new on the list and have a question regarding the status of the
> following internet draft "SIP call control services"
> (draft-ietf-mmusic-sip-cc-01.txt), which is  expired December 1999.
>
> Is there a new version of the draft (or maybe other drafts covering the
> ideas) planed or even already available?
>
>
> Best regards
>
>
> Erwin Postmann
> SIEMENS AG Austria
> Program and System Engineering
> Mobile Networks Solutions - Product Marketing
>
> Autokaderstrasse 29
> A-1210 Vienna
>
> Tel:	+43.5.1707.21398
> Fax:	+43.5.1707.51924
> GSM:	+43.664.1010034
> email:	erwin.postmann@siemens.at
>
>
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 18 13:12: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 NAA08387
	for ; Tue, 18 Apr 2000 13:12: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 B776244336; Tue, 18 Apr 2000 13:09:02 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 9F99544336
	for ; Tue, 18 Apr 2000 07:06:42 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 18 07:08:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 0834E44344; Tue, 18 Apr 2000 06:55:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id BE9B044341
	for ; Tue, 18 Apr 2000 06:55:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 8030852BB; Tue, 18 Apr 2000 06:55:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A1D4552AB
	for ; Tue, 18 Apr 2000 06:55:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Apr 18 06:54:41 EDT 2000
Received: from ietf.org ([132.151.1.176]) by dusty; Tue Apr 18 06:54:40 EDT 2000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00243;
	Tue, 18 Apr 2000 06:54:39 -0400 (EDT)
Message-Id: <200004181054.GAA00243@ietf.org>
To: IETF-Announce: ;
Cc: sip@lists.research.bell-labs.com
From: The IESG 
Reply-To: iesg@ietf.org
Date: Tue, 18 Apr 2000 06:54:38 -0400
Subject: [SIP] Last Call: The SIP Supported Header to Proposed Standard
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


The IESG has received a request from the Session Initiation Protocol
(sip) Working Group to consider The SIP Supported Header
 as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by May 1, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-02.txt



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


From sip-admin@lists.bell-labs.com  Tue Apr 18 14:49: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 OAA09926
	for ; Tue, 18 Apr 2000 14:49: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 46CC944337; Tue, 18 Apr 2000 14:45:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 717EA44336
	for ; Tue, 18 Apr 2000 14:45:50 -0400 (EDT)
Received: from pc64 (pc64.tct.hut.fi [130.233.154.64])
	by keskus.tct.hut.fi (8.10.0/8.10.0) with SMTP id e3IInPM08288;
	Tue, 18 Apr 2000 21:49:25 +0300 (EET DST)
Date: Tue, 18 Apr 2000 21:49:25 +0300 (EET DST)
From: jose 
Message-Id: <20000418215154jose@tct.hut.fi@pc64>
Content-Type: text/plain
To: Jorgen.Bjorkner@hotsip.com
Subject: Re: [SIP] SIP and soft hand-off
Cc: sip@lists.bell-labs.com
X-Mailer: Pronto E-Mail [ver 4.0.2.6]
Mime-Version: 1.0
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09926

Hi Jorgen,

Thanks for your description for each case.
See my comments below.

 

> The case with a simple UA not implementing REGISTER could be solved if
>  SIP
> and mobile IP are provided by the same service provider. 

That is the particular case that I wanted point out, when ISP does not 
provide any SIP server and the UA don't have any way to advice its old proxy 
server that it has changed the location.

Thus, is there any other Location mechanism to locate this UA?

In the new location the UA has been assigned an IP address in a domain where 
there isn't any SIP proxy available and the UA does not have implemented the 
REGISTRAR feature.

Is it possible that ISP once has assigned the mobile IP address has any mean 
to locate the user device and its capabilities (UA or H.323 end device) and 
let others ISP know that this UA is on its domain?

Then, when any remote UA wants to set up the call to that UA it can address 
the signaling directly to the address assigned by the Local ISP to that UA.

>I am not a
>  mobile
> IP expert, so correct me if I am wrong...
> The solution relies on either static mobile addresses per user or that
>  there
> is a server providing a dynamic mobile address that is fixed through the
> whole mobile session, even when the user is moving around between
>  networks.
> In the first case could this static address be hard wired into the users
> home registrar server the time the account is set up. In the second case
> could the entity providing mobile addresses update the registrar server
>  with
> the current mobile address that an user is available on.
> 
> //Jörgen

Here we could have almost the same situation. If ISP providing mobile IP has 
not implemented SIP service, how can notify the UA local registrar that the 
UA is now on its domain?

Maybe I am too much exigent in deploying this scenarios but I just was 
wondering if exist any "Swiss Army Knife" mechanism to locate each user 
despite its situation and  Signaling protocol is using for setting up a 
phone call. Just locating the user location, IP address assigned and end 
device capabilities and then let know to other ISPs that it has that 
information available. Thus, that device would be globally available.

Thanks Jörgen for your help and let me know if you have any clue for this 
situation or there are any other working group that are working on that kind 
of issue.

Thanks a lot.

Best Regards
Jose


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


From sip-admin@lists.bell-labs.com  Tue Apr 18 17:11: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 RAA12292
	for ; Tue, 18 Apr 2000 17:11: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 C2D4844337; Tue, 18 Apr 2000 17:07:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2])
	by lists.bell-labs.com (Postfix) with ESMTP id D4D3944336
	for ; Tue, 18 Apr 2000 17:07:52 -0400 (EDT)
Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id OAA29311; Tue, 18 Apr 2000 14:10:23 -0700 (PDT)
From: "David Oran" 
To: "Roy, Radhika R, ALARC" , 
Cc: 
Subject: RE: [SIP] SIP and soft hand-off
Date: Tue, 18 Apr 2000 17:10:22 -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)
In-Reply-To: 
Importance: Normal
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

In the small hope this will shed light rather than heat...

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Roy, Radhika R, ALARC
> Sent: Friday, April 14, 2000 8:40 PM
> To: Basavaraj.Patil@nokia.com
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
> Hi, Everyone:
>
> My comments are as follows:
>
> 1. We are extending SIP to support mobility in the application layer. So,
> SIP WG is the right place. The SIP WG is the only group that knows what to
> do the SIP protocol in the application layer.
>
I think there's a terminology problem here. When layer 2 people talk about
mobility it means something different than when layer 3 people talk about
mobility, and still something different when layer 7 people talk about
mobility. What is common however, is the need to keep an application happy
in the face of changes in the underlying network connectivity.

- For layer 2 folks, this means keeping the mobility transparent to layer 3
and above in order to provide what looks like a homogenous topology to the
algorithms and protocols which run IP and other global protocols in layers
3, 4 and above. This of course works well in a single administrative domain,
scales only so far, and depends on pretty tight timing and a fair amount of
state.

- For layer 3 folks, this means keeping the logical connectivity seen by the
transport and above constant in order to keep the transport protocols
(especially TCP) happy. By extension this is needed to keep applications
which view transport failure as fatal or semi-fatal from thinking the world
has fallen apart when an IP address changes.

- For layer 7 folks, it just means that the application protocol can deal
with changes in connectivity, network address, and even in some cases,
complete disconnection from the network for extended periods of time (poster
child for this is disconnected file systems like Andrew and DFS, and offline
WEB caching by browsers).

What is (sadly) common among these is only:
1. each assumes that the layers above absolutely positively need
transparency or the world comes crashing down around their ears.
2. each assumes that the layers below can only deal with a subset of the
likely mobility scenarios, and hence are absolutely, positively sure that
they can't depend on the lower layer for performance, robustness, or
scalability reasons.

In the case of SIP, I believe the motivation for doing something to support
mobility directly is driven by:
a) not wanting to depend on Mobile IP in all devices and network
infrastructures. Beyond this, I suspect the dog-leg routing and tunneling
needed by at least the MobileIPv4 approach is viewed as having significant
performance problems for the kind of real time traffic sessions set up by
SIP
b) wanting to have "global" mobility - completely independent of current
network connectivity, administrative boundaries, etc.
c) wanting to potentially deal with mobility at a semantic level above that
of the IP host (e.g. moving a media stream from one device to another).

I don't want to make a value judgement on the validity or relative
importance of these motivations, except to make the observation that the
end-to-end argument has shown again and again its power and general
superiority. It's been true for error control, flow/congestion control,
security, and many of the "ubiquitous" features of computer networks. For me
that says that applications wanting to support mobility in a flexible and
general way will want to have their own mechanisms, but to exploit lower
layer mechanisms AS OPTIMIZATIONS when they are available.

> Let me provide another analogy. We are extending SIP to support QOS. That
> does not mean that extension of SIP has to be done in the QOS WGs
> (DiffServ,
> MPLS, etc).
>
This is NOT precisely true. We specifically did *NOT* extend SIP to support
QoS. That would have been a bad thing to do. What we did instead is allowed
SIP to convey information used to control the lower layer QoS mechanisms,
and to synchronize session establishment with results of QoS signaling
operations.
Perhaps we can use this as guidance for at least the kind of mobility
mentioned in (b) above.

> Only SIP WG can ensure whether the extension of SIP to support mobility
> remains within the framework SIP architecture because they are
> the expert in
> this application layer protocol (not mobile IP or other WGs).
>
This depends on just what one views as the scope of "mobility" as seen by
SIP. God help us if we try to use SIP as a general hammer to pound on the
mobility nail. I can easily see how folks not close to SIP or its domain of
applicability could draw scary conclusions.

> 2. For other points, the technical justifications and contributions will
> proof the fact. No personal opinion will help unless it is justified from
> technical point of view. (Personally, I would be happy to do as much less
> work as we could do to support mobility in SIP.)
>
> Hope this will clarify further.
>
Ditto for my feeble attempts...
Dave Oran.

> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
> Sent: Friday, April 14, 2000 4:11 PM
> To: Roy, Radhika R, ALARC
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] SIP and soft hand-off
>
>
>
>
> Comments below:
>
> Radhika wrote:
> >Chris:
>
> >Now there are internet-drafts related to SIP mobility as well.
> >
> The SIP WG charter does not currently include mobility solutions in
> it's scope. However mobility support will be a key aspect of evolving
> networks and there is a specific WG in the IETF which deals with it -
> Mobile IP.
>
> >Let me clarify: If the network point of attachment is NOT
> changed, there is
> >almost (some non-real-time mobility management may be needed) no
> need to do
> >anything in the application layer (e.g., SIP, H.323). But it is only a
> >special situation.
> >
> >In many situations, it may not be possible. We are addressing those from
> >mobility management point of view. There can be two aspects of this:
> > 1.Should we consider hand-off in the appln layer?
> No.
>
> >2. Should we consider NO handoff in the appln layer?
> The Mobile IP WG is currently debating multiple I-Ds that propose
> handoffs at the network layer. If at all handoffs are to be moved to
> upper layers (from link/physical layers) then it may be optimal to do
> it at the network layer.
>
> -Basavaraj
>
> >
> >I hope that we could agree that the mobility solution would be
> transparent
> >to the application layer (we could save our time)!
> >
> >Best regards,
> >Radhika
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 19 14:01: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 OAA10974
	for ; Wed, 19 Apr 2000 14:01:15 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 06EC144337; Wed, 19 Apr 2000 13:57:42 -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 8997E44336
	for ; Wed, 19 Apr 2000 13:57:39 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FT900D4XZDWOF@firewall.mcit.com> for sip@lists.bell-labs.com;
 Wed, 19 Apr 2000 18:01:08 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FT900K01ZDC0P@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Wed, 19 Apr 2000 18:00:49 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FT900J2LZD4GI@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Wed, 19 Apr 2000 18:00:48 +0000 (GMT)
Received: from dwillispc8 ([166.35.227.170])
 by omzmta03.mcit.com (InterMail v03.02.07 118-124-101)
 with SMTP id <20000419175102.HDGQ9113@dwillispc8> for
 ; Wed, 19 Apr 2000 17:51:02 +0000
Date: Wed, 19 Apr 2000 12:50:25 -0500
From: Dean Willis 
In-reply-to: 
 <35A7D40B978CD311AF05002048404D34E89C5B@wm2.btrd.bostontechnology.com>
To: IETF SIP 
Message-id: <005f01bfaa27$bddeb980$aae323a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Subject: [SIP] RE: SIP call control services (referenced drafts link errors)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


I've heard about a problem with the SIP WG home page:
> -----Original Message-----
> http://www.softarmor.com/sipwg/teams/callcontrol/index.html/
> Yields:
> --------------------------
> Not Found
>
> The requested URL
> /sipwg/teams/drafts/draft-rosenberg-sip-guidelines-00.txt
> was not found on this server.
> --------------------------
>
> On every link

several times. For some reason, the IE5 browser appears to be ignoring the
../../ on the links. Sometimes. I've managed to reproduce it a couple of
times but not consistently. I have not been able to repro with Netscape. I
don't understand. If anybody figures it out, let me know.

I have observed that if I navigate in a stepwise fashion -- that is, go to
http://www.softarmor.com/sipwg/ them go to teams, then go to call control, I
can read the drafts without difficulty.

I'll dig into it as time permits. In the interim, if you are having
difficulty with the links, try either a stepwise navigation as above (which
works for me), back up to the "teams" level and work back down, or just use
the draft name given as an index into either the "drafts" directory or into
the IETF web site for drafts.

--
Dean



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


From sip-admin@lists.bell-labs.com  Wed Apr 19 14:20:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11250
	for ; Wed, 19 Apr 2000 14:20: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 845E94433B; Wed, 19 Apr 2000 14:16:37 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83])
	by lists.bell-labs.com (Postfix) with ESMTP id BED9744336
	for ; Wed, 19 Apr 2000 14:16:34 -0400 (EDT)
Received: from localhost (mwisdom@localhost) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id LAA02899 for ; Wed, 19 Apr 2000 11:20:04 -0700 (PDT)
Date: Wed, 19 Apr 2000 11:20:03 -0700 (PDT)
From: Mark Wisdom 
To: sip@lists.bell-labs.com
Subject: Re: [SIP] OPTIONS behaviour with forking proxy
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:  
X-BeenThere: sip@lists.bell-labs.com

No one has responded to this so far. Surely I can't be the only one
who wants to make use of the OPTIONS method. Any opinions or
authoritative answers out there on this?


---------- Forwarded message ----------
Date: Fri, 14 Apr 2000 17:43:26 -0700 (PDT)
From: Mark Wisdom 
To: sip@lists.bell-labs.com
Subject: [SIP] OPTIONS behaviour with forking proxy

What should a registration server acting as a forking proxy do when it
receives a SIP OPTIONS message which resolves to 2 or more contacts?

Should it:

A. Respond with "300 Multiple Choices".
B. Fork the request off to the multiple choices and then relay the
   first received response back to the original requester?
C. Something else.

I suspect A, but I can't seem to find enough information in
RFC2543 to be certain.

Thanks,
Mark



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


From sip-admin@lists.bell-labs.com  Wed Apr 19 14:32: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 OAA11501
	for ; Wed, 19 Apr 2000 14:32: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 A45AA4433E; Wed, 19 Apr 2000 14:29:19 -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 1B94F4433A
	for ; Wed, 19 Apr 2000 14:29:17 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FTA006DL0UMZ2@firewall.mcit.com> for sip@lists.bell-labs.com;
 Wed, 19 Apr 2000 18:32:46 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FTA009010ULUE@pmismtp01.wcomnet.com> for
 sip@lists.bell-labs.com; Wed, 19 Apr 2000 18:32:46 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FTA0077F0UFGP@pmismtp01.wcomnet.com> for
 sip@lists.bell-labs.com; Wed, 19 Apr 2000 18:32:45 +0000 (GMT)
Received: from dwillispc8 ([166.35.227.170])
 by omzmta03.mcit.com (InterMail v03.02.07 118-124-101)
 with SMTP id <20000419182227.HONM9113@dwillispc8> for
 ; Wed, 19 Apr 2000 18:22:27 +0000
Date: Wed, 19 Apr 2000 13:21:50 -0500
From: Dean Willis 
Subject: RE: [SIP] RE: SIP call control services (referenced drafts link errors)
In-reply-to: <005f01bfaa27$bddeb980$aae323a6@mcit.com>
To: IETF SIP 
Message-id: <006001bfaa2c$217a2840$aae323a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


I figured it out.

The problem is the trailing / I inadvertently left on the published link. It
appears to glitch out the version of Apache used by the ISP hosting the
page.

try:

http://www.softarmor.com/sipwg/teams/callcontrol/index.html

instead.

Some days, I realize how much I've already foggotten and wonder if there's
anything left at all.

--
Dean


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis
> Sent: Wednesday, April 19, 2000 12:50 PM
> To: IETF SIP
> Subject: [SIP] RE: SIP call control services (referenced drafts link
> errors)
>
>
>
> I've heard about a problem with the SIP WG home page:
> > -----Original Message-----
> > http://www.softarmor.com/sipwg/teams/callcontrol/index.html/
> > Yields:
> > --------------------------
> > Not Found
> >
> > The requested URL
> > /sipwg/teams/drafts/draft-rosenberg-sip-guidelines-00.txt
> > was not found on this server.
> > --------------------------
> >
> > On every link
>
> several times. For some reason, the IE5 browser appears to be ignoring the
> ../../ on the links. Sometimes. I've managed to reproduce it a couple of
> times but not consistently. I have not been able to repro with Netscape. I
> don't understand. If anybody figures it out, let me know.
>
> I have observed that if I navigate in a stepwise fashion -- that is, go to
> http://www.softarmor.com/sipwg/ them go to teams, then go to call
> control, I
> can read the drafts without difficulty.
>
> I'll dig into it as time permits. In the interim, if you are having
> difficulty with the links, try either a stepwise navigation as
> above (which
> works for me), back up to the "teams" level and work back down,
> or just use
> the draft name given as an index into either the "drafts"
> directory or into
> the IETF web site for drafts.
>
> --
> Dean
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>



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


From sip-admin@lists.bell-labs.com  Wed Apr 19 14:48: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 OAA11695
	for ; Wed, 19 Apr 2000 14:48: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 ADC404433A; Wed, 19 Apr 2000 14:44:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from server.sipbakeoff.com (unknown [149.112.2.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 159E244336
	for ; Wed, 19 Apr 2000 14:44:56 -0400 (EDT)
Received: from cs.columbia.edu (dhcp185.sipbakeoff.org [149.112.3.185])
	by server.sipbakeoff.com (8.9.3/8.9.3) with ESMTP id MAA09952;
	Wed, 19 Apr 2000 12:49:35 GMT
Message-ID: <38FE0135.131B0802@cs.columbia.edu>
Date: Wed, 19 Apr 2000 14:55:49 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@isi.edu, sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

During the SIP bake-off, two SDP-related issues were raised:

Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
at least one character. It doesn't seem necessary to enforce that s=
have anything in them (like a space). Other textual Internet protocols
seem to be fine with having empty unformatted fields (like Subject: in
email).

Secondly, the rtpmap description does not specify whether the 'encoding
name' is case-sensitive or not. Since it's also used as a media type and
media types are case-insensitive (RFC 2616, 3.7), it probably makes
sense to make them CI in SDP as well.

Comments are appreciated.

Henning


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


From sip-admin@lists.bell-labs.com  Wed Apr 19 15:23:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12335
	for ; Wed, 19 Apr 2000 15:23:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6981444339; Wed, 19 Apr 2000 15:19: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 8702044336
	for ; Wed, 19 Apr 2000 15:19:33 -0400 (EDT)
Received: from metro.cs.columbia.edu (metro.cs.columbia.edu [128.59.19.190])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA07696;
	Wed, 19 Apr 2000 15:23:01 -0400 (EDT)
Received: (from lennox@localhost)
	by metro.cs.columbia.edu (8.9.3/8.9.3) id PAA21180;
	Wed, 19 Apr 2000 15:23:00 -0400 (EDT)
Date: Wed, 19 Apr 2000 15:23:00 -0400 (EDT)
Message-Id: <200004191923.PAA21180@metro.cs.columbia.edu>
From: Jonathan Lennox 
To: Mark Wisdom 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] OPTIONS behaviour with forking proxy
In-Reply-To: 
References: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

On Wed, April 19 2000, "Mark Wisdom" wrote to "sip@lists.bell-labs.com" saying:

> What should a registration server acting as a forking proxy do when it
> receives a SIP OPTIONS message which resolves to 2 or more contacts?
> 
> A. Respond with "300 Multiple Choices".
> B. Fork the request off to the multiple choices and then relay the
>    first received response back to the original requester?
> C. Something else.
> 
> I suspect A, but I can't seem to find enough information in
> RFC2543 to be certain.

OPTIONS isn't any different from any other method...you fork the request off
to every registered location, and send back all the 2xx-class responses or
the first failure response you get.

This means that people who send OPTIONS requests need to expect to get
multiple 2xx responses, of course.

-- 
Jonathan Lennox
lennox@cs.columbia.edu


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


From sip-admin@lists.bell-labs.com  Wed Apr 19 18:31: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 SAA15350
	for ; Wed, 19 Apr 2000 18:31: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 F23C344337; Wed, 19 Apr 2000 18:27:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from server.sipbakeoff.com (unknown [149.112.2.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 6C85244336
	for ; Wed, 19 Apr 2000 18:27:50 -0400 (EDT)
Received: from cs.columbia.edu (dhcp185.sipbakeoff.org [149.112.3.185])
	by server.sipbakeoff.com (8.9.3/8.9.3) with ESMTP id QAA10131
	for ; Wed, 19 Apr 2000 16:32:33 GMT
Message-ID: <38FE3578.F0DD9C76@cs.columbia.edu>
Date: Wed, 19 Apr 2000 18:38:48 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP issues raised at bake-off
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The following issues were discussed at the SIP bake-off. Comments from
the list are appreciated. 'Suggested solution' is the preference
expressed by the bake-off attendees.

1) SDP case-sensitivity for encodings (see previous message)

Suggested solution: case-insensitive (possibly with upper-case as the
canonical version)

2) tag: currently is hex, should token be allowed?

Suggested solution: yes, token should be allowed.

3) REGISTER authentication

Some suggested that proxy-authorization should be used instead of
Authorization for REGISTER. Text needs to be clarified but consensus was
that Authorization is to be used (if a proxy, real or co-located also
wants the client to authenticate, it is free to return a 407 and the
client should use the same mechanism to return Proxy-Authorization).

4) Digest quoting of URIs

RFC 2617 is inconsistent. The BNF specifies that URIs are appended as
arguments, while the example in RFC 2617, Section 3.5 encloses them in
quotation marks. The latter is considered correct since the URI may
contain non-token characters.

5) From/To header

Some implementations do not put a space between the display name and the
'<'. This is legal, if unusual.

6) Expires header

If a new registration has a shorter expiration date, it updates the old
one.

7) Multicast INVITE/REGISTER

It was suggested to include a maddr in the Via header containing the
multicast address. This makes it easier for the server to tell that the
request was received via multicast (since sockets may receive both
unicast and multicast packets).

8) Overlapping transactions

A number of people expressed unhappiness about not allowing overlapping
transactions as it greatly complicates the client state machine for
things like hold/mute. This may need to be discussed again. Maybe
limiting this restriction to media list changes would address most of
the concerns.

9) Status code for non-matching media (in SDP)

Currently, we have 606 for "Not Acceptable", but this terminates
searches. Thus, it was suggested that we may want to add a 488 code for
incompatibility at an individual terminal (which allows the proxy to
search elsewhere for matching media).

10) Record-Route

It was suggested that UAS should reflect all Record-Route headers into
Route headers, as that might simplify implementation of future features.
This is already implied by the current wording in 6.33.2.


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


From sip-admin@lists.bell-labs.com  Thu Apr 20 02:35: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 CAA03395
	for ; Thu, 20 Apr 2000 02:35: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 569134433A; Thu, 20 Apr 2000 02:32:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 7C39644336
	for ; Thu, 20 Apr 2000 02:32:11 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprich.nortel.com; Thu, 20 Apr 2000 01:36:34 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id ; Thu, 20 Apr 2000 01:35:28 -0500
Message-ID: <2E532B03F035D3119AF40000F80932C32073B9@crchy28d.us.nortel.com>
From: "William Lee" 
To: "'Henning Schulzrinne'" 
Cc: "'SIP@lists.bell-labs.com'" 
Subject: RE: [SIP] SDP issues
Date: Thu, 20 Apr 2000 01:35:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAA92.9DA6C444"
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:  
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_01BFAA92.9DA6C444
Content-Type: text/plain

Henning:

In reply to the first SDP issue (s=nothing):

*	According to RFC 2327 s= is a required SDP parameter. Is it the
intention of the spec writers
      to allow nothing to be sent?
*	If so, then should s= even be a required SDP parameter?
*	If s=nothing is permitted, then the fact that s= was present in the
SDP message must be recorded
      in order to adhere to the requirement that s= was indeed in the SDP
message.
*	If an SDP parser is strictly compliant, it will complain about the
s=nothing scenario.
*	SDP parameters are required to appear in a specific order. This
possibly presents
      issues, if a SDP parser strictly validates, depending on how it deals
with the above issue.
*	Section B7, RFC 2543, says that for two-party sessions, the SDP s=
parameter may be left empty. 
      Isn't this in conflict with RFC 2327? However, in the case of
multicast sessions it has to be s=something. 
*	Having the s= parameter follow a varying rule set seems to add an
unnecessary complication for
      SDP message validation.

Comments appreciated. Thanks.

Bill Lee

 

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:hgs@cs.columbia.edu]
> Sent:	Wednesday, April 19, 2000 1:56 PM
> To:	confctrl@isi.edu; sip@lists.bell-labs.com
> Subject:	[SIP] SDP issues
> 
> During the SIP bake-off, two SDP-related issues were raised:
> 
> Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> at least one character. It doesn't seem necessary to enforce that s=
> have anything in them (like a space). Other textual Internet protocols
> seem to be fine with having empty unformatted fields (like Subject: in
> email).
> 
> Secondly, the rtpmap description does not specify whether the 'encoding
> name' is case-sensitive or not. Since it's also used as a media type and
> media types are case-insensitive (RFC 2616, 3.7), it probably makes
> sense to make them CI in SDP as well.
> 
> Comments are appreciated.
> 
> Henning
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFAA92.9DA6C444
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SDP issues




Henning:




In reply to the =
first SDP issue (s=3Dnothing):




  • According to =
RFC 2327 s=3D is a required SDP parameter. Is it the intention of the =
spec writers
    • 



      to allow nothing to be =
sent?


  • If so, then =
should s=3D even be a required SDP parameter?
    • 

  • If s=3Dnothing is =
permitted, then the fact that s=3D was present in the SDP message must =
be recorded
    • 



      in order to adhere to the =
requirement that s=3D was indeed in the SDP message.


  • If an SDP =
parser is strictly compliant, it will complain about the s=3Dnothing =
scenario.
    • 

  • SDP parameters are =
required to appear in a specific order. This possibly =
presents
    • 



      issues, if a SDP parser =
strictly validates, depending on how it deals with the above =
issue.


  • Section B7, RFC =
2543, says that for two-party sessions, the SDP s=3D parameter may be =
left empty. 
    • 



      Isn't this in conflict =
with RFC 2327? However, in the case of multicast sessions it has to be =
s=3Dsomething. 


  • Having the s=3D =
parameter follow a varying rule set seems to add an unnecessary =
complication for
    • 



      SDP message =
validation.




Comments =
appreciated. Thanks.




Bill Lee




 



    

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

    From:   Henning Schulzrinne =
[SMTP:hgs@cs.columbia.edu]

    Sent:   Wednesday, April 19, 2000 1:56 PM

    To:     confctrl@isi.edu; sip@lists.bell-labs.com

    Subject:       =
 [SIP] SDP issues

    


    During the SIP bake-off, two =
SDP-related issues were raised:

    


    Currently, s=3D is defined as text, =
which is 1*(some set of bytes), i.e.,

    at least one character. It doesn't =
seem necessary to enforce that s=3D

    have anything in them (like a space). =
Other textual Internet protocols

    seem to be fine with having empty =
unformatted fields (like Subject: in

    email).

    


    Secondly, the rtpmap description does =
not specify whether the 'encoding

    name' is case-sensitive or not. Since =
it's also used as a media type and

    media types are case-insensitive (RFC =
2616, 3.7), it probably makes

    sense to make them CI in SDP as =
well.

    


    Comments are appreciated.

    


    Henning

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFAA92.9DA6C444--


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


From sip-admin@lists.bell-labs.com  Thu Apr 20 05:35:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04674
	for ; Thu, 20 Apr 2000 05:35:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 45A1744344; Thu, 20 Apr 2000 05:31:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ren.orange.co.uk (news-gw1.orange.co.uk [193.35.129.99])
	by lists.bell-labs.com (Postfix) with ESMTP id 8717744336
	for ; Thu, 20 Apr 2000 05:31:24 -0400 (EDT)
Received: from ruddick (ruddick.orange.co.uk [172.19.16.129])
	by ren.orange.co.uk (Pro-8.9.3/8.9.3) with SMTP id KAA05589;
	Thu, 20 Apr 2000 10:34:56 +0100 (BST)
Received: by ruddick(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 802568C7.0033FF3A ; Thu, 20 Apr 2000 10:27:56 +0100
X-Lotus-FromDomain: HTLUK
From: Simon.BARBER@orange.co.uk
To: J=?iso-8859-1?Q?=F6rgen?= Bj=?iso-8859-1?Q?=F6rkner?= 
Cc: sip@lists.bell-labs.com
Message-ID: <802568C7.0033FD93.00@ruddick>
Date: Thu, 20 Apr 2000 10:45:41 +0100
Subject: Re: SV: [SIP] SIP and soft hand-off
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc"
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:  
X-BeenThere: sip@lists.bell-labs.com

--0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

One slightly more complex case would be where the user has bought his SIP
address from a vanity name provider, and the vanity name provider forwards all
requests on to his real SIP server, which is the server he registers with.

Simon Barber





J
--0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6rgen Bj=F6rkner  on 18/04/2000 10:03:21




To:   "'jose'" 
      sip@lists.bell-labs.com
cc:    (bcc: Simon BARBER/EN/HTLUK)


Subject:  SV: [SIP] SIP and soft hand-off


=

--0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


Hi,
My assumption is that a user "belongs" to a registrar server, the "home"
registrar server", that is operated by a service provider that is providing
the users SIP address. The SIP address points out the registrar server
through DNS for incoming INVITE messages. The problem is now how to forward
these messages to the users current location. This is done to by using the
information from for example a REGISTER message from the user.

DHCP could be used to find registrar servers within the domain where the
user's phone currently is present. A useful scenario for this is when an ISP
is also acting as SIP service provider and wants to deploy phones to be used
on their access. Then could these phones get automatically configured via
the DHCP options and thereby get the address of their registrar server.

In the case when you have a UA implementing the REGISTER method but doesn't
know the nearest proxy you could assume that you know the address of your
home registrar server, analogous how you know about your mail server. This
information could be sent to you when you got the subscription, or
information on a SIM card etc. The register messages could be sent directly
to this network assumed that there is no firewalls in between.

In the case of firewalls you first might have to contact a SIP server in the
domain where you currently are for authorization to let you through the
firewall. This server would then act as a proxy and forward your
registration message to your home registrar server. The proxy server in the
visited domain might be found with SLP or DHCP if you got the IP address
from this domain.

The case with a simple UA not implementing REGISTER could be solved if SIP
and mobile IP are provided by the same service provider. I am not a mobile
IP expert, so correct me if I am wrong...
The solution relies on either static mobile addresses per user or that there
is a server providing a dynamic mobile address that is fixed through the
whole mobile session, even when the user is moving around between networks.
In the first case could this static address be hard wired into the users
home registrar server the time the account is set up. In the second case
could the entity providing mobile addresses update the registrar server with
the current mobile address that an user is available on.

//J
--0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=F6rgen



-----Ursprungligt meddelande-----
Fr=E5n: jose [mailto:jose@tct.hut.fi]
Skickat: den 17 april 2000 19:42
Till: dean.willis@wcom.com; sip@lists.bell-labs.com; mat@cisco.com
=C4mne: Re:[SIP] SIP and soft hand-off


Hi all,


Dear colleagues, I am following the SIP development and now regarding t=
he
mobility problem I would like to point out some situations in a SIP
environment.

In all the cases treated till now all the SIP UA have the REGISTER
capability and they can find using one or other way (DHCP, SLP) the clo=
sest
registrar server to make the registration.

The problem here arise when we are dealing with a plain UA with the sim=
plest

capabilities (not including REGISTER). In this case how could notify th=
e UA
its location to other entities. How can be that UA available to others =
UA or

proxies if it has not been registered anywhere?
This is the specific case when an IP device obtain its mobile address s=
tarts

using it for other needs. Initially, it has assigned a mobile IP addres=
s for

other matters and afterwards it launch the SIP UA in case someone wants=
 to
call him, but that UA has not been registered anywhere.

In the case that we have a complete implementation of the UA including =
the
registration feature but the nearest SIP proxy does not have that
capability, we find the same problem again.

In resume, I am wondering if there is any mean to locate an IP device
independently if is for IP telephony, mail service, or whatever?

Any suggestion about any solution or clue about any working group relat=
ed to

these problems would be welcome.

Thanks
Best Regards
Jose


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


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


=

--0__=VcmWr1ibRbpyk8GzgOauRbI38MBYAFbK0nqanXz6ApMcKh1gqHoNu2Hc--



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


From sip-admin@lists.bell-labs.com  Thu Apr 20 12:56: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 MAA15865
	for ; Thu, 20 Apr 2000 12:56: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 1108644337; Thu, 20 Apr 2000 12:52: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 6019D44336
	for ; Thu, 20 Apr 2000 12:52:17 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA27830;
	Thu, 20 Apr 2000 12:55:50 -0400 (EDT)
Message-ID: <38FF3696.846FAE5D@cs.columbia.edu>
Date: Thu, 20 Apr 2000 12:55:50 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: William Lee 
Cc: "'SIP@lists.bell-labs.com'" 
Subject: Re: [SIP] SDP issues
References: <2E532B03F035D3119AF40000F80932C32073B9@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> William Lee wrote:
> 
> Henning:
> 
> In reply to the first SDP issue (s=nothing):
> 
>    * According to RFC 2327 s= is a required SDP parameter. Is it the
>      intention of the spec writers
> 
>       to allow nothing to be sent?

Probably best discussed on the confctrl mailing list. However, all other
protocols and standard C/C++ coding convention is that the empty string
("") is always legal as input. Clearly, for positional parameters, this
does not work, but for things like s=, it makes no difference. It is
annoying to have to remember everywhere to code

if (strlen(s) == 0) {
  free(s);
  s = strdup(" ");
}
sprintf(sdp, "s=%s", s);

or similar.

> 
>    * If so, then should s= even be a required SDP parameter?

I would say that it shouldn't (and I suspect that many implementations
don't send it).

>    * If s=nothing is permitted, then the fact that s= was present in
>      the SDP message must be recorded
> 
>       in order to adhere to the requirement that s= was indeed in the
> SDP message.
> 
>    * If an SDP parser is strictly compliant, it will complain about
>      the s=nothing scenario.

I doubt that any existing implementations break on that. If they do,
they are not going to work well in practice...

>    * SDP parameters are required to appear in a specific order. This
>      possibly presents
> 
>       issues, if a SDP parser strictly validates, depending on how it
> deals with the above issue.
> 
>    * Section B7, RFC 2543, says that for two-party sessions, the SDP
>      s= parameter may be left empty.
> 
>       Isn't this in conflict with RFC 2327? However, in the case of
> multicast sessions it has to be s=something.
> 
>    * Having the s= parameter follow a varying rule set seems to add an
>      unnecessary complication for
> 
>       SDP message validation.
> 
> Comments appreciated. Thanks.

Ruling out in a protocol what robust implementations need to do anyway
seems like a futile exercise. The only difference is that difficulties
are detected later, in the field...

I would think that making s= optional and (certainly) allowing the null
string as an argument to s= seems in the spirit of all other Internet
text protocols, beyond the reasons mentioned above.


-- 
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 Apr 20 14:55: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 OAA18646
	for ; Thu, 20 Apr 2000 14:55: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 03B1944336; Thu, 20 Apr 2000 14:51: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 DF63844336
	for ; Thu, 20 Apr 2000 10:35:17 -0400 (EDT)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA03057
	for ; Thu, 20 Apr 2000 09:41:48 -0500
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <2FJK1ZP1>; Thu, 20 Apr 2000 09:36:52 -0500
Message-ID: 
From: "Culpepper, Bert" 
To: sip@lists.bell-labs.com
Date: Thu, 20 Apr 2000 09:36:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] FW: I-D ACTION:draft-culpepper-sip-info-event-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:  
X-BeenThere: sip@lists.bell-labs.com

I'd like to make those individuals interested in PSTN-SIP interworking aware
of a new Draft.  And initiate a discussion on the topic described.

This draft proposes a method by which a SIP application can request Media
Gateway event detection and reporting, via the MG's Media Gateway
Controller.  A primary application is to enable DTMF collection but all MG
event related capabilities are supported.  Both MGCP and Megaco protocols
are described.

Comments, corrections, and criticism are welcome.

Thanks,
Bert

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
Sent: Thursday, April 20, 2000 6:44 AM
Subject: I-D ACTION:draft-culpepper-sip-info-event-00.txt


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


	Title		: SIP INFO Method for Event Reporting
	Author(s)	: V. Bharatia, E. Cave, B. Culpepper
	Filename	: draft-culpepper-sip-info-event-00.txt
	Pages		: 10
	Date		: 19-Apr-00
	
This document describes the use of the SIP INFO Method for
communicating mid-call events in SIP [1] sessions.  Two new MIME
types are described, according to the rules defined in RFC 2046 [2],
for use in the INFO message.  These media types can be used within a
SIP INFO message to request, and report, event detection between SIP
network entities.  Emphasis is placed on DTMF signaling to
communicate user indications when using SIP between a Media Gateway
Controller (MGC) and a SIP application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-culpepper-sip-info-event-00.txt



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


From sip-admin@lists.bell-labs.com  Thu Apr 20 14:56:07 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18664
	for ; Thu, 20 Apr 2000 14:56: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 2DE7244349; Thu, 20 Apr 2000 14:51:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 43D8444344
	for ; Thu, 20 Apr 2000 14:51:39 -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 OAA04114;
	Thu, 20 Apr 2000 14:56:22 -0400 (EDT)
Message-ID: <38FF5222.7FB364DA@dynamicsoft.com>
Date: Thu, 20 Apr 2000 14:53:22 -0400
From: Igor Slepchin 
Organization: dynamicsoft
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] Proxy behavior for CANCEL
References: <004601bfa87d$45844d20$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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Provin Gurung wrote:
> Consider, a forking Proxy received an INVITE and it forked and forwarded the
> INVITE to multiple servers downstream, Now along comes a CANCEL from an
> upstream client.  The proxy is supposed to fork and send the CANCEL to the
> branches which have not yet responded.
> 
> How should the proxy react,
> (a) if it already received a 2xx response from one of the downstream
> branches, (This would be if the final response from the proxy to the
> upstream client and the CANCEL crossed over each other.)
> - I guess it should be 481 (Transaction not found)

It should send back a 200 OK; no error occurred in this case. 481 is
sent when the proxy receives a CANCEL for a transaction it doesn't know
anything about. Note that the CANCEL still needs to be proxied even in
the latter case.

> (b) The proxy has not received  2xx nor 6xx from any branches.
> Should the proxy send back a 2xx for the CANCEL  immediately and not care
> how the downstream servers respond to the CANCEL that is forked by this
> proxy, 

Yes. CANCEL requests are hop-by-hop.

> If the proxy responds immediately with 2xx for CANCEL, it is possible that
> the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE

Absolutely. The spec actually says that the UACs must be prepared to
handle this.

> 
> Sorry for not keeping it short, I tried to look up the rfc but could not
> find it discussing the above scenario.

See sections 4.2.5, 12.4 in 2543bis.

---
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 Apr 22 20:49:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20930
	for ; Sat, 22 Apr 2000 20: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 E825F44337; Sat, 22 Apr 2000 20:44:56 -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 93D6D44336
	for ; Sat, 22 Apr 2000 20:44:54 -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 UAA29776;
	Sat, 22 Apr 2000 20:48:40 -0400 (EDT)
Message-ID: <390248D1.1659235E@cs.columbia.edu>
Date: Sat, 22 Apr 2000 20:50:25 -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: Jeff Ayars 
Cc: Henning Schulzrinne , confctrl@ISI.EDU,
        sip@lists.bell-labs.com
References: <4.2.0.58.20000422173715.00b4a770@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jeff Ayars wrote:
> 
> At 02:55 PM 4/19/00 -0400, Henning Schulzrinne wrote:
> >During the SIP bake-off, two SDP-related issues were raised:
> >
> >Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> >at least one character. It doesn't seem necessary to enforce that s=
> >have anything in them (like a space). Other textual Internet protocols
> >seem to be fine with having empty unformatted fields (like Subject: in
> >email).
> 
> Sounds like s= might as well be optional then.  There's already a great
> deal of flexibility in SDP that makes interoperation difficult.  The field
> is marked as required in the spec and the grammar for "text" is clearly 1
> or more.  I don't see a compelling reason to change this.
> 
Any half-way robust implementation needs to be able to deal with missing
s= and with s= followed by nothing. Might as well get the benefit of
allowing it officially.


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 16:20: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 QAA10293
	for ; Sun, 23 Apr 2000 16:20: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 8413B44337; Sun, 23 Apr 2000 16:16:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id AA86A44336
	for ; Sun, 23 Apr 2000 16:16:11 -0400 (EDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08336;
	Sun, 23 Apr 2000 16:21:05 -0400 (EDT)
Message-ID: <39035D34.8447A618@dynamicsoft.com>
Date: Sun, 23 Apr 2000 16:29:40 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox 
Cc: Mark Wisdom , sip@lists.bell-labs.com
Subject: Re: [SIP] OPTIONS behaviour with forking proxy
References:  <200004191923.PAA21180@metro.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Lennox wrote:
> 
> On Wed, April 19 2000, "Mark Wisdom" wrote to "sip@lists.bell-labs.com" saying:
> 
> > What should a registration server acting as a forking proxy do when it
> > receives a SIP OPTIONS message which resolves to 2 or more contacts?
> >
> > A. Respond with "300 Multiple Choices".
> > B. Fork the request off to the multiple choices and then relay the
> >    first received response back to the original requester?
> > C. Something else.
> >
> > I suspect A, but I can't seem to find enough information in
> > RFC2543 to be certain.
> 
> OPTIONS isn't any different from any other method...you fork the request off
> to every registered location, and send back all the 2xx-class responses or
> the first failure response you get.

Just to be clear here - you send back all 200's, or you send the best
response presuming there are no 200's. The best response isn't
necessarily the first failure response.

Also, just like any other method, the server could alternately redirect
instead of forking, option A above.

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


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 16:47: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 QAA10446
	for ; Sun, 23 Apr 2000 16:47: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 318564433D; Sun, 23 Apr 2000 16:43:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C5C0544336
	for ; Sun, 23 Apr 2000 16:43:48 -0400 (EDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08353;
	Sun, 23 Apr 2000 16:49:02 -0400 (EDT)
Message-ID: <390363C2.9BAB847A@dynamicsoft.com>
Date: Sun, 23 Apr 2000 16:57:38 -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: confctrl@ISI.EDU, sip@lists.bell-labs.com
References: <38FE0135.131B0802@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

There was another issue raised; SDP says very little overall about case
sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
depend on the type. The only types which discuss case sensitivity are:

1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
seconds) characters are case sensitive.
2. a=charset:, which uses case insensitive matching for the character
set.

So, we also agreed that in the spirit of SDP, all other values are CASE
SENSITIVE unless otherwise noted. This includes the encoding name
Henning mentions below, which, along with the character set, represent
the only two case insensitive matches in SDP (I believe).

-Jonathan R. 

Henning Schulzrinne wrote:
> 
> During the SIP bake-off, two SDP-related issues were raised:
> 
> Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> at least one character. It doesn't seem necessary to enforce that s=
> have anything in them (like a space). Other textual Internet protocols
> seem to be fine with having empty unformatted fields (like Subject: in
> email).
> 
> Secondly, the rtpmap description does not specify whether the 'encoding
> name' is case-sensitive or not. Since it's also used as a media type and
> media types are case-insensitive (RFC 2616, 3.7), it probably makes
> sense to make them CI in SDP as well.
> 
> Comments are appreciated.
> 
> Henning

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


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 16:56:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10481
	for ; Sun, 23 Apr 2000 16:56:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C62F644344; Sun, 23 Apr 2000 16:51:57 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4568E44342
	for ; Sun, 23 Apr 2000 16:51:55 -0400 (EDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08358;
	Sun, 23 Apr 2000 16:57:11 -0400 (EDT)
Message-ID: <390365AA.CDDFE950@dynamicsoft.com>
Date: Sun, 23 Apr 2000 17:05:46 -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: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP issues raised at bake-off
References: <38FE3578.F0DD9C76@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 

> 5) From/To header
> 
> Some implementations do not put a space between the display name and the
> '<'. This is legal, if unusual.

Yup, as per Annex C:

> The grammar described by this specification is word-based. Except
>    where noted otherwise, linear white space (LWS) can be included
>    between any two adjacent words (token or quoted-string), and between
>    adjacent tokens and separators, without changing the interpretation
>    of a field. At least one delimiter (LWS and/or separators) MUST exist
>    between any two tokens (for the definition of "token" below), since
>    they would otherwise be interpreted as a single token.

The only place there MUST appear LWS is between tokens. Since > is a
separator, according to this paragraph,  LWS can appear, but not MUST
appear.

> 
> 6) Expires header
> 
> If a new registration has a shorter expiration date, it updates the old
> one.

Note that this is consistent with the Expires:0 operation; the reason we
did Expires:0 to erase registrations is that it didn't require special
case treatment for enabling removal. Thus, an implementation which does
not currently have code to special case 0 should work this way already.

> 
> 7) Multicast INVITE/REGISTER
> 
> It was suggested to include a maddr in the Via header containing the
> multicast address. This makes it easier for the server to tell that the
> request was received via multicast (since sockets may receive both
> unicast and multicast packets).

This is already specified in rfc2543:

> A proxy sending a request to a multicast address MUST add the "maddr"
>    parameter to its Via header field, and SHOULD add the "ttl"
>    parameter. If a server receives a request which contained an "maddr"
>    parameter in the topmost Via field, it SHOULD send the response to
>    the multicast address listed in the "maddr" parameter.

The text should be clarified in that it only says this for proxy. Its
also true for a UAC.

> 
> 8) Overlapping transactions
> 
> A number of people expressed unhappiness about not allowing overlapping
> transactions as it greatly complicates the client state machine for
> things like hold/mute. This may need to be discussed again. Maybe
> limiting this restriction to media list changes would address most of
> the concerns.
> 
> 9) Status code for non-matching media (in SDP)
> 
> Currently, we have 606 for "Not Acceptable", but this terminates
> searches. Thus, it was suggested that we may want to add a 488 code for
> incompatibility at an individual terminal (which allows the proxy to
> search elsewhere for matching media).

An implementation can send any 400 code, in fact, and just change the
reason phrase. No need to wait for an additional response code for
people to begin doing this.

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


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 17:20: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 RAA10651
	for ; Sun, 23 Apr 2000 17:20: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 B3F7344341; Sun, 23 Apr 2000 17:16:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5F89044336
	for ; Sun, 23 Apr 2000 17:16:32 -0400 (EDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA08379;
	Sun, 23 Apr 2000 17:21:30 -0400 (EDT)
Message-ID: <39036B5D.E5632AB1@dynamicsoft.com>
Date: Sun, 23 Apr 2000 17:30:05 -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: "Adam B. Roach" ,
        sip-implementors@cs.columbia.edu, sip 
References: <200004201613.LAA20522@b04a24.exu.ericsson.se> <38FF6EF1.7C8659DF@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Lessons learned...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Igor Slepchin wrote:
> 
> "Adam B. Roach" wrote:
> >
> >    - 408 vs 504
> >
> >        408 is to be used when a request cannot be completed in the
> >            time specified in the "Expires" header.
> >
> >        504 is to be used when a proxy or other type of gateway
> >            doesn't receive a response from a next-hop node.
> 
> That sounds fine except that the current description of 408 is too
> restrictive. I think 408 should also be sent when a proxy gives up
> waiting for a final response due to some internal timeout (e.g., after a
> 1xx is received, INVITE transactions hang around forever unless some
> timeout is configured for them). 504 should only be used when no
> response whatsoever was received from a next hop.

Actually, I had a different interpretation of 504. 504 is when a proxy
tries to contact some other service, like a location server, and that
service does not respond. Thats why its a server failure; the other
service represents part of the operation of the server itself (many
folks include the location service within the proxy, for example). Thats
why its 500 class.

Also, I agree with Igor that 408 is used when a proxy gives up. Be
warned about this, however. Lets say a proxy forwards some request, gets
a 100. It then times out, and sends a 408. Unfortunately, the next hop
server then responds with a 300. Kind of too late... THe ideal solution
here is that when the timer expires, the proxy sends a CANCEL. This
should cause an almost immediate final response to the original request,
which can then be forwarded, or a 408 generated. This is safer, in the
sense that the server knows what the response from downstream is. Of
course, it gets more complicated if the CANCEL does not generate a
response to the original request. In this case, you are dealing with (1)
a UA which does not respond to the original request with 487 upon
receiving CANCEL, since you do not have to according to rfc2543, or (2)
some kind of downstream failure. In either case, you are much safer in
generating the 408. 

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


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 17: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 RAA10698
	for ; Sun, 23 Apr 2000 17:30:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5F8544349; Sun, 23 Apr 2000 17:25:59 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.mera.ru (FireWall.mera.ru [195.98.50.58])
	by lists.bell-labs.com (Postfix) with ESMTP id 4C9B144342
	for ; Sun, 23 Apr 2000 17:25:56 -0400 (EDT)
Received: from abc (abc.mera.ru [195.98.57.251])
	by mail.mera.ru (8.9.3/8.9.3) with SMTP id BAA23857
	for ; Mon, 24 Apr 2000 01:29:54 +0400 (MSD)
Message-ID: <032e01bfad6c$e1454630$fb3962c3@mera.ru>
From: "Alexei Prokofiev" 
To: 
References: <38FE3578.F0DD9C76@cs.columbia.edu> <390365AA.CDDFE950@dynamicsoft.com>
Subject: Re: [SIP] SIP issues raised at bake-off
Date: Mon, 24 Apr 2000 01:42: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.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

in case replies are sent by a server UA via several TCP connections 
(for example, a new connection is created for each message) close 
out of which of the connetions must be treated by a client UA as 
CANCEL in case the transaction is not complete?

Thank you for your responce.
-----------
Alex Prokofiev
Mera Labs



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


From sip-admin@lists.bell-labs.com  Sun Apr 23 17:35: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 RAA10769
	for ; Sun, 23 Apr 2000 17:35: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 C7EE744353; Sun, 23 Apr 2000 17:31:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5101D44336
	for ; Sun, 23 Apr 2000 17:31:37 -0400 (EDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA08384;
	Sun, 23 Apr 2000 17:35:46 -0400 (EDT)
Message-ID: <39036EB5.3CC03C44@dynamicsoft.com>
Date: Sun, 23 Apr 2000 17:44:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" 
Cc: sip-implementors@cs.columbia.edu, sip ,
        Igor Slepchin 
References: <200004201613.LAA20522@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Lessons learned...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Adam B. Roach" wrote:
> 

>    - 480 vs 603
> 
>        480 indicates that the user is, for some reason, unavailable.
>            This would be appropriate, for example, if a phone
>            is in a "do not disturb" mode.
> 
>        603 means that the user you are trying to contact has been
>            reached, and has explicitly declined this particular
>            phone call. This would be appropriate if, for example,
>            your device/program displays the name of the caller,
>            and the called party presses a "reject" button.
> 
>    486 vs 600
> 
>        486 is a device busy state. This is what you normally think
>            of when you get a busy tone.
> 
>        600 is a user busy state. There is no analogous situation in
>            today's telephony system. It means that you have
>            contacted the correct user, but he has indicated
>            that he will not take the call because he is busy.
>            It is completely inappropriate to return a 600 for a
>            device busy state, since it termintates outstanding
>            searches.

Absolutely correct. The big difference between 400 and 600 is search
termination.


> 3) This is actually a disagreement I have with RFC2543, and
>    one that I raised some time ago; however, no one seemed
>    interested at the time. Since it actively prevented us from
>    running one of the test cases we wanted to run at this bakeoff,
>    I'm going to raise the issue again. Take discussion on this
>    topic to the SIP working group mailing list, please.
> 
>    According to section 6.37, an implementation should reject
>    messages containing unknown URIs in the "To:" field with
>    a 400 response. Many implementations actually did this.
>    The test case we were attempting was as follows:
> 
>    UAC1 ----> tel: mapping proxy -----> UAC2
> 
>    UAC1 then sends a message to the tel: mapping proxy like:
> 
>      INVITE tel:5551234 SIP/2.0
>      To: 
>      From: ;tag=12345
>      Call-ID: fffff@uac1
>      CSeq: 7654 INVITE
> 
>    Because the proxy mapped the request URI, the INVITE that
>    UAC2 received ends up looking like:
> 
>      INVITE sip:5551234@uac2 SIP/2.0
>      To: 
>      From: ;tag=12345
>      Call-ID: fffff@uac1
>      CSeq: 7654 INVITE
> 
>    UAC2 definitely has quite enough information to service the
>    call. In fact, if not for this clause in 2543, the call would
>    be set up perfectly. I contend that clients shouldn't
>    care if they understand the URI in the To: field, as long
>    as they can process the call, and I encourage implementations
>    to exhibit this behavior.
> 
>    This also follows naturally from what I suggested above: don't
>    validate fields unless you intend to use the information
>    contained in them.

Hmm. This is a good point. Given the increasing use of tel URLs, its
probably worth changing this in rfc2543bis. This doesn't introduce
backwards compatibility problems; it just means that calls to UAs
compliant to the bis version will get set up successfully, when they
won't with rfc2543.

In general, the *request URI* is what is important in processing a
request. The To field is used only for (1) call leg identification
(along with From and Call-ID), and (2) FYI to the called party. The
request URI represents the desired user at the server being contacted.
The To field may contain a URI which is meaningless within the namespace
served by the server. 


Thanks for putting these lessons learned together. They should be
incorporated into the FAQ.

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


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


From sip-admin@lists.bell-labs.com  Sun Apr 23 23:46:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15362
	for ; Sun, 23 Apr 2000 23:46:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F20D544337; Sun, 23 Apr 2000 23:41:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8491144336
	for ; Sun, 23 Apr 2000 23:41:44 -0400 (EDT)
Received: from dynamicsoft.com (1Cust43.tnt3.freehold.nj.da.uu.net [63.25.172.43])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA08613;
	Sun, 23 Apr 2000 23:46:36 -0400 (EDT)
Message-ID: <3903C5A1.412BDDA0@dynamicsoft.com>
Date: Sun, 23 Apr 2000 23:55:13 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alexei Prokofiev 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP issues raised at bake-off
References: <38FE3578.F0DD9C76@cs.columbia.edu> <390365AA.CDDFE950@dynamicsoft.com> <032e01bfad6c$e1454630$fb3962c3@mera.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The server should not open a new connection to send a response if one is
already open. You should not be opening a new connection for each
response.

As a result, it is the original connection the request was sent on,
that, if closed, implies CANCEL.

-Jonathan R.

Alexei Prokofiev wrote:
> 
> Hi,
> 
> in case replies are sent by a server UA via several TCP connections
> (for example, a new connection is created for each message) close
> out of which of the connetions must be treated by a client UA as
> CANCEL in case the transaction is not complete?
> 
> Thank you for your responce.
> -----------
> Alex Prokofiev
> Mera Labs
> 
> _______________________________________________
> 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:   (732) 741-4778
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 Apr 24 02: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 CAA28070
	for ; Mon, 24 Apr 2000 02:18: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 92EEB44337; Mon, 24 Apr 2000 02:14:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C17044336
	for ; Mon, 24 Apr 2000 02:13:59 -0400 (EDT)
Received: from dynamicsoft.com (1Cust43.tnt3.freehold.nj.da.uu.net [63.25.172.43])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA08672;
	Mon, 24 Apr 2000 02:19:12 -0400 (EDT)
Message-ID: <3903E962.F1527AA2@dynamicsoft.com>
Date: Mon, 24 Apr 2000 02:27:46 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Handley 
Cc: Henning Schulzrinne , confctrl@ISI.EDU,
        sip@lists.bell-labs.com
References: <33072.956556329@hazard.aciri.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Mark Handley wrote:
> 
> >There was another issue raised; SDP says very little overall about case
> >sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
> >depend on the type. The only types which discuss case sensitivity are:
> >
> >1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
> >seconds) characters are case sensitive.
> >2. a=charset:, which uses case insensitive matching for the character
> >set.
> >
> >So, we also agreed that in the spirit of SDP, all other values are CASE
> >SENSITIVE unless otherwise noted. This includes the encoding name
> >Henning mentions below, which, along with the character set, represent
> >the only two case insensitive matches in SDP (I believe).
> 
> RFC 2367 states:
> 
>    An SDP session description consists of a number of lines of text of
>    the form =  is always exactly one character and is
>    case-significant.   is a structured text string whose format
>    depends on .  It also will be case-significant unless a
>    specific field defines otherwise.

Duh. Of all the sentences in the spec I miss, somehow its this one. My
apologies. I'm glad at least the recommended clarification we made fits
with whats actually in the spec :)

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
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 Apr 24 03:01:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28291
	for ; Mon, 24 Apr 2000 03:01: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 1C3464433B; Mon, 24 Apr 2000 02:56:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx2.wipro.com (unknown [203.197.164.42])
	by lists.bell-labs.com (Postfix) with ESMTP id 9D9C744336
	for ; Mon, 24 Apr 2000 02:56:43 -0400 (EDT)
Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50])
	by wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id PAA19898
	for ; Mon, 24 Apr 2000 15:04:02 +0530
Received: from sarovar.mail.wipro.com ([164.164.27.50])
          by m2vwall1.wipro.com (Netscape Messaging Server 3.6)  with ESMTP
          id AAA653B for ;
          Mon, 24 Apr 2000 12:30:14 +0530
Received: from hiren ([192.168.243.67]) by sarovar.mail.wipro.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA53CF
          for ; Mon, 24 Apr 2000 12:32:21 +0530
Message-ID: <009101bfadba$c24187a0$43f3a8c0@hiren.wipinfo.soft.net>
From: "Hiren Shah" 
To: 
Date: Mon, 24 Apr 2000 12:30:21 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_008E_01BFADE8.DBA2A2F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Subject: [SIP] MGCP / SIP interaction
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

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

Hi all

I have a small doubt in the concept.
Suppose MGCP protocol is used to transfer audio between two telephones =
through a packet network using the call agents and media gateways.
I have read that SIP is used between the call agent to call agent =
communication in a wide network. I am failing to get the point behind =
this.Please send me some justification of why SIP is required between =
the communication.

regards
Hiren










A Candle never  loses any of its light by lighting other Candles

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












Hi all


 


I have a small doubt in the concept.


Suppose MGCP protocol is used to transfer audio between two =
telephones=20
through a packet network using the call agents and media gateways.


I have read that SIP is used between the call agent to call agent=20
communication in a wide network. I am failing to get the point behind=20
this.Please send me some justification of why SIP is required between =
the=20
communication.


 


regards


Hiren


 


 


 


 


 


 


 


 


 


 


A Candle never  loses any of its light by lighting other=20
Candles


------=_NextPart_000_008E_01BFADE8.DBA2A2F0--



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 08: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 IAA01699
	for ; Mon, 24 Apr 2000 08:25: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 7829844336; Mon, 24 Apr 2000 08:21:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web219.mail.yahoo.com (web219.mail.yahoo.com [128.11.68.119])
	by lists.bell-labs.com (Postfix) with SMTP id A8AD044336
	for ; Sun, 23 Apr 2000 13:03:48 -0400 (EDT)
Received: (qmail 2724 invoked by uid 60001); 23 Apr 2000 17:07:50 -0000
Message-ID: <20000423170750.2723.qmail@web219.mail.yahoo.com>
Received: from [209.245.140.58] by web219.mail.yahoo.com; Sun, 23 Apr 2000 10:07:50 PDT
Date: Sun, 23 Apr 2000 10:07:50 -0700 (PDT)
From: Ilya Slain 
To: sip@lists.bell-labs.com
Cc: ilyas2@yahoo.com, binguyen@cisco.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] mwi in SIP: supplying waiting message lists
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


There has recently been some discussion on the way to
do message waiting indication (mwi) using SUBSCRIBE/
NOTIFY SIP extensions.  However, I am not aware of
any proposals to for specifying waiting message list
summary, supplied in mwi NOTIFY message.  In other
words, there is no proposed way to supply the summary
of messages being available in the voice mail system.

So I would like to submit a brief sample proposal to
do
message waiting indication with message summary using
SIP
SUBSCRIBE/NOTIFY.  This is based on the recent
SUBSCSRIBE/
NOTIFY IETF draft:
http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt

The main purpose of this proposal is to start the
discussion
on the topic with the aim of eventually submitting an
Inf. Draft.

1. Subscription
----------------
Event field specifies "mwi" field (message waiting
indication).
There is no message body.

SUBSCRIBE ...
To:             ...
From:           ...
Call-ID:        ...
CSeq:           ...
Contact:        ...
Expires:        ...
Event:          mwi
Content-Length: 0

2. Notification
-----------------
Event field specifies "mwi".
Message body specifies the message summary.

NOTIFY
To:             ...
From:           ...
Call-ID:        ...
CSeq:           ...
Contact:        ...
Expires:        ...
Event:          mwi
Content-Type:   application/um
Content-Length: 148

VOICEMAIL: ; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
EMAIL:     ; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
FAX:       ; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
VIDEO:     ; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2

where TOTAL_MESSAGES, n1, n2 are integers
U = UNTOUCHED
S = SKIPPED
F = FLAGGED
R = READ
A = ANSWERED
D = DELETED

For example:
voicemail: 10; U:3/1; S:1/0; F:0/0; R:5/2; A:1/0;
D:0/0
where U: 3/1  indicates that there are 3 untouched
messages, 1 of which is urgent.

More formal grammar for the application/um message
body:

application_um_message_body = message_summary_list
message_summary_list = message_summary "\n"
message_summary_list | NULL
message_summary = message_type ": " total_messages ";
" typed_summary_list
message_type = "VOICEMAIL" | "EMAIL" | "FAX" | "VIDEO"
total_messages = INTEGER
typed_summary_list = typed_summary ";"
typed_summary_list | NULL
typed_summary = type ":" number_of_messages "/"
number_of_urgent_messages
type = "U" | "S" | "F" | "R" | "A" | "D"
number_of_messages = INTEGER
number_of_urgent_messages = INTEGER

______________________________________________________________________________

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




__________________________________________________
Do You Yahoo!?
Send online invitations 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 Apr 24 08:29:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01745
	for ; Mon, 24 Apr 2000 08:29:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F0F9A44344; Mon, 24 Apr 2000 08:24:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from prognet.com (prognet.com [205.219.198.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 48B3444336
	for ; Mon, 24 Apr 2000 01:11:17 -0400 (EDT)
Received: from jeffa_laptop ([172.23.103.129])
	by prognet.com (8.9.2/8.9.0) with ESMTP id WAA24913;
	Sun, 23 Apr 2000 22:15:36 -0700 (PDT)
Message-Id: <4.2.0.58.20000423220632.03e73810@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 23 Apr 2000 22:13:36 -0700
To: Jonathan Rosenberg ,
        Henning Schulzrinne 
From: Jeff Ayars 
Cc: confctrl@ISI.EDU, sip@lists.bell-labs.com
In-Reply-To: <390363C2.9BAB847A@dynamicsoft.com>
References: <38FE0135.131B0802@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

At 04:57 PM 4/23/00 -0400, Jonathan Rosenberg wrote:
>There was another issue raised; SDP says very little overall about case
>sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
>depend on the type. The only types which discuss case sensitivity are:
>
>1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
>seconds) characters are case sensitive.
>2. a=charset:, which uses case insensitive matching for the character
>set.
>
>So, we also agreed that in the spirit of SDP, all other values are CASE
>SENSITIVE unless otherwise noted. This includes the encoding name
>Henning mentions below, which, along with the character set, represent
>the only two case insensitive matches in SDP (I believe).
>
>-Jonathan R.

I'm confused by this last paragraph.  First you say all 'other' values are 
CASE SENSITIVE.  Then you say that encoding name, along with the character 
set represent the only two case insensitive matches.

So are you agreeing that  from a=rtpmap and  from m= 
should be CASE INSENSITIVE?  Or are you saying that since SDP is silent on 
the case sensitivity of  and  that they should be 
CASE SENSITIVE?

I agree with Henning's suggestion below that since  and  form a media type and media types are CASE INSENSITIVE, that  
and  should also be CASE INSENSITIVE.

Jeff Ayars
Technical Lead
RealNetworks, Inc.


>Henning Schulzrinne wrote:
> >
> > During the SIP bake-off, two SDP-related issues were raised:
> >
> > Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> > at least one character. It doesn't seem necessary to enforce that s=
> > have anything in them (like a space). Other textual Internet protocols
> > seem to be fine with having empty unformatted fields (like Subject: in
> > email).
> >
> > Secondly, the rtpmap description does not specify whether the 'encoding
> > name' is case-sensitive or not. Since it's also used as a media type and
> > media types are case-insensitive (RFC 2616, 3.7), it probably makes
> > sense to make them CI in SDP as well.
> >
> > Comments are appreciated.
> >
> > Henning
>
>--
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com





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


From sip-admin@lists.bell-labs.com  Mon Apr 24 08:30: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 IAA01771
	for ; Mon, 24 Apr 2000 08:30: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 600544434F; Mon, 24 Apr 2000 08:24:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by lists.bell-labs.com (Postfix) with ESMTP id CD09044336
	for ; Mon, 24 Apr 2000 02:01:30 -0400 (EDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id XAA33074;
	Sun, 23 Apr 2000 23:05:30 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley 
X-Organisation: ACIRI
To: Jonathan Rosenberg 
Cc: Henning Schulzrinne , confctrl@ISI.EDU,
        sip@lists.bell-labs.com
In-reply-to: Your message of "Sun, 23 Apr 2000 16:57:38 EDT."
             <390363C2.9BAB847A@dynamicsoft.com> 
Date: Sun, 23 Apr 2000 23:05:29 -0700
Message-ID: <33072.956556329@hazard.aciri.org>
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


>There was another issue raised; SDP says very little overall about case
>sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
>depend on the type. The only types which discuss case sensitivity are:
>
>1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
>seconds) characters are case sensitive.
>2. a=charset:, which uses case insensitive matching for the character
>set.
>
>So, we also agreed that in the spirit of SDP, all other values are CASE
>SENSITIVE unless otherwise noted. This includes the encoding name
>Henning mentions below, which, along with the character set, represent
>the only two case insensitive matches in SDP (I believe).


RFC 2367 states:

   An SDP session description consists of a number of lines of text of
   the form =  is always exactly one character and is
   case-significant.   is a structured text string whose format
   depends on .  It also will be case-significant unless a
   specific field defines otherwise.

The only place where RFC 2367 states that something is case-insentive
is in the case of the charset attribute.

By default, this means that attributes are case-sensitive unless
specified otherwise, and all other fields are case-sensitive.

In the case of the rtpmap attribute, the issue of the meaning of
encoding names is punted to the relevant RTP profile spec.  As far as
SDP is concerned, they're case _sensitive_ by virtue of not specifying
otherwise.  However, the RTP AV profile specifies that the encoding
name is a MIME subtype, and I believe MIME specifies that subtypes are
not case sensitive.  Hence when rtpmap is used with protocol "RTP/AVP"
(and it's not currently specified for any other protocol), then
although the SDP string is case-sensitive to the SDP parser, it makes
sense to treat the encoding name as case-insensitive.  The rest of the
rtpmap attribute would still be case-sensitive.

BTW RFC 2327 also specifies:

   SDP session descriptions are entirely textual using the ISO 10646
   character set in UTF-8 encoding. SDP field names and attributes names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values may use the full ISO 10646 character set.

Thus the rtpmap attribute (with the exception of the attribute name
("rtpmap") itself) is also in ISO 10646 UTF 8.  However, the encoding
name is going to have to be in the US ASCII subset of ISO 10646 UTF 8
to be a valid MIME subtype, although the SDP syntax allows non-ASCII
encoding names.  

The key point is that SDP doesn't specify how to interpret the
encoding-name at all.  The RTP AV profile specifies this, and so adds
additional semantics to the basic SDP syntax.  

Cheers,
	Mark



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 08:32:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01853
	for ; Mon, 24 Apr 2000 08:32: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 2E29C44354; Mon, 24 Apr 2000 08:24:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by lists.bell-labs.com (Postfix) with ESMTP id 9184E44336
	for ; Sat, 22 Apr 2000 22:08:55 -0400 (EDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id TAA25567;
	Sat, 22 Apr 2000 19:12:47 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley 
X-Organisation: ACIRI
To: Henning Schulzrinne 
Cc: Jeff Ayars , Henning Schulzrinne ,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
In-reply-to: Your message of "Sat, 22 Apr 2000 20:50:25 EDT."
             <390248D1.1659235E@cs.columbia.edu> 
Date: Sat, 22 Apr 2000 19:12:47 -0700
Message-ID: <25565.956455967@hazard.aciri.org>
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


>Any half-way robust implementation needs to be able to deal with missing
>s= and with s= followed by nothing. Might as well get the benefit of
>allowing it officially.

Whatever you might wish the SDP spec would say, it's fairly clear on
this issue: if there's no s= line, you should treat the SDP as
corrupted and act accordingly.  If you send SDP without the s= line,
you are definitely not compliant with RFC 2327 and shouldn't expect
your message to be accepted.

Changing the spec at this stage would introduce backward compatibility
issues, so should not be done lightly.  The more incompatible changes
we introduce, the less likely we are to be able to move SDP (and hence
SIP and RTSP) to Draft Standard without cycling it at Proposed
Standard first.

Cheers,
	Mark



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 08:34:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01879
	for ; Mon, 24 Apr 2000 08:34:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A3264435A; Mon, 24 Apr 2000 08:24:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from prognet.com (prognet.com [205.219.198.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 7FA4A44336
	for ; Sat, 22 Apr 2000 20:40:35 -0400 (EDT)
Received: from jeffa_laptop ([172.23.103.129])
	by prognet.com (8.9.2/8.9.0) with ESMTP id RAA08532;
	Sat, 22 Apr 2000 17:44:43 -0700 (PDT)
Message-Id: <4.2.0.58.20000422173715.00b4a770@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 22 Apr 2000 17:44:00 -0700
To: Henning Schulzrinne , confctrl@ISI.EDU,
        sip@lists.bell-labs.com
From: Jeff Ayars 
In-Reply-To: <38FE0135.131B0802@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

At 02:55 PM 4/19/00 -0400, Henning Schulzrinne wrote:
>During the SIP bake-off, two SDP-related issues were raised:
>
>Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
>at least one character. It doesn't seem necessary to enforce that s=
>have anything in them (like a space). Other textual Internet protocols
>seem to be fine with having empty unformatted fields (like Subject: in
>email).

Sounds like s= might as well be optional then.  There's already a great 
deal of flexibility in SDP that makes interoperation difficult.  The field 
is marked as required in the spec and the grammar for "text" is clearly 1 
or more.  I don't see a compelling reason to change this.


>Secondly, the rtpmap description does not specify whether the 'encoding
>name' is case-sensitive or not. Since it's also used as a media type and
>media types are case-insensitive (RFC 2616, 3.7), it probably makes
>sense to make them CI in SDP as well.

I completely agree with this clarification.  We have always treated it as 
case-insensitive and a consistent interpretation is needed for interoperation.

Jeff Ayars
Technical Lead, Core Technologies
RealNetworks, Inc.





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


From sip-admin@lists.bell-labs.com  Mon Apr 24 11:40: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 LAA06418
	for ; Mon, 24 Apr 2000 11:40: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 7BE4344337; Mon, 24 Apr 2000 11:36:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by lists.bell-labs.com (Postfix) with ESMTP id C68D044336
	for ; Mon, 24 Apr 2000 11:36:03 -0400 (EDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA29864; Mon, 24 Apr 2000 08:39:08 -0700 (PDT)
Message-Id: <4.3.1.2.20000424110320.00c2e880@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Apr 2000 11:16:11 -0400
To: Mark Handley , Jonathan Rosenberg 
From: Chip Sharp 
Cc: Henning Schulzrinne , confctrl@ISI.EDU,
        sip@lists.bell-labs.com
In-Reply-To: <33072.956556329@hazard.aciri.org>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Re: SDP issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Thanks for the clarification.

When moving to Draft,  the ABNF should be made consistent with the main 
text in regards to case-sensitivity.

RFC2234 (ABNF) states:
"NOTE:     ABNF strings are case-insensitive and
            the character set for these strings is us-ascii."

An example of the change needed in the ABNF is:
      attribute-fields =    *("a=" attribute CRLF)
should be:
      attribute-fields =    *(%x61 attribute CRLF)

Chip

At 11:05 PM 4/23/00 -0700, Mark Handley wrote:

> >There was another issue raised; SDP says very little overall about case
> >sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
> >depend on the type. The only types which discuss case sensitivity are:
> >
> >1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
> >seconds) characters are case sensitive.
> >2. a=charset:, which uses case insensitive matching for the character
> >set.
> >
> >So, we also agreed that in the spirit of SDP, all other values are CASE
> >SENSITIVE unless otherwise noted. This includes the encoding name
> >Henning mentions below, which, along with the character set, represent
> >the only two case insensitive matches in SDP (I believe).
>
>
>RFC 2367 states:
>
>    An SDP session description consists of a number of lines of text of
>    the form =  is always exactly one character and is
>    case-significant.   is a structured text string whose format
>    depends on .  It also will be case-significant unless a
>    specific field defines otherwise.
>
>The only place where RFC 2367 states that something is case-insentive
>is in the case of the charset attribute.
>
>By default, this means that attributes are case-sensitive unless
>specified otherwise, and all other fields are case-sensitive.
>
>In the case of the rtpmap attribute, the issue of the meaning of
>encoding names is punted to the relevant RTP profile spec.  As far as
>SDP is concerned, they're case _sensitive_ by virtue of not specifying
>otherwise.  However, the RTP AV profile specifies that the encoding
>name is a MIME subtype, and I believe MIME specifies that subtypes are
>not case sensitive.  Hence when rtpmap is used with protocol "RTP/AVP"
>(and it's not currently specified for any other protocol), then
>although the SDP string is case-sensitive to the SDP parser, it makes
>sense to treat the encoding name as case-insensitive.  The rest of the
>rtpmap attribute would still be case-sensitive.
>
>BTW RFC 2327 also specifies:
>
>    SDP session descriptions are entirely textual using the ISO 10646
>    character set in UTF-8 encoding. SDP field names and attributes names
>    use only the US-ASCII subset of UTF-8, but textual fields and
>    attribute values may use the full ISO 10646 character set.
>
>Thus the rtpmap attribute (with the exception of the attribute name
>("rtpmap") itself) is also in ISO 10646 UTF 8.  However, the encoding
>name is going to have to be in the US ASCII subset of ISO 10646 UTF 8
>to be a valid MIME subtype, although the SDP syntax allows non-ASCII
>encoding names.
>
>The key point is that SDP doesn't specify how to interpret the
>encoding-name at all.  The RTP AV profile specifies this, and so adds
>additional semantics to the basic SDP syntax.
>
>Cheers,
>      Mark


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 11:55: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 LAA06846
	for ; Mon, 24 Apr 2000 11:55: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 3BA7D4433D; Mon, 24 Apr 2000 11:51: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 96A354433C
	for ; Mon, 24 Apr 2000 11:51:34 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26391;
	Mon, 24 Apr 2000 11:55:38 -0400 (EDT)
Message-ID: <39046E7A.4B89B440@cs.columbia.edu>
Date: Mon, 24 Apr 2000 11:55:38 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Chip Sharp 
Cc: Mark Handley , Jonathan Rosenberg ,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: Re: [SIP] Re: SDP issues
References:  <4.3.1.2.20000424110320.00c2e880@dogwood.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Chip Sharp wrote:
> 
> Thanks for the clarification.
> 
> When moving to Draft,  the ABNF should be made consistent with the main
> text in regards to case-sensitivity.
> 
> RFC2234 (ABNF) states:
> "NOTE:     ABNF strings are case-insensitive and
>             the character set for these strings is us-ascii."
> 
> An example of the change needed in the ABNF is:
>       attribute-fields =    *("a=" attribute CRLF)
> should be:
>       attribute-fields =    *(%x61 attribute CRLF)

Are you sure that applies to the protocol specified by the grammar or
just to the tokens within the ABNF, so that "CRLF" and "crlf" are
equivalent?
-- 
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 Apr 24 12:18:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07775
	for ; Mon, 24 Apr 2000 12:18:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EB0154433B; Mon, 24 Apr 2000 12:13:52 -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 2A06A44336
	for ; Mon, 24 Apr 2000 12:13:50 -0400 (EDT)
Received: from vovida.com ([209.237.8.98])
	by repulse.cnchost.com
	id MAA05255; Mon, 24 Apr 2000 12:17:59 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <390473B7.8597609E@vovida.com>
Date: Mon, 24 Apr 2000 09:17:59 -0700
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPbell-labs 
Content-Type: multipart/alternative;
 boundary="------------04329C6B54038759919D318E"
Subject: [SIP] SUBSCRIBE / NOTIFY discussions
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


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

Hi:

How do I subscribe for this in the e-groups list.

Thanks much!

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



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



Hi:

How do I subscribe for this in the e-groups list.

Thanks much!

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

 

--------------04329C6B54038759919D318E--



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 12: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 MAA08495
	for ; Mon, 24 Apr 2000 12: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 56A234433C; Mon, 24 Apr 2000 12:36:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by lists.bell-labs.com (Postfix) with ESMTP id 954F74433B
	for ; Mon, 24 Apr 2000 12:36:09 -0400 (EDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA25649; Mon, 24 Apr 2000 09:39:14 -0700 (PDT)
Message-Id: <4.3.1.2.20000424122411.00b109a0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Apr 2000 12:29:43 -0400
To: Henning Schulzrinne 
From: Chip Sharp 
Subject: Re: [SIP] Re: SDP issues
Cc: Mark Handley , Jonathan Rosenberg ,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
In-Reply-To: <39046E7A.4B89B440@cs.columbia.edu>
References: 
 <4.3.1.2.20000424110320.00c2e880@dogwood.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:  
X-BeenThere: sip@lists.bell-labs.com

At 11:55 AM 4/24/00 -0400, Henning Schulzrinne wrote:
>Chip Sharp wrote:
> >
> > Thanks for the clarification.
> >
> > When moving to Draft,  the ABNF should be made consistent with the main
> > text in regards to case-sensitivity.
> >
> > RFC2234 (ABNF) states:
> > "NOTE:     ABNF strings are case-insensitive and
> >             the character set for these strings is us-ascii."
> >
> > An example of the change needed in the ABNF is:
> >       attribute-fields =    *("a=" attribute CRLF)
> > should be:
> >       attribute-fields =    *(%x61 attribute CRLF)
>
>Are you sure that applies to the protocol specified by the grammar or
>just to the tokens within the ABNF, so that "CRLF" and "crlf" are
>equivalent?

These days, I'm not "sure" of much of anything. :-)

I don't believe RFC2234 is very clear on this issue either.
However, if you look at page 5 under "Concatenation" there is this example:

----begin quote----
    A rule can define a simple, ordered string of values -- i.e., a
    concatenation of contiguous characters -- by listing a sequence of
    rule names.  For example:

         foo         =  %x61           ; a

         bar         =  %x62           ; b

         mumble      =  foo bar foo

         So that the rule  matches the lowercase string "aba".
----end quote----

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


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 13: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 NAA09929
	for ; Mon, 24 Apr 2000 13:41:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4E29844337; Mon, 24 Apr 2000 13:36:39 -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 C187F44336
	for ; Mon, 24 Apr 2000 13:36:36 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA10364;
	Mon, 24 Apr 2000 13:40:43 -0400 (EDT)
Message-ID: <3904871B.8B0108F1@cs.columbia.edu>
Date: Mon, 24 Apr 2000 13:40:43 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" 
Cc: Jonathan Rosenberg ,
        Igor Slepchin ,
        sip-implementors@cs.columbia.edu, sip 
References: <200004241614.LAA00955@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Lessons learned...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

"Adam B. Roach" wrote:
> 
> Jonathan Rosenberg writes:
> >Actually, I had a different interpretation of 504. 504 is when a proxy
> >tries to contact some other service, like a location server, and that
> >service does not respond. Thats why its a server failure; the other
> >service represents part of the operation of the server itself (many
> >folks include the location service within the proxy, for example). Thats
> >why its 500 class.
> >
> >Also, I agree with Igor that 408 is used when a proxy gives up.
> ...
> 
> I have no problem with this model; it does, however, require that
> the description of 408 be updated in RFC2543bis.

Current (modified) wording is:

The server could not produce a response, e.g., a user location, within
the time indicated in the \header{Expires} request-header field.  The
client {\MAY} repeat the request without modifications at any later
time.

Please suggest improvements.


-- 
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 Apr 24 13:44: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 NAA10007
	for ; Mon, 24 Apr 2000 13:44: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 A0A8344344; Mon, 24 Apr 2000 13:40:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by lists.bell-labs.com (Postfix) with SMTP id D07184433F
	for ; Mon, 24 Apr 2000 13:40:09 -0400 (EDT)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Apr 2000 10:43:37 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58)
	id ; Mon, 24 Apr 2000 10:43:37 -0700
Message-ID: 
From: Christian Huitema 
To: "'Mark Handley'" 
Cc: Jeff Ayars , confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: RE: [SIP] Re: SDP issues
Date: Mon, 24 Apr 2000 10:43:34 -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:  
X-BeenThere: sip@lists.bell-labs.com

> Whatever you might wish the SDP spec would say, it's fairly clear on
> this issue: if there's no s= line, you should treat the SDP as
> corrupted and act accordingly.  If you send SDP without the s= line,
> you are definitely not compliant with RFC 2327 and shouldn't expect
> your message to be accepted.

What we are seeing here is a conflict between SAP and SIP. SDP was
originally designed for the multicast session directory programs (sd, sdr)
that use a session id to correlate advertizements from multiple possible
announcers. If you do that, then you need a very complete and autonomous
session description, including session-id and timing parameters.

SDP is then used in SIP (and also MGCP and Megaco) as a way to describe and
negotiate the characteristics of a "private session." If the beginning and
end of the sessions are bracketed by the INVITE and BYE requests, if the
sessions are identified by a SIP "Call-id," then the SDP level session
identifiers and timing indicators are somewhat redundant.

What we probably need is a profile of some sort, that qualifies what is
mandatory and when. For example, I believe that a fully formed "s=" field
MUST be present when announcements of multicast sessions are multicast in
SAP. The same requirement would logically apply when invitations to the same
sessions are sent via SIP. But the requirement is not all that logical for
invitations to ephemeral point to point sessions -- the robustness principle
would dictate that inviters SHOULD fill up a session field, but that
invitees should not reject invitations to point to point sessions when the
"s=" field is absent.


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


From sip-admin@lists.bell-labs.com  Mon Apr 24 15:02:07 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12270
	for ; Mon, 24 Apr 2000 15:01: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 2895444336; Mon, 24 Apr 2000 14:57:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 0F5F744336
	for ; Mon, 24 Apr 2000 12:10:21 -0400 (EDT)
Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA10718;
	Mon, 24 Apr 2000 11:14:27 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA02379;
	Mon, 24 Apr 2000 11:14:26 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA07186; Mon, 24 Apr 2000 11:14:26 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA00955;
	Mon, 24 Apr 2000 11:14:25 -0500 (CDT)
Message-Id: <200004241614.LAA00955@b04a24.exu.ericsson.se>
To: jdrosen@dynamicsoft.com (Jonathan Rosenberg)
Date: Mon, 24 Apr 2000 11:14:25 -0500 (CDT)
Cc: islepchin@dynamicsoft.com (Igor Slepchin),
        sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com (sip)
In-Reply-To: <39036B5D.E5632AB1@dynamicsoft.com> from "Jonathan Rosenberg" at Apr 23, 2000 05:30:05 PM
From: "Adam B. Roach" 
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Lessons learned...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
>Actually, I had a different interpretation of 504. 504 is when a proxy
>tries to contact some other service, like a location server, and that
>service does not respond. Thats why its a server failure; the other
>service represents part of the operation of the server itself (many
>folks include the location service within the proxy, for example). Thats
>why its 500 class.
>
>Also, I agree with Igor that 408 is used when a proxy gives up.
...

I have no problem with this model; it does, however, require that
the description of 408 be updated in RFC2543bis.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 15:08: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 PAA12291
	for ; Mon, 24 Apr 2000 15:02: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 03FF94433C; Mon, 24 Apr 2000 14:57:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id C67BE44336
	for ; Mon, 24 Apr 2000 14:29:55 -0400 (EDT)
Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA23298;
	Mon, 24 Apr 2000 13:34:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA27852;
	Mon, 24 Apr 2000 13:34:03 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA14374; Mon, 24 Apr 2000 13:34:03 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA01622;
	Mon, 24 Apr 2000 13:34:02 -0500 (CDT)
Message-Id: <200004241834.NAA01622@b04a24.exu.ericsson.se>
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 24 Apr 2000 13:34:01 -0500 (CDT)
Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg),
        islepchin@dynamicsoft.com (Igor Slepchin),
        sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com (sip)
In-Reply-To: <3904871B.8B0108F1@cs.columbia.edu> from "Henning Schulzrinne" at Apr 24, 2000 01:40:43 PM
From: "Adam B. Roach" 
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Lessons learned...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

>> >Also, I agree with Igor that 408 is used when a proxy gives up.
>> ...
>> 
>> I have no problem with this model; it does, however, require that
>> the description of 408 be updated in RFC2543bis.
>
>Current (modified) wording is:
>
>The server could not produce a response, e.g., a user location, within
>the time indicated in the \header{Expires} request-header field.  The
>client {\MAY} repeat the request without modifications at any later
>time.
>
>Please suggest improvements.

The server could not produce a response, e.g., a user location, within
a suitable amount of time.  This may be due to the time indicated in the
\header{Expires} request-header field or by the expiration of an internal
timer in the server.  The client {\MAY} repeat the request without 
modifications at any later time.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA



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


From sip-admin@lists.bell-labs.com  Mon Apr 24 17:07: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 RAA15032
	for ; Mon, 24 Apr 2000 17:07: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 45DB544338; Mon, 24 Apr 2000 17:03:10 -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 E013A44336
	for ; Mon, 24 Apr 2000 17:03:07 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FTJ00L56HC6IF@firewall.mcit.com> for sip@lists.bell-labs.com;
 Mon, 24 Apr 2000 21:07:18 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0FTJ00G01HC5BT@pmismtp01.wcomnet.com>;
 Mon, 24 Apr 2000 21:07:18 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FTJ00EFVHBSVU@pmismtp01.wcomnet.com>; Mon,
 24 Apr 2000 21:07:05 +0000 (GMT)
Received: from wcom.com ([166.44.153.234])
 by omzmta03.mcit.com (InterMail v03.02.07 118-124-101)
 with ESMTP id <20000424210703.FITZ20964@wcom.com>; Mon,
 24 Apr 2000 21:07:03 +0000
Date: Sun, 23 Apr 2000 16:09:59 -0500
From: Alan Johnston 
Subject: Re: [SIP] INFO msg call Flows
To: "Donovan, Steven R." 
Cc: "'Sunitha Kumar'" , SIP 
Message-id: <390366A5.7C587A68@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <75C79E507864D3118AFC00805FEAB7D83493F0@ripexch001.mcit.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I had originally planned to do this but ran out of time. I will include
one in the next draft. I'd appreciate any INFO call flows that anyone
would like to contribute with message details - especially involving
PSTN interworking.

Thanks,
Alan Johnston
MCI WorldCom

Donovan, Steven R. wrote:

>  Sunitha,Given that the INFO message can only be used in the context
> of an existing session, I'm not so sure that a standalone INFO call
> flow would be very useful (much less very interesting, given that it
> would be a simple INFO, 200 ok exchange, or INFO, 481 exchange if it
> occurred outside of an existing session).It might, however, be useful
> to have a call flow that shows the use of the INFO message to carry
> mid-call signaling.This seems like a candidate for the call flow
> document. Steve
>
>      -----Original Message-----
>      From: Sunitha Kumar [mailto:skumar@vovida.com]
>      Sent: Tuesday, April 11, 2000 11:31 PM
>      To: SIPbell-labs
>      Subject: [SIP] INFO msg call Flows
>      Hi :
>
>      Are there any call flows with the INFO method, similar to
>      the ones in the call flow document.
>
>
>      Thanks!
>
>      --
>      Sunitha Kumar
>      http://www.vovida.com
>
>
>




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


From sip-admin@lists.bell-labs.com  Mon Apr 24 20:22: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 UAA18310
	for ; Mon, 24 Apr 2000 20:22: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 A3CE144338; Mon, 24 Apr 2000 20:18:03 -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 E1DBC44336
	for ; Mon, 24 Apr 2000 20:18:00 -0400 (EDT)
Received: (from shbhatna@localhost)
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id UAA00803;
	Mon, 24 Apr 2000 20:22:11 -0400 (EDT)
From: Shail Bhatnagar 
Message-Id: <200004250022.UAA00803@bounty.cisco.com>
To: sip@lists.bell-labs.com
Date: Mon, 24 Apr 2000 20:22:11 -0400 (EDT)
Cc: shbhatna@cisco.com
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] CANCEL related 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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Can someone please clarify the behavior in the following scenarios :

1) Stateful proxy server returns a final response upstream.
Now it receives a CANCEL request. Should it return a 481 response ??

2) Stateful forking proxy server returns a 200 response to INVITE upstream
and receives another 200 OK from downstream. Should it return this second
200 OK upstream or it is a configuration issue ??

3) Stateful forking proxy server is waiting for a final response on forked
"branches" and meanwhile receives a CANCEL. It returns a 200 OK upstream
and generates locally generated CANCEL requests for pending branches. Now it
receives a 200 response to original request. Should it just drop this
response ??        


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


From sip-admin@lists.bell-labs.com  Mon Apr 24 20:48:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18659
	for ; Mon, 24 Apr 2000 20:48: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 16EAC44337; Mon, 24 Apr 2000 20:43:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9797C44336
	for ; Mon, 24 Apr 2000 20:43:43 -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 UAA11394;
	Mon, 24 Apr 2000 20:49:09 -0400 (EDT)
Message-ID: <3904EAE4.F535398A@dynamicsoft.com>
Date: Mon, 24 Apr 2000 20:46:28 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Shail Bhatnagar 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Shail Bhatnagar wrote:
> 
> Can someone please clarify the behavior in the following scenarios :
> 
> 1) Stateful proxy server returns a final response upstream.
> Now it receives a CANCEL request. Should it return a 481 response ??

It may return a 481. However, it should still try to proxy the CANCEL
upstream, I believe.
 
> 2) Stateful forking proxy server returns a 200 response to INVITE upstream
> and receives another 200 OK from downstream. Should it return this second
> 200 OK upstream or it is a configuration issue ??

It should proxy the second 200 OK upstream.
 
> 3) Stateful forking proxy server is waiting for a final response on forked
> "branches" and meanwhile receives a CANCEL. It returns a 200 OK upstream
> and generates locally generated CANCEL requests for pending branches. Now it
> receives a 200 response to original request. Should it just drop this
> response ??

No way. It should proxy the 200 OK upstream (see sec 4.2.5 of
RFC2543bis).

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  Mon Apr 24 20:55: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 UAA18776
	for ; Mon, 24 Apr 2000 20:55: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 4F1EB44346; Mon, 24 Apr 2000 20:50:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E711744336
	for ; Mon, 24 Apr 2000 20:50: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 UAA11398;
	Mon, 24 Apr 2000 20:56:18 -0400 (EDT)
Message-ID: <3904EC8E.9AB22316@dynamicsoft.com>
Date: Mon, 24 Apr 2000 20:53:34 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Igor Slepchin wrote:
> 
> Shail Bhatnagar wrote:
> >
> > Can someone please clarify the behavior in the following scenarios :
> >
> > 1) Stateful proxy server returns a final response upstream.
> > Now it receives a CANCEL request. Should it return a 481 response ??
> 
> It may return a 481. However, it should still try to proxy the CANCEL
> upstream, I believe.

Oops, I meant downstream...

---
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 Apr 24 23:40:16 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23051
	for ; Mon, 24 Apr 2000 23: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 05B7844337; Mon, 24 Apr 2000 23:35:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx2.wipro.com (unknown [203.197.164.42])
	by lists.bell-labs.com (Postfix) with ESMTP id 57F8344336
	for ; Mon, 24 Apr 2000 23:35:51 -0400 (EDT)
Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50])
	by wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id LAA12740
	for ; Tue, 25 Apr 2000 11:43:22 +0530
Received: from sarovar.mail.wipro.com ([164.164.27.50])
          by m2vwall1.wipro.com (Netscape Messaging Server 3.6)  with ESMTP
          id AAAD43 for ;
          Tue, 25 Apr 2000 09:09:17 +0530
Received: from hiren ([192.168.243.67]) by sarovar.mail.wipro.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA71F;
          Tue, 25 Apr 2000 09:11:25 +0530
Message-ID: <004f01bfae67$da493ac0$43f3a8c0@hiren.wipinfo.soft.net>
From: "Hiren Shah" 
To: 
Cc: , 
Date: Tue, 25 Apr 2000 09:09:25 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004C_01BFAE95.F3E5FF80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Subject: [SIP] (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:  
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

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

Hi all
nara and Glenn cleared some of my doubts and now i can place SIP in the =
picture in an MGCP media transfer.I have another small doubt.Basically i =
am very new to SIP and  MGCP.Let me give you a very simple scenario.
You have a media gateway which just gets a media stream in analog form =
from a source connected to the media gateway .This media gateway =
transfers the media stream using MGCP and the call agent to a distant =
location where another media gateway of the same vendor is located .This =
media gateway then routes the media stream to some destination in analog =
form.This is the most simplest scenario i could think of.
I think you need to have two call agents residing near the two media =
gateways since they are geographically very far.=20
Now in the above case the vendors of the media gateway are the same and =
there is no need of any SS7 signalling as the endpoints are simple =
analog sources connected by twisted pair wires to the gateway.
Now in this case Is there any need of SIP between the two call agents ?

regards
Hiren


A Candle never  loses any of its light by lighting other Candles

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












Hi all


nara and Glenn cleared some of my doubts and now i can place SIP in =
the=20
picture in an MGCP media transfer.I have another small doubt.Basically i =
am very=20
new to SIP and  MGCP.Let me give you a very simple scenario.


You have a media gateway which just gets a media stream in analog =
form from=20
a source connected to the media gateway .This media gateway transfers =
the media=20
stream using MGCP and the call agent to a distant location where another =
media=20
gateway of the same vendor is located .This media gateway then routes =
the media=20
stream to some destination in analog form.This is the most simplest =
scenario i=20
could think of.


I think you need to have two call agents residing near the two =
media=20
gateways since they are geographically very far. 


Now in the above case the vendors of the media gateway are the same =
and=20
there is no need of any SS7 signalling as the endpoints are simple =
analog=20
sources connected by twisted pair wires to the gateway.


Now in this case Is there any need of SIP between the two call =
agents=20
?


 


regards


Hiren


 


 


A Candle never  loses any of its light by =
lighting other=20
Candles


------=_NextPart_000_004C_01BFAE95.F3E5FF80--



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


From sip-admin@lists.bell-labs.com  Tue Apr 25 01:22:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26232
	for ; Tue, 25 Apr 2000 01:21:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4D67E44337; Tue, 25 Apr 2000 01:17:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BD60844336
	for ; Tue, 25 Apr 2000 01:17:35 -0400 (EDT)
Received: from dynamicsoft.com (1Cust39.tnt3.freehold.nj.da.uu.net [63.25.172.39])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11645;
	Tue, 25 Apr 2000 01:22:47 -0400 (EDT)
Message-ID: <39052DAF.160A2CED@dynamicsoft.com>
Date: Tue, 25 Apr 2000 01:31:27 -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] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Igor Slepchin wrote:
> 
> Shail Bhatnagar wrote:
> >
> > Can someone please clarify the behavior in the following scenarios :
> >
> > 1) Stateful proxy server returns a final response upstream.
> > Now it receives a CANCEL request. Should it return a 481 response ??
> 
> It may return a 481. However, it should still try to proxy the CANCEL
> upstream, I believe.

Actually, I think the proxy will generate a 200 OK to to the CANCEL.
There was no error; the CANCEL was received for a valid transaction. 

As for proxying it upstream, if the proxy returned a final response
already, there should either be no pending branches, or a CANCEL was
already sent to cancel pending branches. In that case, there is no need
to proxy the CANCEL.

> 
> > 2) Stateful forking proxy server returns a 200 response to INVITE upstream
> > and receives another 200 OK from downstream. Should it return this second
> > 200 OK upstream or it is a configuration issue ??
> 
> It should proxy the second 200 OK upstream.

Yes. In general, a proxy should never absorb 200 OK.

> 
> > 3) Stateful forking proxy server is waiting for a final response on forked
> > "branches" and meanwhile receives a CANCEL. It returns a 200 OK upstream
> > and generates locally generated CANCEL requests for pending branches. Now it
> > receives a 200 response to original request. Should it just drop this
> > response ??
> 
> No way. It should proxy the 200 OK upstream (see sec 4.2.5 of
> RFC2543bis).

Igor is correct. Remember, CANCEL is meant to "speed up" completion of
the original request. So, after sending a CANCEL, you should still be
prepared for any set of responses you might get, just as if you had
never sent the CANCEL in the first place.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
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 Apr 25 08:58: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 IAA11358
	for ; Tue, 25 Apr 2000 08: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 C779144337; Tue, 25 Apr 2000 08:54:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx2.wipro.com (unknown [203.197.164.42])
	by lists.bell-labs.com (Postfix) with ESMTP id E27DA44336
	for ; Tue, 25 Apr 2000 08:54:11 -0400 (EDT)
Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50])
	by wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id VAA32156
	for ; Tue, 25 Apr 2000 21:01:34 +0530
Received: from sarovar.mail.wipro.com ([164.164.27.50])
          by m2vwall1.wipro.com (Netscape Messaging Server 3.6)  with ESMTP
          id AAA131F for ;
          Tue, 25 Apr 2000 18:27:08 +0530
Received: from hiren ([192.168.243.67]) by sarovar.mail.wipro.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA19D
          for ; Tue, 25 Apr 2000 18:29:18 +0530
Message-ID: <009d01bfaeb5$cc359340$43f3a8c0@hiren.wipinfo.soft.net>
From: "Hiren Shah" 
To: 
Date: Tue, 25 Apr 2000 18:27:22 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Subject: [SIP] SIP/MGCP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi all
nara and hemant have really cleared my doubts regarding the use of SIP in
MGCP
protocol.Thanks a lot.
This is a bit off the line but can anyone direct me to a MGCP discussion
forum.
Basically i am doing some research in MGCP and SIP.

regards
Hiren






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


From sip-admin@lists.bell-labs.com  Tue Apr 25 09:14: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 JAA11848
	for ; Tue, 25 Apr 2000 09:14: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 AA99A4434A; Tue, 25 Apr 2000 09:10:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 1445644346
	for ; Tue, 25 Apr 2000 09:10:00 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprich.nortel.com; Tue, 25 Apr 2000 08:11:56 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id ; Tue, 25 Apr 2000 08:10:45 -0500
Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C36E8@zcard00q.ca.nortel.com>
From: "Peter Blatherwick" 
To: "'hiren.shah@wipro.com'" ,
        sip 
Subject: RE: [SIP] SIP/MGCP
Date: Tue, 25 Apr 2000 08:10:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAEB7.A9D2F048"
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:  
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_01BFAEB7.A9D2F048
Content-Type: text/plain;
	charset="iso-8859-1"

Hiren:

Please join the Megaco WG discussion, since that is the IETF Standards Track
direction for gateway control.  Megaco/H.248 Protocol is the international
standard in this area, a joint effort between IETF Megaco and ITU SG-16.  

WG Charter, list instructions etc can be found at:
http://www.ietf.org/html.charters/megaco-charter.html

E-mail list archive is at:
http://standards.nortelnetworks.com/archives/megaco.html

Regards,
Peter Blatherwick


-----Original Message-----
From: hiren.shah@wipro.com [mailto:hiren.shah@wipro.com]
Sent: Tuesday, April 25, 2000 08:57
To: sip
Subject: [SIP] SIP/MGCP


Hi all
nara and hemant have really cleared my doubts regarding the use of SIP in
MGCP
protocol.Thanks a lot.
This is a bit off the line but can anyone direct me to a MGCP discussion
forum.
Basically i am doing some research in MGCP and SIP.

regards
Hiren






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

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






RE: [SIP] SIP/MGCP




Hiren:




Please join the Megaco WG discussion, =
since that is the IETF Standards Track direction for gateway control.  Megaco/H.248 Protocol is the international standard in =
this area, a joint effort between IETF Megaco and ITU =
SG-16.  



WG Charter, list instructions etc can =
be found at:

http://www.ietf.org/html.charters/megaco-charter.html<=
/A>




E-mail list archive is at:

http://standards.nortelnetworks.com/archives/megaco.ht=
ml




Regards,

Peter Blatherwick






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

From: hiren.shah@wipro.com [mailto:hiren.shah@wipro.com]

Sent: Tuesday, April 25, 2000 =
08:57

To: sip

Subject: [SIP] SIP/MGCP






Hi all

nara and hemant have really cleared =
my doubts regarding the use of SIP in

MGCP

protocol.Thanks a lot.

This is a bit off the line but can =
anyone direct me to a MGCP discussion

forum.

Basically i am doing some research in =
MGCP and SIP.




regards

Hiren














_______________________________________________

SIP mailing list

SIP@lists.bell-labs.com

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





------_=_NextPart_001_01BFAEB7.A9D2F048--


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 09: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 JAA12206
	for ; Tue, 25 Apr 2000 09:34: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 809DD44356; Tue, 25 Apr 2000 09:29:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 860E244336
	for ; Tue, 25 Apr 2000 09:29:37 -0400 (EDT)
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA11532;
	Tue, 25 Apr 2000 09:32:30 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA06293;
	Tue, 25 Apr 2000 09:32:31 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <2MSF6KKK>; Tue, 25 Apr 2000 09:27:08 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF678203@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Hiren Shah'" , sip@lists.bell-labs.com
Cc: mjh@aciri.org, nara@syndeocorp.com
Subject: RE: [SIP] (no subject)
Date: Tue, 25 Apr 2000 09:32:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFAEB9.F3E7E24A"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFAEB9.F3E7E24A
Content-Type: text/plain;
	charset="iso-8859-1"

If you need two call agents, then they must communicate.  What protocol
would you choose?
 
If the call agents come from one vendor, then they may of course use a
proprietary protocol.
However, the network operator may wish to have the CAs use a standard
protocol.  There are
several choices - ISUP/SS7 is one choice, especially the Q.BICC variant.
H.323 is another
choice.  SIP is yet another choice.  
 
You started out assuming you wanted a Media Gateway/Media Gateway Controller
architecture.
That may be very appropriate for some kinds of gateways, but "intelligent"
devices may be
more appropriate for other kinds of endpoints.  Complex systems may have
both kinds in the network.  One of the nice characteristics of sip is that
you can build quite simple UAs, or
quite complex UA/Server combinations.  This is less true of some other
protocol choices.
 
One other statement you made bothers me  you implied that the distance
between the gateways
was the reason you needed two call agents.  This should not be true -
distance is not an important
factor in deciding what Call Agent should control what Gateways.  Such
decisions may take into
account administrative boundaries, network bandwidth, CA capacity, and
network topology.
In a simple case as you describe, one CA may be very appropriate.  
 
Brian
 
 

-----Original Message-----
From: Hiren Shah [mailto:hiren.shah@wipro.com]
Sent: Monday, April 24, 2000 11:39 PM
To: sip@lists.bell-labs.com
Cc: mjh@aciri.org; nara@syndeocorp.com
Subject: [SIP] (no subject)


Hi all
nara and Glenn cleared some of my doubts and now i can place SIP in the
picture in an MGCP media transfer.I have another small doubt.Basically i am
very new to SIP and  MGCP.Let me give you a very simple scenario.
You have a media gateway which just gets a media stream in analog form from
a source connected to the media gateway .This media gateway transfers the
media stream using MGCP and the call agent to a distant location where
another media gateway of the same vendor is located .This media gateway then
routes the media stream to some destination in analog form.This is the most
simplest scenario i could think of.
I think you need to have two call agents residing near the two media
gateways since they are geographically very far. 
Now in the above case the vendors of the media gateway are the same and
there is no need of any SS7 signalling as the endpoints are simple analog
sources connected by twisted pair wires to the gateway.
Now in this case Is there any need of SIP between the two call agents ?
 
regards
Hiren
 
 
A Candle never  loses any of its light by lighting other Candles


------_=_NextPart_001_01BFAEB9.F3E7E24A
Content-Type: text/html;
	charset="iso-8859-1"












If you 
need two call agents, then they must communicate.  What protocol would you 
choose?


 


If the 
call agents come from one vendor, then they may of course use a proprietary 
protocol.


However, the network operator may wish to have the CAs 
use a standard protocol.  There are


several choices - ISUP/SS7 is one choice, especially 
the Q.BICC variant.  H.323 is another


choice.  SIP is yet another choice.  



 


You 
started out assuming you wanted a Media Gateway/Media Gateway Controller 
architecture.


That 
may be very appropriate for some kinds of gateways, but "intelligent" devices 
may be


more 
appropriate for other kinds of endpoints.  Complex systems may have both 
kinds in the network.  One of the nice characteristics of sip is that you 
can build quite simple UAs, or


quite 
complex UA/Server combinations.  This is less true of some other protocol 
choices.


 


One 
other statement you made bothers me  you implied that the distance between 
the gateways


was 
the reason you needed two call agents.  This should not be true - distance 
is not an important


factor 
in deciding what Call Agent should control what Gateways.  Such decisions 
may take into


account administrative boundaries, network bandwidth, 
CA capacity, and network topology.


In a 
simple case as you describe, one CA may be very appropriate.  



 


Brian


 


 



  
-----Original Message-----
From: Hiren Shah 
  [mailto:hiren.shah@wipro.com]
Sent: Monday, April 24, 2000 11:39 
  PM
To: sip@lists.bell-labs.com
Cc: mjh@aciri.org; 
  nara@syndeocorp.com
Subject: [SIP] (no subject)


  
Hi all

  
nara and Glenn cleared some of my doubts and now i can place SIP in the 
  picture in an MGCP media transfer.I have another small doubt.Basically i am 
  very new to SIP and  MGCP.Let me give you a very simple scenario.

  
You have a media gateway which just gets a media stream in analog form 
  from a source connected to the media gateway .This media gateway transfers the 
  media stream using MGCP and the call agent to a distant location where another 
  media gateway of the same vendor is located .This media gateway then routes 
  the media stream to some destination in analog form.This is the most simplest 
  scenario i could think of.

  
I think you need to have two call agents residing near the two media 
  gateways since they are geographically very far. 

  
Now in the above case the vendors of the media gateway are the same and 
  there is no need of any SS7 signalling as the endpoints are simple analog 
  sources connected by twisted pair wires to the gateway.

  
Now in this case Is there any need of SIP between the two call agents 
  ?

  
 

  
regards

  
Hiren

  
 

  
 

  
A Candle never  loses any of its light by lighting 
  other Candles


------_=_NextPart_001_01BFAEB9.F3E7E24A--


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 09:46: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 JAA12382
	for ; Tue, 25 Apr 2000 09:46:19 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2659744337; Tue, 25 Apr 2000 09:41:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.alcatel.fr (mail.alcatel.fr [194.133.58.151])
	by lists.bell-labs.com (Postfix) with ESMTP id 5A98544336
	for ; Tue, 25 Apr 2000 03:57:59 -0400 (EDT)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mailgate.alcatel.fr (ALCANET/SMTP) with ESMTP id IAA28947
        for ; Tue, 25 Apr 2000 08:54:54 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA27332
        for ; Tue, 25 Apr 2000 10:02:10 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA01359
	for ; Tue, 25 Apr 2000 10:02:12 +0200 (MET DST)
Received: from young.dinsunnet (young [188.9.34.36])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id KAA11077
	for ; Tue, 25 Apr 2000 10:02:11 +0200 (MET DST)
Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4)
	id KAA12554; Tue, 25 Apr 2000 10:02:11 +0200 (MET DST)
Message-ID: <39055103.B543C50E@ms.alcatel.fr>
Date: Tue, 25 Apr 2000 10:02:11 +0200
From: Francois-Xavier Guitton 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP 
Subject: [SIP] Status of Also and Requested-By header fields
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

All,

Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony Call
Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed Multipoint
Conferences using SIP) use the Also and Requested-By header fields to
allow conferencing features. But I did not find out where these fields
are specified. Even in the last RFC2543bis (April 2000) these fields are
not described.

Can someone tell me which document specifies these header fields ?

Regards,


Francois-Xavier Guitton
ALCATEL Corporate Research Center

mailto:Francois-Xavier.Guitton@ms.alcatel.fr




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


From sip-admin@lists.bell-labs.com  Tue Apr 25 09: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 JAA12420
	for ; Tue, 25 Apr 2000 09: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 3738344354; Tue, 25 Apr 2000 09:41:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by lists.bell-labs.com (Postfix) with ESMTP id 65BA344352
	for ; Tue, 25 Apr 2000 09:41:21 -0400 (EDT)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA27450;
        Tue, 25 Apr 2000 15:41:49 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA09788;
        Tue, 25 Apr 2000 15:45:08 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA23501;
	Tue, 25 Apr 2000 15:44:56 +0200 (MET DST)
Received: from young.dinsunnet (young [188.9.34.36])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA17568;
	Tue, 25 Apr 2000 15:43:53 +0200 (MET DST)
Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4)
	id PAA12683; Tue, 25 Apr 2000 15:43:53 +0200 (MET DST)
Message-ID: <3905A119.AB248267@ms.alcatel.fr>
Date: Tue, 25 Apr 2000 15:43:53 +0200
From: Francois-Xavier Guitton 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP 
Subject: [SIP] Status of Also and Requested-By header fields
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

All,

Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony Call
Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed Multipoint
Conferences using SIP) use the Also and Requested-By header fields to
allow conferencing features. But I did not find out where these fields
are specified. Even in the last RFC2543bis (April 2000) these fields are
not described.

Can someone tell me which document specifies these header fields ?

Regards,


Francois-Xavier Guitton
ALCATEL Corporate Research Center

mailto:Francois-Xavier.Guitton@ms.alcatel.fr


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 10:09: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 KAA12898
	for ; Tue, 25 Apr 2000 10:09: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 72DDF4434D; Tue, 25 Apr 2000 10:05:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 32C7344336
	for ; Tue, 25 Apr 2000 10:05:02 -0400 (EDT)
Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA12327;
	Tue, 25 Apr 2000 10:10:32 -0400 (EDT)
Message-ID: <3905A963.D9650F47@dynamicsoft.com>
Date: Tue, 25 Apr 2000 10:19:15 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois-Xavier Guitton 
Cc: SIP 
Subject: Re: [SIP] Status of Also and Requested-By header fields
References: <3905A119.AB248267@ms.alcatel.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

These fields were defined in the original call control draft:
http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sip-cc-01.txt

which has now expired. The group decided that the scope of this was too
large, and so has decided to attack the problem differently. Transfer is
split out, and is now described in:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-cc-transfer-00.txt

a new draft on distributed multiparty conferencing is pending.

-Jonathan R.

Francois-Xavier Guitton wrote:
> 
> All,
> 
> Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony Call
> Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed Multipoint
> Conferences using SIP) use the Also and Requested-By header fields to
> allow conferencing features. But I did not find out where these fields
> are specified. Even in the last RFC2543bis (April 2000) these fields are
> not described.
> 
> Can someone tell me which document specifies these header fields ?
> 
> Regards,
> 
> Francois-Xavier Guitton
> ALCATEL Corporate Research Center
> 
> mailto:Francois-Xavier.Guitton@ms.alcatel.fr
> 
> _______________________________________________
> 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:   (732) 741-4778
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 Apr 25 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 LAA17880
	for ; Tue, 25 Apr 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 F383944337; Tue, 25 Apr 2000 11:49:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by lists.bell-labs.com (Postfix) with ESMTP id AC37A44336
	for ; Tue, 25 Apr 2000 11:46:34 -0400 (EDT)
Received: from intervoice-brite.com ([172.16.16.64])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id KAA06537
	for ; Tue, 25 Apr 2000 10:52:57 -0500
Received: from INTERVOICE-Message_Server by intervoice-brite.com
	with Novell_GroupWise; Tue, 25 Apr 2000 10:50:48 -0500
Message-Id: 
X-Mailer: Novell GroupWise 5.2
Date: Tue, 25 Apr 2000 10:50:38 -0500
From: "Viral Bharatia" 
To: brosen@fore.com, sip@lists.bell-labs.com, hiren.shah@wipro.com
Cc: mjh@aciri.org, nara@syndeocorp.com
Subject: Re: RE: [SIP] (no subject)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17880

Softswitches run into a similar issue and SIP BCP-T is used for inter softswitch communication. One advantage of using SIP BCP-T is that it allows intelligent terminals to hook up with the network elements and have control of the call which is vital for providing enhanced services. Moreover, for intelligent services, you need to be able to exchange information during the call - esp. DTMF. 

The following draft addresses "in-call" event notification issues like DTMF notification:

http://www.ietf.org/internet-drafts/draft-culpepper-sip-info-event-00.txt

- Viral

Viral Bharatia
Intervoice-Brite

>>> "Rosen, Brian"  04/25 8:32 AM >>>
If you need two call agents, then they must communicate.  What protocol
would you choose?
 
If the call agents come from one vendor, then they may of course use a
proprietary protocol.
However, the network operator may wish to have the CAs use a standard
protocol.  There are
several choices - ISUP/SS7 is one choice, especially the Q.BICC variant.
H.323 is another
choice.  SIP is yet another choice.  
 
You started out assuming you wanted a Media Gateway/Media Gateway Controller
architecture.
That may be very appropriate for some kinds of gateways, but "intelligent"
devices may be
more appropriate for other kinds of endpoints.  Complex systems may have
both kinds in the network.  One of the nice characteristics of sip is that
you can build quite simple UAs, or
quite complex UA/Server combinations.  This is less true of some other
protocol choices.
 
One other statement you made bothers me  you implied that the distance
between the gateways
was the reason you needed two call agents.  This should not be true -
distance is not an important
factor in deciding what Call Agent should control what Gateways.  Such
decisions may take into
account administrative boundaries, network bandwidth, CA capacity, and
network topology.
In a simple case as you describe, one CA may be very appropriate.  
 
Brian
 
 

-----Original Message-----
From: Hiren Shah [mailto:hiren.shah@wipro.com] 
Sent: Monday, April 24, 2000 11:39 PM
To: sip@lists.bell-labs.com 
Cc: mjh@aciri.org; nara@syndeocorp.com 
Subject: [SIP] (no subject)


Hi all
nara and Glenn cleared some of my doubts and now i can place SIP in the
picture in an MGCP media transfer.I have another small doubt.Basically i am
very new to SIP and  MGCP.Let me give you a very simple scenario.
You have a media gateway which just gets a media stream in analog form from
a source connected to the media gateway .This media gateway transfers the
media stream using MGCP and the call agent to a distant location where
another media gateway of the same vendor is located .This media gateway then
routes the media stream to some destination in analog form.This is the most
simplest scenario i could think of.
I think you need to have two call agents residing near the two media
gateways since they are geographically very far. 
Now in the above case the vendors of the media gateway are the same and
there is no need of any SS7 signalling as the endpoints are simple analog
sources connected by twisted pair wires to the gateway.
Now in this case Is there any need of SIP between the two call agents ?
 
regards
Hiren
 
 
A Candle never  loses any of its light by lighting other Candles




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


From sip-admin@lists.bell-labs.com  Tue Apr 25 12:03:43 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18173
	for ; Tue, 25 Apr 2000 12:03: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 734AA44351; Tue, 25 Apr 2000 11:59:13 -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 0FCB344346
	for ; Tue, 25 Apr 2000 11:59:11 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02894;
	Tue, 25 Apr 2000 10:03:20 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA07257;
	Tue, 25 Apr 2000 09:02:25 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA03076;
	Tue, 25 Apr 2000 09:02:24 -0700 (PDT)
Message-Id: <200004251602.JAA03076@nasnfs.eng.sun.com>
Date: Tue, 25 Apr 2000 09:04:57 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
To: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com
Cc: mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rnrqCEclktBCCIyyjj7pyQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Subject: [SIP] SIP and network element signalling (formerly: (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:  
X-BeenThere: sip@lists.bell-labs.com


>If you need two call agents, then they must communicate.  What protocol
>would you choose?
> 
>If the call agents come from one vendor, then they may of course use a
>proprietary protocol.
>However, the network operator may wish to have the CAs use a standard
>protocol.  There are
>several choices - ISUP/SS7 is one choice, especially the Q.BICC variant.
>H.323 is another
>choice.  SIP is yet another choice.  
> 

SIP is the Session *Initiation* Protocol, it was not originally
intended for signalling between network elements outside of the
context of setting up a multimedia session. ISUP/SS7 is awkward in
an all-IP network, I`m not all that familiar with H.323.

>You started out assuming you wanted a Media Gateway/Media Gateway Controller
>architecture.
>That may be very appropriate for some kinds of gateways, but "intelligent"
>devices may be
>more appropriate for other kinds of endpoints.  Complex systems may have
>both kinds in the network.  One of the nice characteristics of sip is that
>you can build quite simple UAs, or
>quite complex UA/Server combinations.  This is less true of some other
>protocol choices.
> 

My understanding is that Megaco is primarily for "dumb"
endpoints, and SIP is for "smart" endpoints. 

This discussion brings up an issue that I'm encountering in my work
with 3rd generation cellular systems. There is need for a signalling
protocol between network elements, like SIP proxies as call agents
or a SIP proxy/call agent and a "smart" IP-based cell phone, outside
of the context of setting up a multimedia session. An example in
the cell phone world is paging to determine whether a cell phone
happens to be in a particular service area. Or having an
intelligent IP cell phone retrieve authentication credentials from 
a proxy, so it can authenticate incoming INVITEs, before any
call is in progress.

There are ways that one could force these situations into a SIP
context, like setting up a multimedia session to perform the operation,
then using a SIP INFO method to transfer the data or perform the
operation, but these seem somewhat forced, like a hack. Despite this, some
people are forging ahead with this anyway due to lack of a better solution. 
Megaco doesn't seem like the right solution either, if its intended use 
primarily covers controlling media gateways for "dumb" devices. Most cell phones 
these days are pretty intelligent, and since 3GPP has decided to standardize on 
SIP for a future all-IP cell phone, cell phones are likely to become even more 
intelligent as they move to using IP for signalling and voice services as well
as for data.

So the question is what to do? Should these functions simply be left to
proprietary protocols? Is there need for another protocol that is 
specifically designed for signalling between network elements, like
proxies, to cover these cases? Or should SIP be somehow expanded
to cover them? 

My opinion is that proprietary protocols are not appropriate, since
most of these functions are covered by standardized protocols in
the current SS7 based network, so this would be a step backwards.
Since I generally like to keep protocols well focussed and therefore
hopefully simple, expanding out SIP to handle these cases seems 
fraught with potential featurization peril. On the other hand,
it is unclear to me whether there are enough cases to cover
having a new protocol.

Comments?

Maybe this isn't the right list to explore this issue (if so, please
tell me to get lost)?

		jak

		




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


From sip-admin@lists.bell-labs.com  Tue Apr 25 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 MAA18559
	for ; Tue, 25 Apr 2000 12:15:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5983944359; Tue, 25 Apr 2000 12:10:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id C5E6744357
	for ; Tue, 25 Apr 2000 12:10:38 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA20795;
	Tue, 25 Apr 2000 12:08:57 -0400 (EDT)
Message-ID: <3905C319.7C5D83C3@cs.columbia.edu>
Date: Tue, 25 Apr 2000 12:08: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: James Kempf 
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004251602.JAA03076@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

It might be helpful to describe those things that are different for
"network element" signaling and what information needs to be conveyed. I
don't see (yet) why this needs to be a hack, but I would stay away from
"let's just use the INFO hammer" approach.

I wouldn't read too much into a protocol name. This is more of a
historical accident than a political platform. As far as I can tell, SIP
should be able to handle the tasks typically done by signaling
protocols. It is not a multimedia transport protocol such as RTP or a
replacement for email or ftp.
-- 
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 Apr 25 12:53: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 MAA19572
	for ; Tue, 25 Apr 2000 12:53: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 40F1E44337; Tue, 25 Apr 2000 12:49:02 -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 8C41944336
	for ; Tue, 25 Apr 2000 12:48:59 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28282;
	Tue, 25 Apr 2000 10:50:01 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA15366;
	Tue, 25 Apr 2000 09:32:46 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA03455;
	Tue, 25 Apr 2000 09:32:45 -0700 (PDT)
Message-Id: <200004251632.JAA03455@nasnfs.eng.sun.com>
Date: Tue, 25 Apr 2000 09:35:18 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
To: James.Kempf@eng.sun.com, schulzrinne@cs.columbia.edu
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: oS8bsxVisQk9Sd54NWqRQg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

>
>It might be helpful to describe those things that are different for
>"network element" signaling and what information needs to be conveyed. I
>don't see (yet) why this needs to be a hack, but I would stay away from
>"let's just use the INFO hammer" approach.
>

The particular ones I've encountered so far in my work with IS-41 are:

1) Paging a cell phone that currently doesn't have an ongoing call
and might even be in standby mode.

2) Having an IP-based phone obtain authentication credentials from a network 
authentication server, which may also function as a SIP proxy/call agent, to
allow the IP-based cell phone to authenticate INVITEs as having
come from a valid source.

3) Allowing the call agent to request a list of features (tones
and announcements) from its home service database for delivery to the mobile 
terminal (FeatureRequest in IS-41). Athough this message would most likely be 
encountered during setup or execution of a call (when the INFO method could be
used), it may occur outside of that context and it will require communication 
between two network elements, one of which (the home service database) is not 
involved in routing the call.

There are likely to be others. 

>I wouldn't read too much into a protocol name. This is more of a
>historical accident than a political platform. As far as I can tell, SIP
>should be able to handle the tasks typically done by signaling
>protocols. It is not a multimedia transport protocol such as RTP or a
>replacement for email or ftp.

Using SIP or enhancing it if necessary is certainly an attractive option.
I'm a bit concerned that the INFO method might become a catchall, in
which people start dumping in signalling information in a uncoordinated
manner. 

Perhaps an auxillary protocol, like, SDP for the INFO method would work,
along with opening up the use of INFO between network elements when
a call is not in progress (currently it is only defined for when
a call is in progress).

		jak





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


From sip-admin@lists.bell-labs.com  Tue Apr 25 15:57: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 PAA24340
	for ; Tue, 25 Apr 2000 15:57:14 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 736BB44337; Tue, 25 Apr 2000 15:52:48 -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 AF07744336
	for ; Tue, 25 Apr 2000 15:52:45 -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 NAA07144;
	Tue, 25 Apr 2000 13:56:02 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA14822;
	Tue, 25 Apr 2000 12:55:59 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA06597;
	Tue, 25 Apr 2000 12:55:57 -0700 (PDT)
Message-Id: <200004251955.MAA06597@nasnfs.eng.sun.com>
Date: Tue, 25 Apr 2000 12:58:30 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
Subject: RE: [SIP] SIP and network element signalling (formerly: (no subje ct) )
To: James.Kempf@eng.sun.com, schulzrinne@cs.columbia.edu,
        bert.culpepper@intervoice-brite.com
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OnoTwdZ1KIItnGfuTH73yw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com


>If those of us in the telecommunications industry are going to embrace SIP
>as a signaling protocol (as it appears we have), we are going to have to
>find ways to do the things in the IP network that we've done in the
>circuit-switched network (and wireless network).  

Agreed.

>The use of the SIP INFO
>method, along with new MIME Type proposals, for ISUP and QSIG "tunneling"
>appears to be generally endorsed.  It was defined as a solution to providing
>much of the circuit-switched network functionality in a SIP network.  I may
>be wrong, but the intention of the authors of the SIP INFO ID appears to be
>for its use in solving many outstanding issues with converging the
>circuit-switched network with packet networks.
>


It's not clear that tunnelling legacy protocols is the right solution
for all IP networks, including IP to the mobile terminal. IMHO, there is
an important compatibility role for legacy protocols, but there
are other areas, authentication for example, that could benefit
from new approaches when signalling to the mobile terminal
over IP becomes possible. All IP network elements may also benefit.

>Extending (where appropriate) and using existing protocols is preferable to
>defining new ones in my opinion.  I do not want to see the INFO method
>become a catch-all though.  Obviously, more thought and work is needed to
>bring about interoperability between the two telecommunications network with
>the IP network.

Agreed.

		jak



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


From sip-admin@lists.bell-labs.com  Tue Apr 25 17: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 RAA26192
	for ; Tue, 25 Apr 2000 17: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 5D08644337; Tue, 25 Apr 2000 17:07:22 -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 C27D644336
	for ; Tue, 25 Apr 2000 17:07:19 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FTL001N1C7FWO@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 25 Apr 2000 21:11:39 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FTL00701C79RR@dgismtp01.wcomnet.com>;
 Tue, 25 Apr 2000 21:11:38 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FTL006KJC71VP@dgismtp01.wcomnet.com>; Tue,
 25 Apr 2000 21:11:25 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <29W8JR16>; Tue, 25 Apr 2000 21:11:25 +0000
Content-return: allowed
Date: Tue, 25 Apr 2000 21:11:22 +0000
From: "Donovan, Steven R." 
Subject: RE: [SIP] CANCEL related questions
To: "'Jonathan Rosenberg'" ,
        Igor Slepchin 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D8349429@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=iso-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

Jonathan Rosenberg wrote:
> 
> Igor Slepchin wrote:
> > 
> > Shail Bhatnagar wrote:
> > >
> > > Can someone please clarify the behavior in the following 
> scenarios :
> > >
> > > 1) Stateful proxy server returns a final response upstream.
> > > Now it receives a CANCEL request. Should it return a 481 
> response ??
> > 
> > It may return a 481. However, it should still try to proxy 
> the CANCEL
> > upstream, I believe.
> 
> Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> There was no error; the CANCEL was received for a valid transaction. 
> 

It depends on whether the proxy still has state for the transaction.  
If the proxy has "forgotten" about the transaction, then a 481 is
the appropriate response.  


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 17:17:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26261
	for ; Tue, 25 Apr 2000 17:17:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 98C6144338; Tue, 25 Apr 2000 17:12:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A50844337
	for ; Tue, 25 Apr 2000 17:12:32 -0400 (EDT)
Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14439;
	Tue, 25 Apr 2000 17:17:48 -0400 (EDT)
Message-ID: <39060D84.BCF935B2@dynamicsoft.com>
Date: Tue, 25 Apr 2000 17: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: "Donovan, Steven R." 
Cc: Igor Slepchin ,
        Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <75C79E507864D3118AFC00805FEAB7D8349429@ripexch001.mcit.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Donovan, Steven R." wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Igor Slepchin wrote:
> > >
> > > Shail Bhatnagar wrote:
> > > >
> > > > Can someone please clarify the behavior in the following
> > scenarios :
> > > >
> > > > 1) Stateful proxy server returns a final response upstream.
> > > > Now it receives a CANCEL request. Should it return a 481
> > response ??
> > >
> > > It may return a 481. However, it should still try to proxy
> > the CANCEL
> > > upstream, I believe.
> >
> > Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> > There was no error; the CANCEL was received for a valid transaction.
> >
> 
> It depends on whether the proxy still has state for the transaction.
> If the proxy has "forgotten" about the transaction, then a 481 is
> the appropriate response.

I don't think thats the right behavior. In this case, I think the proxy
should actually proxy the CANCEL, as any other request. Consider this
scenario. A UAC sends an INVITE, goes through a proxy, goes to UAS, 100
comes back. The UAC lets the phone ring for a long time. At some point,
the proxy gives up and destroys transaction state (note that it may have
been stateless to begin with). Now, the UAC finally decides to CANCEL.
So, it sends a CANCEL, and this arrives to the proxy. There is
definitely a value in proxying this CANCEL so that it can cause the
request to be cancelled at the UAS. 

Since the correct behavior of a stateless proxy is to forward all
CANCELs, it makes sense that the default behavior of a stateful proxy
which forgot its state should be the same - proxy the CANCEL.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 17:20: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 RAA26342
	for ; Tue, 25 Apr 2000 17:20: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 0A4E14435F; Tue, 25 Apr 2000 17:16:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 81D8144338
	for ; Tue, 25 Apr 2000 17:15: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 RAA14451;
	Tue, 25 Apr 2000 17:21:30 -0400 (EDT)
Message-ID: <39060BAC.A2630606@dynamicsoft.com>
Date: Tue, 25 Apr 2000 17:18:36 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Donovan, Steven R." 
Cc: "'Jonathan Rosenberg'" ,
        Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <75C79E507864D3118AFC00805FEAB7D8349429@ripexch001.mcit.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

"Donovan, Steven R." wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Igor Slepchin wrote:
> > >
> > > Shail Bhatnagar wrote:
> > > > 1) Stateful proxy server returns a final response upstream.
> > > > Now it receives a CANCEL request. Should it return a 481
> > response ??
> > >
> > > It may return a 481. However, it should still try to proxy
> > the CANCEL
> > > upstream, I believe.
> >
> > Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> > There was no error; the CANCEL was received for a valid transaction.
> >
> 
> It depends on whether the proxy still has state for the transaction.
> If the proxy has "forgotten" about the transaction, then a 481 is
> the appropriate response.

Actually, I still think that it might be appropriate for the proxy to
return a 4xx response when it receives a CANCEL for the transaction in a
state where it shouldn't receive any save for a race condition. Not that
this makes any difference...

Also note that if the proxy has forgotten about the transaction, it
needs to forward the CANCEL after returning the 481 (and yes, I was
wrong on this in my first reply).

---
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 Apr 25 17:29: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 RAA26490
	for ; Tue, 25 Apr 2000 17:29: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 11ECA4435F; Tue, 25 Apr 2000 17:25:28 -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 E76A944357
	for ; Tue, 25 Apr 2000 17:25:24 -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 RAA16081;
	Tue, 25 Apr 2000 17:27:00 -0400 (EDT)
Message-ID: <39060DA4.F91B30CE@cisco.com>
Date: Tue, 25 Apr 2000 17:27:00 -0400
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Igor Slepchin , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Thanks for responses. One more related question. Let us consider the following
scenario :

1) INVITE from UA to proxy 
2) 100 from proxy to UA and INVITE from proxy to next hop server
3) CANCEL from UA to proxy and CANCEL from proxy to next hop server
4) Proxy gets a duplicate copy of INVITE and returns 487 response
5) Proxy gets a 200 response to INVITE and forwards it upstream. This
creates a messy state at the UA. Is this acceptable ??

Thanks,
Shail

Jonathan Rosenberg wrote:
> 
> Igor Slepchin wrote:
> >
> > Shail Bhatnagar wrote:
> > >
> > > Can someone please clarify the behavior in the following scenarios :
> > >
> > > 1) Stateful proxy server returns a final response upstream.
> > > Now it receives a CANCEL request. Should it return a 481 response ??
> >
> > It may return a 481. However, it should still try to proxy the CANCEL
> > upstream, I believe.
> 
> Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> There was no error; the CANCEL was received for a valid transaction.
> 
> As for proxying it upstream, if the proxy returned a final response
> already, there should either be no pending branches, or a CANCEL was
> already sent to cancel pending branches. In that case, there is no need
> to proxy the CANCEL.
> 
> >
> > > 2) Stateful forking proxy server returns a 200 response to INVITE upstream
> > > and receives another 200 OK from downstream. Should it return this second
> > > 200 OK upstream or it is a configuration issue ??
> >
> > It should proxy the second 200 OK upstream.
> 
> Yes. In general, a proxy should never absorb 200 OK.
> 
> >
> > > 3) Stateful forking proxy server is waiting for a final response on forked
> > > "branches" and meanwhile receives a CANCEL. It returns a 200 OK upstream
> > > and generates locally generated CANCEL requests for pending branches. Now it
> > > receives a 200 response to original request. Should it just drop this
> > > response ??
> >
> > No way. It should proxy the 200 OK upstream (see sec 4.2.5 of
> > RFC2543bis).
> 
> Igor is correct. Remember, CANCEL is meant to "speed up" completion of
> the original request. So, after sending a CANCEL, you should still be
> prepared for any set of responses you might get, just as if you had
> never sent the CANCEL in the first place.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> 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 Apr 25 17:36: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 RAA26782
	for ; Tue, 25 Apr 2000 17:36: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 EB6FD44369; Tue, 25 Apr 2000 17:32:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8026E44368
	for ; Tue, 25 Apr 2000 17:32:04 -0400 (EDT)
Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14506;
	Tue, 25 Apr 2000 17:37:35 -0400 (EDT)
Message-ID: <39061227.F260A7C0@dynamicsoft.com>
Date: Tue, 25 Apr 2000 17:46:15 -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: Igor Slepchin , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@dynamicsoft.com> <39060DA4.F91B30CE@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Shail Bhatnagar wrote:
> 
> Thanks for responses. One more related question. Let us consider the following
> scenario :
> 
> 1) INVITE from UA to proxy
> 2) 100 from proxy to UA and INVITE from proxy to next hop server
> 3) CANCEL from UA to proxy and CANCEL from proxy to next hop server
> 4) Proxy gets a duplicate copy of INVITE and returns 487 response

Why would it do this? The proxy should not generate the response to the
INVITE, it should wait for a response. Remember - the point of the
CANCEL is to speed up the return of a response from the UAS. The reason
you really don't want to generate one yourself like this is exactly the
case in step 5 below.

> 5) Proxy gets a 200 response to INVITE and forwards it upstream. This
> creates a messy state at the UA. Is this acceptable ??

No.

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


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 17:40:31 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26895
	for ; Tue, 25 Apr 2000 17:40:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DA16D44355; Tue, 25 Apr 2000 17:35:59 -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 A433844336
	for ; Tue, 25 Apr 2000 17:35:56 -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 RAA16985;
	Tue, 25 Apr 2000 17:40:11 -0400 (EDT)
Message-ID: <390610BB.AC6685C9@cisco.com>
Date: Tue, 25 Apr 2000 17:40:11 -0400
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Igor Slepchin , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@dynamicsoft.com> <39060DA4.F91B30CE@cisco.com> <39061227.F260A7C0@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

> 
> Why would it do this? The proxy should not generate the response to the
> INVITE, it should wait for a response. Remember - the point of the
> CANCEL is to speed up the return of a response from the UAS. The reason
> you really don't want to generate one yourself like this is exactly the
> case in step 5 below.
> 

Okay, so what should the proxy do with this duplicate INVITE - simply drop it
(since transaction is cancelled) or return 100 trying ??

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  Tue Apr 25 17:47: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 RAA27012
	for ; Tue, 25 Apr 2000 17:47: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 8B72944337; Tue, 25 Apr 2000 17:42:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 19BFA44336
	for ; Tue, 25 Apr 2000 17:42:38 -0400 (EDT)
Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14548;
	Tue, 25 Apr 2000 17:48:09 -0400 (EDT)
Message-ID: <390614A0.59F16F8F@dynamicsoft.com>
Date: Tue, 25 Apr 2000 17:56:48 -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: Igor Slepchin , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@dynamicsoft.com> <39060DA4.F91B30CE@cisco.com> <39061227.F260A7C0@dynamicsoft.com> <390610BB.AC6685C9@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Shail Bhatnagar wrote:
> 
> Jonathan Rosenberg wrote:
> 
> >
> > Why would it do this? The proxy should not generate the response to the
> > INVITE, it should wait for a response. Remember - the point of the
> > CANCEL is to speed up the return of a response from the UAS. The reason
> > you really don't want to generate one yourself like this is exactly the
> > case in step 5 below.
> >
> 
> Okay, so what should the proxy do with this duplicate INVITE - simply drop it
> (since transaction is cancelled) or return 100 trying ??

Do the same thing you would do if a CANCEL was never received.
Retransmit the last provisional response sent for a stateful proxy, and
proxy the INVITE for a stateless proxy.

Remember - CANCELs only act to speed up a response to the transaction.
The original transaction itself, its state is not directly affected by
CANCEL in a proxy.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Tue Apr 25 17: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 RAA27184
	for ; Tue, 25 Apr 2000 17: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 49C3C4436A; Tue, 25 Apr 2000 17:52:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C9EC844337
	for ; Tue, 25 Apr 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 RAA14612;
	Tue, 25 Apr 2000 17:57:48 -0400 (EDT)
Message-ID: <39061426.46C52BAE@dynamicsoft.com>
Date: Tue, 25 Apr 2000 17:54:46 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@dynamicsoft.com> <39060DA4.F91B30CE@cisco.com> <39061227.F260A7C0@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> >
> > 1) INVITE from UA to proxy
> > 2) 100 from proxy to UA and INVITE from proxy to next hop server
> > 3) CANCEL from UA to proxy and CANCEL from proxy to next hop server
> > 4) Proxy gets a duplicate copy of INVITE and returns 487 response
> 
> Why would it do this? The proxy should not generate the response to the
> INVITE, it should wait for a response. Remember - the point of the
> CANCEL is to speed up the return of a response from the UAS. The reason
> you really don't want to generate one yourself like this is exactly the
> case in step 5 below.
> 
> > 5) Proxy gets a 200 response to INVITE and forwards it upstream. This
> > creates a messy state at the UA. Is this acceptable ??
> 
> No.

I guess this "No" is only valid in the context of item 4 above - the
proxy erred when sending the 487 instead of waiting for one from the UAS
and created this mess. Nevertheless, the protocol still requires UAC be
prepared to receive that 200 OK.

---
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 Apr 25 22:37:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04842
	for ; Tue, 25 Apr 2000 22:37:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 49CD544337; Tue, 25 Apr 2000 22:32:44 -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 006DE44336
	for ; Tue, 25 Apr 2000 22:32:41 -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 WAA03874;
	Tue, 25 Apr 2000 22:36:09 -0400 (EDT)
Message-ID: <3906564C.9992B1E7@cs.columbia.edu>
Date: Tue, 25 Apr 2000 22:37:00 -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: James Kempf 
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004251632.JAA03455@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



James Kempf wrote:
> 
> >
> >It might be helpful to describe those things that are different for
> >"network element" signaling and what information needs to be conveyed. I
> >don't see (yet) why this needs to be a hack, but I would stay away from
> >"let's just use the INFO hammer" approach.
> >
> 
> The particular ones I've encountered so far in my work with IS-41 are:
> 
> 1) Paging a cell phone that currently doesn't have an ongoing call
> and might even be in standby mode.

Paging to initiate a call? Why is this different from an INVITE?

> 
> 2) Having an IP-based phone obtain authentication credentials from a network
> authentication server, which may also function as a SIP proxy/call agent, to
> allow the IP-based cell phone to authenticate INVITEs as having
> come from a valid source.

I assume that public key mechanisms are not acceptable?

> 
> 3) Allowing the call agent to request a list of features (tones
> and announcements) from its home service database for delivery to the mobile
> terminal (FeatureRequest in IS-41). Athough this message would most likely be
> encountered during setup or execution of a call (when the INFO method could be
> used), it may occur outside of that context and it will require communication
> between two network elements, one of which (the home service database) is not
> involved in routing the call.

Might help to define 'call agent', as I'm not sure I have the same
understanding of this term as you might. Sounds like an OPTIONS request
to me, but then I'm not sure how 'tones and announcements' fit into
this, as that sounds like media, not signaling.

> 
> There are likely to be others.
> 
> >I wouldn't read too much into a protocol name. This is more of a
> >historical accident than a political platform. As far as I can tell, SIP
> >should be able to handle the tasks typically done by signaling
> >protocols. It is not a multimedia transport protocol such as RTP or a
> >replacement for email or ftp.
> 
> Using SIP or enhancing it if necessary is certainly an attractive option.
> I'm a bit concerned that the INFO method might become a catchall, in
> which people start dumping in signalling information in a uncoordinated
> manner.

I share your concern - INFO should be used very sparingly. There is no
cost in SIP in defining new methods, for example, which allows one to
express what actually is meant rather than somehow being implied in the
body or a collection of headers.

> 
> Perhaps an auxillary protocol, like, SDP for the INFO method would work,
> along with opening up the use of INFO between network elements when
> a call is not in progress (currently it is only defined for when
> a call is in progress).
> 
>                 jak
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 26 00:45: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 AAA07894
	for ; Wed, 26 Apr 2000 00:45: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 219CB44337; Wed, 26 Apr 2000 00:41:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx2.wipro.com (unknown [203.197.164.42])
	by lists.bell-labs.com (Postfix) with ESMTP id C100444336
	for ; Wed, 26 Apr 2000 00:41:12 -0400 (EDT)
Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50])
	by wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id MAA06126
	for ; Wed, 26 Apr 2000 12:49:10 +0530
Received: from ace.wipsys.soft.net ([164.164.27.50]) by m2vwall1.wipro.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA5D5F
          for ; Wed, 26 Apr 2000 10:14:55 +0530
Received: from wipro.com ([164.164.28.228]) by ace.wipsys.soft.net
          (Netscape Messaging Server 3.6)  with ESMTP id AAA70B3
          for ; Wed, 26 Apr 2000 10:12:50 +0530
Message-ID: <390676D0.EDE178C2@wipro.com>
Date: Wed, 26 Apr 2000 10:25:44 +0530
From: "VIBHU RISHI" 
X-Mailer: Mozilla 4.7 [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] regarding the SIP url
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

hi,

in the sip draft, it is defined that we will be using the SIP URL for
addressing sip objects ( sec. 1.4.1 ). To me it looks like that the SIP
address is similar to the e-mail addresses . ( user@host ). So, why is
it that SIP address was taken as a different address. Why is it that the
e-mail address is not taken as a the sip address ?

My argument is this, since everyone will be having e-mail, the person
can use the same e-mail ids to make calls on SIP. There will be no need
to remeber another id just to make calls. Since we are looking at
convergence, we can have the mail servers act as the sip servers. 

Since I am new to SIP, my thought process might have flaws. Please feel
free to bring them to my notice :-)

vibhu..



-- 
You've got to do your own growing, no matter how tall your grandfather
was.
-Irish Proverb
---------------------------------------------------------------------
Vibhu Rishi                 e@  vibhu.rishi@wipro.com
Sr. Systems Engineer     ring@  5539134-39 ext.: 407/405		
WIPRO
Madivala I - Bangalore
---------------------------------------------------------------------


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 01:13: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 BAA09237
	for ; Wed, 26 Apr 2000 01:13: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 A704144337; Wed, 26 Apr 2000 01:09:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3472744336
	for ; Wed, 26 Apr 2000 01:09:03 -0400 (EDT)
Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA15520;
	Wed, 26 Apr 2000 01:10:46 -0400 (EDT)
Message-ID: <39067C5A.6D6F930D@dynamicsoft.com>
Date: Wed, 26 Apr 2000 01:19:22 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: VIBHU RISHI 
Cc: sip 
Subject: Re: [SIP] regarding the SIP url
References: <390676D0.EDE178C2@wipro.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



VIBHU RISHI wrote:
> 
> hi,
> 
> in the sip draft, it is defined that we will be using the SIP URL for
> addressing sip objects ( sec. 1.4.1 ). To me it looks like that the SIP
> address is similar to the e-mail addresses . ( user@host ). So, why is
> it that SIP address was taken as a different address. Why is it that the
> e-mail address is not taken as a the sip address ?

Sure, you can certainly use your email address as your SIP address. We
chose the formatting specifically to support this. Its not mandatory, of
course, so that I can have separate providers for sip and email. So, if
dynamicsoft provides both my email and sip service, my email address is
jdrosen@dynamicsoft.com and my sip URL is sip:jdrosen@dynamicsoft.com. 

> 
> My argument is this, since everyone will be having e-mail, the person
> can use the same e-mail ids to make calls on SIP. There will be no need
> to remeber another id just to make calls. Since we are looking at
> convergence, we can have the mail servers act as the sip servers.

Um, no. Just because these are the same address does not mean they are
the same server. Ideally, with SRV records deployed, there would be a
_sip._udp entry for the SIP server for each domain, likely a different
machine than the mail server.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 06:52: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 GAA22896
	for ; Wed, 26 Apr 2000 06:52: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 F011E44341; Wed, 26 Apr 2000 06:47:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173])
	by lists.bell-labs.com (Postfix) with ESMTP id C115644336
	for ; Wed, 26 Apr 2000 06:47:41 -0400 (EDT)
Received: from modem-64.antenna-lion.dialup.pol.co.uk ([62.136.223.64] helo=theseventhson.freeserve.co.uk)
	by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 12kPQG-0000yM-00
	for sip@lists.bell-labs.com; Wed, 26 Apr 2000 11:52:00 +0100
Message-ID: <3906CB2A.12DC455C@theseventhson.freeserve.co.uk>
Date: Wed, 26 Apr 2000 11:55:38 +0100
From: Benny Prijono 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Session timer comments (2)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


>From Session Timer draft dated March 2000 (page 5):

   If no 200 OK response to a refreshing re-INVITE is 
   received before the expiration of the session, the 
   UAC SHOULD send a BYE request to terminate the call. 
   It SHOULD send this BYE slightly before   expiration 
   of the session. Ten seconds is RECOMMENDED.

I believe this paragraph is intended to deal with two different issues.
First, when the re-INVITE failed, and, second when the UAC doesn't want
to send re-INVITE to refresh the timer. 

For the first issue, ie. when the re-INVITE failed, I think the UAC
should send the BYE immediately. For the second issue, i.e if the UAC
doesn't want to refresh the timer, then it should send the BYE slightly
before the expiration of the session (10 seconds recommended).

If my interpretation above correct, then that paragraph needs to be
modified because it is confusing. And also you need to change comments
in sample call flow in page 9:

   For whatever reason, the calling UA decides not 
   to refresh. So, after 120 seconds, it sends a BYE.

The correct timeout value should be 110 seconds.

-- 
cheers,
Bennylp



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


From sip-admin@lists.bell-labs.com  Wed Apr 26 08:03:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24425
	for ; Wed, 26 Apr 2000 08:03: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 8BB4944337; Wed, 26 Apr 2000 07:59: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 32CAA44336
	for ; Wed, 26 Apr 2000 07:59:17 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id NAA14951; Wed, 26 Apr 2000 13:01:47 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Sip Mail List 
Date: Wed, 26 Apr 2000 11:39:34 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00042612595802.02452@gethin>
Content-Transfer-Encoding: 8bit
Subject: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hi,

I'm querying the idea of escaped characters in Sip Url's.
This is discussed in both the rfc and bis in Section 2.

The RFC says:

"Note that reserved characters have to be
   escaped and that the "set of characters reserved within any given URI
   component is defined by that component. In general, a character is
   reserved if the semantics of the URI changes if the character is
   replaced with its escaped US-ASCII encoding" [12]."

What I am querying is the use of this escaped notation within the hostname
of the SIP-URL.

The bnf in Section 2 Figure 3 defines the hostname to consist of only alphas,
numbers and `-' characters.  It does NOT allow for escaped characters to 
exist as no `%' char is allowed.

However, the bis draft provides an example at the end of Section 2.1 as follows:

"Thus, the following URLs are equivalent:

sip:juser@%65xample.com:5060
sip:juser@ExAmPlE.CoM;Transport=UDp"

Thus we have a contradication to the bnf with the address "%65xample.com".  
It seems to me that there would be no cause to have escaped characters in the 
host name as it could never be resolved to an actual IP address.  And to have to 
revert the escaped char back to its original form is very inefficent as extra checks
will have to be made for each character to see if it is in the escaped form.  Plus the
actual escaped char may be reverted to an invalid char for a host.

The bnf does however allow escaped characters in the userinfo and header elements, 
but not in parameter values.

To summarize, as I understand it:

Escaped characters can only be used in the following elements:

1) user
2) password
3) hname
4) hvalue

and in these cases, when doing a comparison check, the escaped values MUST be
compared in their reverted (non-escaped form).

Escaped values MUST not be used in the following elements:
1) host
2) url-parameter

Please can you confirm and clarify this matter.

thanx


gethin


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 09:08:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25616
	for ; Wed, 26 Apr 2000 09:08: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 AE23544337; Wed, 26 Apr 2000 09:04: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 061CE44336
	for ; Wed, 26 Apr 2000 09:04:14 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id OAA06592; Wed, 26 Apr 2000 14:06:36 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" 
Cc: 
Subject: RE: [SIP] CANCEL related questions
Date: Wed, 26 Apr 2000 14:06:36 +0100
Message-ID: <002b01bfaf80$4092a410$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <39060D84.BCF935B2@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Bleh,

Apologies for any confusion of message attribution, or whatever, I
seem to be missing half of this thread...

Jonathan Rosenberg wrote:
>
> "Donovan, Steven R." wrote:
>
> > It depends on whether the proxy still has state for the transaction.
> > If the proxy has "forgotten" about the transaction, then a 481 is
> > the appropriate response.
> 
> I don't think thats the right behavior. In this case, I think the proxy
> should actually proxy the CANCEL, as any other request. Consider this
> scenario. A UAC sends an INVITE, goes through a proxy, goes to UAS, 100
> comes back. The UAC lets the phone ring for a long time. At some point,
> the proxy gives up and destroys transaction state (note that it may have
> been stateless to begin with). Now, the UAC finally decides to CANCEL.
> So, it sends a CANCEL, and this arrives to the proxy. There is
> definitely a value in proxying this CANCEL so that it can cause the
> request to be cancelled at the UAS. 

So, should a stateful proxy always return 200 for a CANCEL?  I'm
struggling to envisage a case where it would not.  It seems to me
that returning 481 implies confusing semantics, since the ultimate
UAS could "successfully" CANCEL the offending transaction.

> Since the correct behavior of a stateless proxy is to forward all
> CANCELs, it makes sense that the default behavior of a stateful proxy
> which forgot its state should be the same - proxy the CANCEL.

Is this stated explicitly anywhere, or is it implied by section
12.3.4 in rfc2543bis?  Therefore, should a stateless proxy initially
return a 100 for a CANCEL, as specified by section 12.4?  (Seems
pointless if we're always going to return 200...but obviously I
may be way off with the 200.)  Actually, thinking about it, isn't
the opening text of Section 12.4 --
    "The server MUST respond to the request immediately with a
     100 (Trying) response."
-- (potentially also) wrong when considering ACKs?  (Section 10.6)

To finish, can the Ten Commandments of a Stateful Proxy Behaviour,
when dealing with Requests, be summed up as:
 0) Thou shalt always attempt[0] to proxy any Request, unless it
    is a REGISTER for the local domain (or similar);
 1) Thou shalt return 100 (Trying) whilst thou proxies, unless
    the Request is an ACK;  
 2) Thou shalt obey the mighty C code in Section 12.4 of RFC 2543
    when proxying INVITEs, OPTIONSs, BYEs;
 3) Thou shalt return 200 (OK) uponst(?) seeing a CANCEL;
 4) Thou shalt not generate any Responses to ACKs;
 5) See 0;
 6) See 1;
 7) See 2;
 8) See 3;
 9) See 4.

Of course, I made it Ten just to look clever.

Am I being too simplistic?


 - Jo.

[0] Admittedly, I'm blatantly ignoring the case of an INVITE or
    REGISTER that requires authorisaction; or any semantics implied
    by, for example, a Request with a Max-Forwards value of 0.
-- 
  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 Apr 26 10:34: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 KAA27383
	for ; Wed, 26 Apr 2000 10:34: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 C185144337; Wed, 26 Apr 2000 10:30: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 7206A44336
	for ; Wed, 26 Apr 2000 10:30:06 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA19186;
	Wed, 26 Apr 2000 10:34:03 -0400 (EDT)
Message-ID: <3906FE5B.7662DD2B@cs.columbia.edu>
Date: Wed, 26 Apr 2000 10:34: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: Mauricio.Arango@eng.sun.com
Cc: James Kempf , nara@syndeocorp.com,
        brosen@fore.com, sip@lists.bell-labs.com, hiren.shah@wipro.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004261426.HAA20806@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Mauricio Arango wrote:
> 
> >>
> >> 1) Paging a cell phone that currently doesn't have an ongoing call
> >> and might even be in standby mode.
> >
> >Paging to initiate a call? Why is this different from an INVITE?
> >
> 
> Not necessarily to initiate a call but to find the location (cell) of the
> station, or obtain other station information before the call is made.
> 
> I think one of the points Jim is making is that if INVITE is used for both
> these type of queries and for initiating a call, there doesn't seem to be
> a way in SIP to tell a station or any other element to treat INVITEs used
> for different purposes in a different way. A possibility could be a SIP
> pre-call query method.

What about just using OPTIONS? It is a query method that gets routed in
the same way that other SIP requests, such as INVITE, would be.


-- 
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 Apr 26 10: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 KAA27775
	for ; Wed, 26 Apr 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 896EB44337; Wed, 26 Apr 2000 10:53:35 -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 06A3944336
	for ; Wed, 26 Apr 2000 10:53:33 -0400 (EDT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FTM00A7JPKMT0@firewall.mcit.com> for sip@lists.bell-labs.com;
 Wed, 26 Apr 2000 14:57:58 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0FTM00J01PDNQS@pmismtp04.wcomnet.com>;
 Wed, 26 Apr 2000 14:53:50 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FTM00I9CPD8P0@pmismtp04.wcomnet.com>; Wed,
 26 Apr 2000 14:53:44 +0000 (GMT)
Received: from dwillispc8 ([166.35.227.170])
 by omzmta04.mcit.com (InterMail v03.02.07.05 118-131)
 with SMTP id <20000426145728.XMEN6594@dwillispc8>; Wed,
 26 Apr 2000 14:57:28 +0000
Date: Wed, 26 Apr 2000 09:56:54 -0500
From: Dean Willis 
Subject: RE: [SIP] MGCP / SIP interaction
In-reply-to: <009101bfadba$c24187a0$43f3a8c0@hiren.wipinfo.soft.net>
To: Hiren Shah , sip@lists.bell-labs.com
Message-id: <002001bfaf8f$a947c3a0$aae323a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_+CKuIQp9eQufNt8fkDZtUw)"
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:  
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

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


If all you want to do is have two phones controlled via MGCP from the same
MGC, you don't need SIP.

I would however argue that you want to do more.

What happens if you want to talk from a device controlled by one MGC to a
device controlled by another MGC? What if those MGCs are in two different
administrative domains?

What happens if one of the end devices is NOT a stupid "slave" endpoint and
its operator doesn't want it "controlled" by a single carrier?

How do you invole value-added services provided by someone who is NOT
affiliated with your carrier in conjunction with a call that is controlled
by your carrier's MGC?

--
Dean


  -----Original Message-----
  From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Hiren Shah
  Sent: Monday, April 24, 2000 2:00 AM
  To: sip@lists.bell-labs.com
  Subject: [SIP] MGCP / SIP interaction


  Hi all

  I have a small doubt in the concept.
  Suppose MGCP protocol is used to transfer audio between two telephones
through a packet network using the call agents and media gateways.
  I have read that SIP is used between the call agent to call agent
communication in a wide network. I am failing to get the point behind
this.Please send me some justification of why SIP is required between the
communication.

  regards
  Hiren










  A Candle never  loses any of its light by lighting other Candles

--Boundary_(ID_+CKuIQp9eQufNt8fkDZtUw)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable










 


If all=20
you want to do is have two phones controlled via MGCP from the same =
MGC,=20
you don't need SIP.


 


I=20
would however argue that you want to do more.


 


What=20
happens if you want to talk from a device controlled by one MGC to a =
device=20
controlled by another MGC? What if those MGCs are in two different=20
administrative domains?


 


What=20
happens if one of the end devices is NOT a stupid "slave" endpoint and =
its=20
operator doesn't want it "controlled" by a single =
carrier?


 


How do=20
you invole value-added services provided by someone who is NOT =
affiliated with=20
your carrier in conjunction with a call that is controlled by your =
carrier's=20
MGC?


 


--


Dean


 


 


  
-----Original Message-----
From:=20
  sip-admin@lists.bell-labs.com =
[mailto:sip-admin@lists.bell-labs.com]On=20
  Behalf Of Hiren Shah
Sent: Monday, April 24, 2000 2:00=20
  AM
To: sip@lists.bell-labs.com
Subject: [SIP] MGCP =
/ SIP=20
  interaction


  
Hi all

  
 

  
I have a small doubt in the concept.

  
Suppose MGCP protocol is used to transfer audio between two =
telephones=20
  through a packet network using the call agents and media =
gateways.

  
I have read that SIP is used between the call agent to call agent =

  communication in a wide network. I am failing to get the point behind=20
  this.Please send me some justification of why SIP is required between =
the=20
  communication.

  
 

  
regards

  
Hiren

  
 

  
 

  
 

  
 

  
 

  
 

  
 

  
 

  
 

  
 

  
A Candle never  loses any of its light by lighting other=20
  Candles


--Boundary_(ID_+CKuIQp9eQufNt8fkDZtUw)--


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 11:25:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28325
	for ; Wed, 26 Apr 2000 11:25: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 2A15F44337; Wed, 26 Apr 2000 11:20:25 -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 6D48844336
	for ; Wed, 26 Apr 2000 11:20:22 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00722;
	Wed, 26 Apr 2000 09:24:05 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA22394;
	Wed, 26 Apr 2000 08:24:04 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22099;
	Wed, 26 Apr 2000 08:24:03 -0700 (PDT)
Message-Id: <200004261524.IAA22099@nasnfs.eng.sun.com>
Date: Wed, 26 Apr 2000 08:26:36 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
To: James.Kempf@eng.sun.com, schulzrinne@cs.columbia.edu
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ZlaMEwGvsY7q/fAU31PhoQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

 
>> 1) Paging a cell phone that currently doesn't have an ongoing call
>> and might even be in standby mode.
>
>Paging to initiate a call? Why is this different from an INVITE?
>

An INVITE would work if the phone was being paged to set up a call, but paging 
does not necessarily lead to a call being set up. It may be done
for administrative reasons, for example, to flush a cached service
profile if the phone is no longer in the service area. My understanding is that 
INVITE is part of a precall setup process only.

>> 
>> 2) Having an IP-based phone obtain authentication credentials from a network
>> authentication server, which may also function as a SIP proxy/call agent, to
>> allow the IP-based cell phone to authenticate INVITEs as having
>> come from a valid source.
>
>I assume that public key mechanisms are not acceptable?
>

Sure, but I'm talking about setting up the keying in the first place.
Something lightweight is needed. It may be possible to leverage
off the mobile IP keying here.

>> 
>> 3) Allowing the call agent to request a list of features (tones
>> and announcements) from its home service database for delivery to the mobile
>> terminal (FeatureRequest in IS-41). Athough this message would most likely be
>> encountered during setup or execution of a call (when the INFO method could 
be
>> used), it may occur outside of that context and it will require communication
>> between two network elements, one of which (the home service database) is not
>> involved in routing the call.
>
>Might help to define 'call agent', as I'm not sure I have the same
>understanding of this term as you might. Sounds like an OPTIONS request
>to me, but then I'm not sure how 'tones and announcements' fit into
>this, as that sounds like media, not signaling.
>

I thought that OPTIONS was only allowed in the context of either
setting up a call or an ongoing call. With regard to what the "tones
and announcents" are, that's all the IS-41 spec says about the return
value for FeatureRequest. I presume its something like the 
announcement you get when somebody's phone is off and you try to
call it. Though that is in the context of a call setup, FeatureRequest
is not restricted to an in progress call, as far as I can determine.

		jak




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


From sip-admin@lists.bell-labs.com  Wed Apr 26 12:30:02 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29521
	for ; Wed, 26 Apr 2000 12:30:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C38C44337; Wed, 26 Apr 2000 12:25:27 -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 169FE44336
	for ; Wed, 26 Apr 2000 12:25:25 -0400 (EDT)
Received: from cs.columbia.edu (dhcp5.cs.columbia.edu [128.59.19.205])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA14134;
	Wed, 26 Apr 2000 12:28:54 -0400 (EDT)
Message-ID: <39071B08.7B19F15B@cs.columbia.edu>
Date: Wed, 26 Apr 2000 12:36:24 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
Cc: schulzrinne@cs.columbia.edu, hiren.shah@wipro.com, sip@lists.bell-labs.com,
        brosen@fore.com, mjh@aciri.org, nara@syndeocorp.com,
        mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004261524.IAA22099@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> 
> I thought that OPTIONS was only allowed in the context of either
> setting up a call or an ongoing call. With regard to what the "tones
> and announcents" are, that's all the IS-41 spec says about the return
> value for FeatureRequest. I presume its something like the
> announcement you get when somebody's phone is off and you try to
> call it. Though that is in the context of a call setup, FeatureRequest
> is not restricted to an in progress call, as far as I can determine.
> 
OPTIONS is meant to be used pre-call, to find out what the other side
can do. An INVITE may follow or not. So it doesn't have to be part of a
call.


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 13:03: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 NAA00407
	for ; Wed, 26 Apr 2000 13:03: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 EDFC444337; Wed, 26 Apr 2000 12:58:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8A70344336
	for ; Wed, 26 Apr 2000 12:58: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 NAA16958;
	Wed, 26 Apr 2000 13:04:28 -0400 (EDT)
Message-ID: <390720D8.44210C96@dynamicsoft.com>
Date: Wed, 26 Apr 2000 13:01:12 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Gethin Liddell 
Cc: Sip Mail List 
Subject: Re: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
References: <00042612595802.02452@gethin>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I agree that escaping characters in host name makes little sense as that
host name wouldn't be resolvable anyway; it is explicitly disallowed by
the BNF, and the example is inconsistent with the BNF as you correctly
noted. However, I don't think the spec prohibits escaped chars in url
parameters:

other-param     = ( token | ( token "=" ( token | quoted-string )))

and BNF of token allows '%' sign (explicitly in 2543bis).

---
Igor Slepchin

Gethin Liddell wrote:
> 
> Hi,
> 
> I'm querying the idea of escaped characters in Sip Url's.
> This is discussed in both the rfc and bis in Section 2.
> 
> The RFC says:
> 
> "Note that reserved characters have to be
>    escaped and that the "set of characters reserved within any given URI
>    component is defined by that component. In general, a character is
>    reserved if the semantics of the URI changes if the character is
>    replaced with its escaped US-ASCII encoding" [12]."
> 
> What I am querying is the use of this escaped notation within the hostname
> of the SIP-URL.
> 
> The bnf in Section 2 Figure 3 defines the hostname to consist of only alphas,
> numbers and `-' characters.  It does NOT allow for escaped characters to
> exist as no `%' char is allowed.
> 
> However, the bis draft provides an example at the end of Section 2.1 as follows:
> 
> "Thus, the following URLs are equivalent:
> 
> sip:juser@%65xample.com:5060
> sip:juser@ExAmPlE.CoM;Transport=UDp"
> 
> Thus we have a contradication to the bnf with the address "%65xample.com".
> It seems to me that there would be no cause to have escaped characters in the
> host name as it could never be resolved to an actual IP address.  And to have to
> revert the escaped char back to its original form is very inefficent as extra checks
> will have to be made for each character to see if it is in the escaped form.  Plus the
> actual escaped char may be reverted to an invalid char for a host.
> 
> The bnf does however allow escaped characters in the userinfo and header elements,
> but not in parameter values.
> 
> To summarize, as I understand it:
> 
> Escaped characters can only be used in the following elements:
> 
> 1) user
> 2) password
> 3) hname
> 4) hvalue
> 
> and in these cases, when doing a comparison check, the escaped values MUST be
> compared in their reverted (non-escaped form).
> 
> Escaped values MUST not be used in the following elements:
> 1) host
> 2) url-parameter
> 
> Please can you confirm and clarify this matter.
> 
> thanx
> 
> gethin
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 26 13:35: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 NAA00941
	for ; Wed, 26 Apr 2000 13: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 1698B44337; Wed, 26 Apr 2000 13:30:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 41C8244336
	for ; Wed, 26 Apr 2000 13:30:55 -0400 (EDT)
Received: from qhars002.nortel.com (actually zhars00t) by qnsgs000.nortel.com;
          Wed, 26 Apr 2000 18:22:24 +0100
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Wed, 26 Apr 2000 17:43:56 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2650.21) id ;
          Wed, 26 Apr 2000 17:43:53 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304BEEB@nwcwi1a.europe.nortel.com>
From: "Mark Watson" 
To: sip@lists.bell-labs.com, "'Chip Sharp'" 
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
Date: Wed, 26 Apr 2000 17:43:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAF9E.99FD3006"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFAF9E.99FD3006
Content-Type: text/plain

There will defintely be a need to consider interworking between SIP(-T) and
BICC, but whether this should be done by this group or ITU-T SG11, I am not
so sure about.

I do not think we need to carry BICC inside SIP-T though. BICC is basically
ISUP with extensions for controlling an IP or ATM bearer. SIP-T can already
control IP/ATM bearers using SDP so it wouldn't make sense to carry the
extra BICC stuff as well. It should instead be interworked to the equivalent
SIP mechanism for setting up the bearer.

I expect there will be discussions on this kind of issue at the next SG11
meeting on BICC (1-5 May).

Regards,

Mark Watson
Nortel Networks, UK

> ----------
> From: 	Chip Sharp
> Sent: 	Monday, April 10, 2000 1:27 pm
> To: 	sip@lists.bell-labs.com
> Subject: 	[SIP] Carrying Q.BICC as an Mime-type in SIP
> 
> ITU (SG11) is currently defining a variant of ISUP that is being called 
> "Bearer Independent Call Control" (BICC).  I'm sure many of you are aware 
> of this.
> 
> They have completed work for Q.BICC to handle Narrowband ISDN services
> over 
> ATM (this is now numbered Q.1901) and they are now beginning work on IP
> and 
> other networks.
> 
> It seems that networks using SIP will have to interwork with these
> networks 
> as well as the current PSTN that uses ISUP.
> 
> Could (or should) this be included in the SIP-T draft?  Would it be its
> own 
> type or could/should it be included as a value for the version or spec
> field?
> 
> Chip
> http://www.netaid.org
> -------------------------------------------------------------------------
> Chip Sharp                 CTO Consulting Engineering
> Cisco Systems
> Reality - Love it or Leave it.			
> ------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

------_=_NextPart_001_01BFAF9E.99FD3006
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Carrying Q.BICC as an Mime-type in SIP




There will =
defintely be a need to consider interworking between SIP(-T) and BICC, =
but whether this should be done by this group or ITU-T SG11, I am not =
so sure about.



I do not think we =
need to carry BICC inside SIP-T though. BICC is basically ISUP with =
extensions for controlling an IP or ATM bearer. SIP-T can already =
control IP/ATM bearers using SDP so it wouldn't make sense to carry the =
extra BICC stuff as well. It should instead be interworked to the =
equivalent SIP mechanism for setting up the bearer.



I expect there will =
be discussions on this kind of issue at the next SG11 meeting on BICC =
(1-5 May).




Regards,




Mark Watson

Nortel Networks, =
UK



    

    ----------

    From:   Chip Sharp

    Sent:   Monday, April 10, 2000 1:27 pm

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

    Subject: =
       [SIP] Carrying Q.BICC as an Mime-type in SIP

    


    ITU (SG11) is currently defining a =
variant of ISUP that is being called 

    "Bearer Independent Call =
Control" (BICC).  I'm sure many of you are aware 

    of this.

    


    They have completed work for Q.BICC to =
handle Narrowband ISDN services over 

    ATM (this is now numbered Q.1901) and =
they are now beginning work on IP and 

    other networks.

    


    It seems that networks using SIP will =
have to interwork with these networks 

    as well as the current PSTN that uses =
ISUP.

    


    Could (or should) this be included in =
the SIP-T draft?  Would it be its own 

    type or could/should it be included =
as a value for the version or spec field?

    


    Chip

    http://www.netaid.org

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

    Chip =
Sharp           &=
nbsp;     CTO Consulting Engineering

    Cisco Systems

    Reality - Love it or Leave it.  =
        =
        

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

    

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFAF9E.99FD3006--


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 13:59:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01304
	for ; Wed, 26 Apr 2000 13:59: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 4C3C944337; Wed, 26 Apr 2000 13:54:31 -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 9AAE644336
	for ; Wed, 26 Apr 2000 13:54:28 -0400 (EDT)
Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id NAA09264 for sip@lists.bell-labs.com; Wed, 26 Apr 2000 13:58:52 -0400 (EDT)
From: David Daiker 
Message-Id: <200004261758.NAA09264@blanc.cisco.com>
To: sip@lists.bell-labs.com
Date: Wed, 26 Apr 2000 13:58:52 -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] Proxies enforcing UA compliance
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


I have a general question about the recommended behavior of a proxy that 
receives a non-compliant message from a UAC.

Specifically, what should a proxy do with a final response to an INVITE
that lacks a 'tag' parameter in its 'To' field.

Should it be forwarded and let the UA figure it out ?
or drop it until the callee gives up and quits re-transmitting it ?

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  Wed Apr 26 14:07:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01515
	for ; Wed, 26 Apr 2000 14:07: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 CBD4544337; Wed, 26 Apr 2000 14:02:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by lists.bell-labs.com (Postfix) with ESMTP id 1030844336
	for ; Wed, 26 Apr 2000 14:02:26 -0400 (EDT)
Received: from l3107mxr.atl.hp.com (l3107mxr.atl.hp.com [15.19.254.19])
	by palrel3.hp.com (Postfix) with ESMTP
	id 6F88517AF7; Wed, 26 Apr 2000 11:06:19 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by l3107mxr.atl.hp.com (Postfix) with ESMTP
	id F00EB4FDA0; Wed, 26 Apr 2000 14:06:16 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA01625;
	Wed, 26 Apr 2000 19:06:15 +0100 (BST)
Message-ID: <39073052.C07B022B@hplb.hpl.hp.com>
Date: Wed, 26 Apr 2000 19:07:14 +0100
From: Anders Kristensen 
Organization: HP Labs
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol
References: <200004142156.OAA25820@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi James,

It sounds to me like you're looking to use SIP for something no
appropriate methods have been defined. You'll be exploiting the
addressing, routing, reliability etc., but not the well-defined
semantics of session setup. This is a perfectly reasonable thing to do.
  
I would echo Hennings comment about the oddness of a lot of people
seemingly being uneasy about defining new methods, when in fact this is
no more work than defining new headers, and shouldn't result in any more
interoperabiblity problems - proxies are required to treat messages with
unknown methods like other requests and presumably the destination knows
about your extension method.

There are a number of ways to signal the intent of a SIP message, e.g.
  o the method
  o the Content-Type
  o the Content-Function header, possibly with some new token

To me it sounds like in your case defining new methods is definitely
clearer and cleaner than trying to use INFO, especially when there might
not even be a body that could be used to indicate intent.

Anders


James Kempf wrote:
> 
> I'm working on a design for replacing the IS-41 North American cellular
> signalling protocol with IP protocols. I had a couple of questions about
> how the SIP INFO method, or potentially another SIP method, might
> be used.
> 
> 1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange
> of radio signal strength information is explicitly mentioned as
> an application of the SIP INFO method. The HandoffMeasurementRequest
> and HandoffMeasurementRequest2 messages in IS-41 are sent by the anchor
> Mobile Switching Center (MSC) to a potential serving MSC to obtain information
> about the signal strength of a Mobile Station (MS) in order to determine
> if the potential serving MSC is a better candidate for handling the
> mobile's call (called "hard handoff" in cellular jargon). They could be
> replaced with a SIP INFO method. There are three problems:
> 
>         a) The radio information is always solicited by the anchor MSC,
>         and from the ID, the SIP INFO method seems like it is
>         sent unsolicted. I suppose one could come up with two INFO
>         methods, one to solicit the radio information and one to
>         return it, but this seems like a hack somehow.
> 
>         b) In the ID, it explicitly states that the INFO method is
>         only applicable when there is a call in progress. Problem is,
>         there isn't a call in progress between the anchor MSC and
>         the serving MSC, that's why the anchor MSC is soliciting
>         the radio quality information in the first place.
> 
>         c) The INFO method seems like it is meant to be sent between
>         SIP UAC's, while the HandoffMeasurementRequest(2) methods
>         are primarily designed to be sent between network elements.
>         A SIP replacement would probably be sent between the last hop SIP
>         proxies acting as Call Agents (CAs) for the call, which replaces
>         the MSC in an all IP network.
> 
> 2) There are a bunch of IS-41 messages that involve transmitting
> feature or other information between the MS's Home Location
> Register (HLR) and the MS. These are initiated by either the serving
> MSC or the HLR. Examples are InformationDirective, which is used
> by the HLR to provide notifications to an idle MS, and FeatureRequest,
> which sends particular features to a potentially idle MS (features
> being things like messages or playing particular tones). Again, these
> seem like candidates to replace with the SIP INFO message, but
> the potential lack of any call in progress would prohibit that.
> 
> The alternative I could see would be establishing a session in order
> to then send the information via the INFO method, but that seems like
> overkill. And in the case of HandoffMeasurementRequest(2), the
> message isn't intended for a SIP UAC anyway.
> 
> Maybe SIP is the wrong protocol to consider, since it is dedicated
> to setting up and maintaining sessions, and not to exchanging information
> between network elements or between network elements and terminals?
> 
> Can anybody provide some guidance?
> 
>                 jak
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Anders Kristensen ,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 14: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 OAA01577
	for ; Wed, 26 Apr 2000 14:12: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 D1DE144345; Wed, 26 Apr 2000 14:07:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3944944344
	for ; Wed, 26 Apr 2000 14:07:40 -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 OAA17227;
	Wed, 26 Apr 2000 14:09:33 -0400 (EDT)
Message-ID: <3907300F.2E01C5C4@dynamicsoft.com>
Date: Wed, 26 Apr 2000 14:06:07 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <002b01bfaf80$4092a410$4e34c3c1@ubiquity.co.uk>
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> So, should a stateful proxy always return 200 for a CANCEL?  I'm
> struggling to envisage a case where it would not.  It seems to me
> that returning 481 implies confusing semantics, since the ultimate
> UAS could "successfully" CANCEL the offending transaction.

It should return 481 if it doesn't know what transaction that CANCEL is
for (i.e., it has already forgotten about that transaction or received a
stray CANCEL). I thought it might also return a 481 if it received a
CANCEL for a transaction in the state where CANCEL doesn't make sense
but the spec is quite specific on this (4.2.5 in 2543bis):

A redirect or user agent server (a proxy server as well, I guess)
receiving a CANCEL request responds with a status code 200 (OK) if the
transaction exists and a status 481 (Transaction Does Not Exist) if not.

Note that the class of CANCEL response has no impact on protocol
operation.
 
> > Since the correct behavior of a stateless proxy is to forward all
> > CANCELs, it makes sense that the default behavior of a stateful proxy
> > which forgot its state should be the same - proxy the CANCEL.
> 
> Is this stated explicitly anywhere, or is it implied by section
> 12.3.4 in rfc2543bis?  

No special case is made for CANCEL and all other requests are to be
proxied, hence CANCEL is to be proxied as well. I don't think this
specific situation is described anywhere in the spec.

> Therefore, should a stateless proxy initially
> return a 100 for a CANCEL, as specified by section 12.4?  

No. From section 7.1 in 2543bis: "A server SHOULD send a 1xx response if
it expects to take more than 200 ms to obtain a final response." A
response to CANCEL is sent immediately, so there is no point in sending
a 1xx.

> To finish, can the Ten Commandments of a Stateful Proxy Behaviour,
> when dealing with Requests, be summed up as:
>  0) Thou shalt always attempt[0] to proxy any Request, unless it
>     is a REGISTER for the local domain (or similar);

"Any" is probably too generic. You might want to send final responses
sometime as well:)

>  1) Thou shalt return 100 (Trying) whilst thou proxies, unless
>     the Request is an ACK;
See 7.1

>  3) Thou shalt return 200 (OK) uponst(?) seeing a CANCEL;
See above

>  4) Thou shalt not generate any Responses to ACKs;
Universally true.

---
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 Apr 26 14:38:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02074
	for ; Wed, 26 Apr 2000 14:38: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 1264344337; Wed, 26 Apr 2000 14:33:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 6037144336
	for ; Wed, 26 Apr 2000 14:33:29 -0400 (EDT)
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA00907;
	Wed, 26 Apr 2000 14:36:32 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA05286;
	Wed, 26 Apr 2000 14:36:33 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <2MSF7M8Z>; Wed, 26 Apr 2000 14:31:08 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF678227@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Mark Watson'" , sip@lists.bell-labs.com,
        "'Chip Sharp'" 
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
Date: Wed, 26 Apr 2000 14:36:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFAFAD.950D1EB2"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFAFAD.950D1EB2
Content-Type: text/plain;
	charset="iso-8859-1"

I don't agree.  One of the interesting cases of SIP-T, for which the whole
notion
of the ISUP MIME type was invented was to allow ISUP SIP ISUP connections.
Allowing BICC SIP BICC should be allowed.  Of course, the BNC-ID, the ?ADM?
message, etc introduced in Q.BICC could just go through the MIME encap.
 
Of course, the cool thing would be to eventually get the media to flow
through all
three networks as one IP end-to-end stream!
 
I'll note that we plan to have the BNC-ID be an item specifiable in SDP for
other reasons
soon.
 
Brian

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Wednesday, April 26, 2000 12:44 PM
To: sip@lists.bell-labs.com; 'Chip Sharp'
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP



There will defintely be a need to consider interworking between SIP(-T) and
BICC, but whether this should be done by this group or ITU-T SG11, I am not
so sure about.

I do not think we need to carry BICC inside SIP-T though. BICC is basically
ISUP with extensions for controlling an IP or ATM bearer. SIP-T can already
control IP/ATM bearers using SDP so it wouldn't make sense to carry the
extra BICC stuff as well. It should instead be interworked to the equivalent
SIP mechanism for setting up the bearer.

I expect there will be discussions on this kind of issue at the next SG11
meeting on BICC (1-5 May). 

Regards, 

Mark Watson 
Nortel Networks, UK 

	---------- 
From:   Chip Sharp 
Sent:   Monday, April 10, 2000 1:27 pm 
To:     sip@lists.bell-labs.com 
Subject:        [SIP] Carrying Q.BICC as an Mime-type in SIP 

	ITU (SG11) is currently defining a variant of ISUP that is being
called 
"Bearer Independent Call Control" (BICC).  I'm sure many of you are aware 
of this. 

	They have completed work for Q.BICC to handle Narrowband ISDN
services over 
ATM (this is now numbered Q.1901) and they are now beginning work on IP and 
other networks. 

	It seems that networks using SIP will have to interwork with these
networks 
as well as the current PSTN that uses ISUP. 

	Could (or should) this be included in the SIP-T draft?  Would it be
its own 
type or could/should it be included as a value for the version or spec
field? 

	Chip 
http://www.netaid.org   
------------------------------------------------------------------------- 
Chip Sharp                 CTO Consulting Engineering 
Cisco Systems 
Reality - Love it or Leave it.                  
------------------------------------------------------------------------ 



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


------_=_NextPart_001_01BFAFAD.950D1EB2
Content-Type: text/html;
	charset="iso-8859-1"




RE: [SIP] Carrying Q.BICC as an Mime-type in SIP




I 
don't agree.  One of the interesting cases of SIP-T, for which the whole 
notion


of the 
ISUP MIME type was invented was to allow ISUP SIP ISUP 
connections.


Allowing BICC SIP BICC should be allowed.  Of 
course, the BNC-ID, the ?ADM?


message, etc introduced in Q.BICC could just go through 
the MIME encap.


 


Of 
course, the cool thing would be to eventually get the media to flow through 
all


three 
networks as one IP end-to-end stream!


 


I'll 
note that we plan to have the BNC-ID be an item specifiable in SDP for other 
reasons


soon.


 


Brian



  
-----Original Message-----
From: Mark Watson 
  [mailto:mwatson@nortelnetworks.com]
Sent: Wednesday, April 26, 2000 
  12:44 PM
To: sip@lists.bell-labs.com; 'Chip 
  Sharp'
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in 
  SIP


  
There will defintely be a need to 
  consider interworking between SIP(-T) and BICC, but whether this should be 
  done by this group or ITU-T SG11, I am not so sure about.

  
I do not think we need to carry BICC 
  inside SIP-T though. BICC is basically ISUP with extensions for controlling an 
  IP or ATM bearer. SIP-T can already control IP/ATM bearers using SDP so it 
  wouldn't make sense to carry the extra BICC stuff as well. It should instead 
  be interworked to the equivalent SIP mechanism for setting up the 
  bearer.

  
I expect there will be discussions 
  on this kind of issue at the next SG11 meeting on BICC (1-5 May). 

  
Regards, 

  
Mark Watson 
Nortel Networks, UK 

  
    
    
    ---------- 
    From:   Chip Sharp 
    
    Sent:   Monday, April 10, 2000 1:27 pm 
    To:     sip@lists.bell-labs.com 
    Subject:        [SIP] Carrying Q.BICC as an Mime-type in SIP 
    
    
    ITU (SG11) is currently defining a variant of 
    ISUP that is being called 
    "Bearer 
    Independent Call Control" (BICC).  I'm sure many of you are aware 
    
    of this. 
    
    
    They have completed work for Q.BICC to handle 
    Narrowband ISDN services over 
    ATM (this 
    is now numbered Q.1901) and they are now beginning work on IP and 
    
    other networks. 
    
    
    It seems that networks using SIP will have to 
    interwork with these networks 
    as well as 
    the current PSTN that uses ISUP. 
    
    
    Could (or should) this be included in the SIP-T 
    draft?  Would it be its own 
    type or 
    could/should it be included as a value for the version or spec field? 
    
    
    
    Chip 
    http://www.netaid.org 
    ------------------------------------------------------------------------- 
    
    Chip 
    Sharp                 
    CTO Consulting Engineering 
    Cisco 
    Systems 
    Reality - Love it or Leave 
    it.          
            
    ------------------------------------------------------------------------ 
    


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


------_=_NextPart_001_01BFAFAD.950D1EB2--


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 14:55: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 OAA02430
	for ; Wed, 26 Apr 2000 14: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 4E47E44345; Wed, 26 Apr 2000 14:50:55 -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 B0F7044336
	for ; Wed, 26 Apr 2000 14:50:50 -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 LAA05104;
	Wed, 26 Apr 2000 11:54:27 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ADC06723;
	Wed, 26 Apr 2000 11:52:45 -0700 (PDT)
Message-Id: <4.2.0.58.20000426114402.00cbb340@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 26 Apr 2000 11:53:38 -0700
To: James Kempf 
From: Rohan Mahy 
Subject: Re: [SIP] SIP and network element signalling (formerly: (no
  subject) )
Cc: James.Kempf@eng.sun.com, schulzrinne@cs.columbia.edu, hiren.shah@wipro.com,
        sip@lists.bell-labs.com, brosen@fore.com, mjh@aciri.org,
        nara@syndeocorp.com, mauricio.arango@eng.sun.com
In-Reply-To: <200004261524.IAA22099@nasnfs.eng.sun.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:  
X-BeenThere: sip@lists.bell-labs.com

At 08:26 AM 4/26/00 , James Kempf wrote:
>
> >> 1) Paging a cell phone that currently doesn't have an ongoing call
> >> and might even be in standby mode.
> >
> >Paging to initiate a call? Why is this different from an INVITE?
> >
>
>An INVITE would work if the phone was being paged to set up a call, but 
>paging
>does not necessarily lead to a call being set up. It may be done
>for administrative reasons, for example, to flush a cached service
>profile if the phone is no longer in the service area. My understanding is 
>that
>INVITE is part of a precall setup process only.

Without knowing the specifics of your application it seems OPTIONS would be 
appropriate.

One thing you haven't mentioned is alphanumeric "paging", where 
SUBSCRIBE/NOTIFY would be appropriate.

> >> 2) Having an IP-based phone obtain authentication credentials from a 
> network
> >> authentication server, which may also function as a SIP proxy/call 
> agent, to
> >> allow the IP-based cell phone to authenticate INVITEs as having
> >> come from a valid source.
> >
> >I assume that public key mechanisms are not acceptable?
> >
>
>Sure, but I'm talking about setting up the keying in the first place.
>Something lightweight is needed. It may be possible to leverage
>off the mobile IP keying here.

seems reasonable to exchange keying information either before or during a 
REGISTER.  several methods for "securing" signalling have been proposed: 
Basic, Digest, RADIUS, Kerberos, IKE, TLS.....    stay tuned, this is a 
complex topic.

> >> 3) Allowing the call agent to request a list of features (tones
> >> and announcements) from its home service database for delivery to the 
> mobile
> >> terminal (FeatureRequest in IS-41). Athough this message would most 
> likely be
> >> encountered during setup or execution of a call (when the INFO method 
> could
>be
> >> used), it may occur outside of that context and it will require 
> communication
> >> between two network elements, one of which (the home service database) 
> is not
> >> involved in routing the call.
> >
> >Might help to define 'call agent', as I'm not sure I have the same
> >understanding of this term as you might. Sounds like an OPTIONS request
> >to me, but then I'm not sure how 'tones and announcements' fit into
> >this, as that sounds like media, not signaling.
> >
>
>I thought that OPTIONS was only allowed in the context of either
>setting up a call or an ongoing call. With regard to what the "tones
>and announcents" are, that's all the IS-41 spec says about the return
>value for FeatureRequest. I presume its something like the
>announcement you get when somebody's phone is off and you try to
>call it. Though that is in the context of a call setup, FeatureRequest
>is not restricted to an in progress call, as far as I can determine.

tones and features seem like the type of thing returned in a 183 session 
progess message, which corresponds to an attempted INVITE, but typically 
not a call "in-progress."

if for some reason, you need to send tones to the phone completely outside 
of the context of an attempted call, i have some ideas, but i would want to 
know more specifics before elaborating.

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  Wed Apr 26 14:59: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 OAA02473
	for ; Wed, 26 Apr 2000 14:59: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 E424B44338; Wed, 26 Apr 2000 14:54:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by lists.bell-labs.com (Postfix) with ESMTP id 3C5EE44336
	for ; Wed, 26 Apr 2000 14:54:28 -0400 (EDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id LAA11535; Wed, 26 Apr 2000 11:58:52 -0700 (PDT)
Message-Id: <4.3.1.2.20000426141346.00b67910@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 26 Apr 2000 14:57:20 -0400
To: "Mark Watson" , sip@lists.bell-labs.com
From: Chip Sharp 
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
In-Reply-To: <61ABD11436FED21192440000F81F3E360304BEEB@nwcwi1a.europe.no
 rtel.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:  
X-BeenThere: sip@lists.bell-labs.com

At 05:43 PM 4/26/00 +0100, Mark Watson wrote:

>There will defintely be a need to consider interworking between SIP(-T) 
>and BICC, but whether this should be done by this group or ITU-T SG11, I 
>am not so sure about.
>
>I do not think we need to carry BICC inside SIP-T though. BICC is 
>basically ISUP with extensions for controlling an IP or ATM bearer. SIP-T 
>can already control IP/ATM bearers using SDP so it wouldn't make sense to 
>carry the extra BICC stuff as well. It should instead be interworked to 
>the equivalent SIP mechanism for setting up the bearer.

 From the few discussions I've been involved in and the documents I've 
read, SG11 is very adamant that Bearer-Independent Call Control isn't 
supposed to carry "bearer-dependent" information.  Of course, they have 
relented a little in order to carry some addressing info 
(BIWF-address).  Also, BICC has not been extended to control IP bearers 
yet.  CS2 is still in the requirements stage and the current draft of the 
BICC CS2 requirements includes support of IP bearers as a requirement.

Given that, you may be right that it doesn't necessarily make sense to 
carry BICC in SIP-T, but it is something that should be kept in mind since 
we don't know exactly what SG11 will come up with in the end.

Perhaps what we need is a way to carry SDP in BICC. :-)



>I expect there will be discussions on this kind of issue at the next SG11 
>meeting on BICC (1-5 May).

I've decided not to fly to Melbourne for the week and go to the CALEA JEM 
instead.  Have fun.


>Regards,
>
>Mark Watson
>Nortel Networks, UK
>----------  From:   Chip Sharp  Sent:   Monday, April 10, 2000 1:27 
>pm  To:     sip@lists.bell-labs.com  Subject:        [SIP] Carrying Q.BICC 
>as an Mime-type in SIP
>
>ITU (SG11) is currently defining a variant of ISUP that is being 
>called  "Bearer Independent Call Control" (BICC).  I'm sure many of you 
>are aware  of this.
>
>They have completed work for Q.BICC to handle Narrowband ISDN services 
>over  ATM (this is now numbered Q.1901) and they are now beginning work on 
>IP and  other networks.
>
>It seems that networks using SIP will have to interwork with these 
>networks  as well as the current PSTN that uses ISUP.
>
>Could (or should) this be included in the SIP-T draft?  Would it be its 
>own  type or could/should it be included as a value for the version or 
>spec field?
>
>Chip  http://www.netaid.org 
>------------------------------------------------------------------------- 
>Chip Sharp                 CTO Consulting Engineering  Cisco 
>Systems  Reality - Love it or Leave 
>it. 
>------------------------------------------------------------------------
>
>
>
>_______________________________________________  SIP mailing 
>list  SIP@lists.bell-labs.com 
>http://lists.bell-labs.com/mailman/listinfo/sip 
>


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------



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


From sip-admin@lists.bell-labs.com  Wed Apr 26 15:03: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 PAA02717
	for ; Wed, 26 Apr 2000 15:03: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 563B34434D; Wed, 26 Apr 2000 14:58: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 9765C44338
	for ; Wed, 26 Apr 2000 14:58:21 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id UAA01809; Wed, 26 Apr 2000 20:00:40 +0100 (BST)
Message-ID: <39073CD7.AE2C2780@ubiquity.net>
Date: Wed, 26 Apr 2000 20:00:39 +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: Igor Slepchin 
Cc: Jo Hornsby ,
        Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <002b01bfaf80$4092a410$4e34c3c1@ubiquity.co.uk> <3907300F.2E01C5C4@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

At the risk of adding more confusion ...

Igor Slepchin wrote:

> Jo Hornsby wrote:
> >
> > So, should a stateful proxy always return 200 for a CANCEL?  I'm
> > struggling to envisage a case where it would not.  It seems to me
> > that returning 481 implies confusing semantics, since the ultimate
> > UAS could "successfully" CANCEL the offending transaction.
>
> It should return 481 if it doesn't know what transaction that CANCEL is
> for (i.e., it has already forgotten about that transaction or received a
> stray CANCEL). I thought it might also return a 481 if it received a
> CANCEL for a transaction in the state where CANCEL doesn't make sense
> but the spec is quite specific on this (4.2.5 in 2543bis):
>
> A redirect or user agent server (a proxy server as well, I guess)
> receiving a CANCEL request responds with a status code 200 (OK) if the
> transaction exists and a status 481 (Transaction Does Not Exist) if not.

Just to be clear are you saying that you should send back 481 and proxy
the CANCEL? I thought that a stateful proxy should always forward on
the CANCEL as while it may have lost state a UAS may not have and
find the CANCEL useful.  (See Jonathon's posting earlier on this thread).

> Note that the class of CANCEL response has no impact on protocol
> operation.
>
> > > Since the correct behavior of a stateless proxy is to forward all
> > > CANCELs, it makes sense that the default behavior of a stateful proxy
> > > which forgot its state should be the same - proxy the CANCEL.
> >
> > Is this stated explicitly anywhere, or is it implied by section
> > 12.3.4 in rfc2543bis?
>
> No special case is made for CANCEL and all other requests are to be
> proxied, hence CANCEL is to be proxied as well. I don't think this
> specific situation is described anywhere in the spec.

> > Therefore, should a stateless proxy initially
> > return a 100 for a CANCEL, as specified by section 12.4?
>
> No. From section 7.1 in 2543bis: "A server SHOULD send a 1xx response if
> it expects to take more than 200 ms to obtain a final response." A
> response to CANCEL is sent immediately, so there is no point in sending
> a 1xx.

I agree that sending a 100 is not very sensible for CANCELS.
However 12.4 states a forking proxy MUST send back 100 immediately.
This contradicts what we think is the right thing to do here and the
case with ACKs where the draft also says you shouldn't generate any
responses. If we are right maybe the bis draft needs clarifying here.

Cheers,
Neil
--
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 Apr 26 15:11: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 PAA02959
	for ; Wed, 26 Apr 2000 15:11: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 18D5E44338; Wed, 26 Apr 2000 15:07:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ott-rd.ss8.ca (gw-ss8networks.storm.ca [209.87.234.122])
	by lists.bell-labs.com (Postfix) with ESMTP id 42AC844337
	for ; Wed, 26 Apr 2000 15:06:59 -0400 (EDT)
Received: from eberpc ([192.168.1.60])
	by ott-rd.ss8.ca (8.9.3/8.9.3) with SMTP id PAA04209
	for ; Wed, 26 Apr 2000 15:11:17 -0400
From: "Eber Mello" 
To: 
Date: Wed, 26 Apr 2000 15:13:26 -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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: [SIP] Third-party call control with already initiated call
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

The third-party call control draft (expires September 2000) describes a 
generic way of setting up parties using a "controller".
It also mentions in section 4 that "if a participant initiates 
the call, the controller must step in as a virtual UAC/UAS and 
act as a termination and re-initiation point". I have a couple of
questions regarding this mechanism:

1) A Re-Invite initiated by the controller to one of the UAs to 
put it on hold would use the same call-leg ids of the original
Invite transaction? Note that the original Invite was not
addressed to the controller but rather to a third UA. The controller 
happened to be on the signalling path and was only monitoring the 
messages between the UAs and decided to step in.

2)Could the controller be used to "intercept" Invite requests 
to third-party users and respond to them with 200 OK in order to, say, 
connect (in the RTP sense) the UAC to a non-SIP enabled entity (e.g.
a music source). In this case would the 200 OK use the same call-leg ids
of the original Invite?

Thanks,

Eber Mello


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


From sip-admin@lists.bell-labs.com  Wed Apr 26 15:25: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 PAA03158
	for ; Wed, 26 Apr 2000 15:25: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 45A5F44337; Wed, 26 Apr 2000 15:21:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9A1C544336
	for ; Wed, 26 Apr 2000 15:21: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 PAA17552;
	Wed, 26 Apr 2000 15:23:06 -0400 (EDT)
Message-ID: <3907413E.9D08BA66@dynamicsoft.com>
Date: Wed, 26 Apr 2000 15:19:26 -0400
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Neil Deason 
Cc: Jo Hornsby ,
        Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <002b01bfaf80$4092a410$4e34c3c1@ubiquity.co.uk> <3907300F.2E01C5C4@dynamicsoft.com> <39073CD7.AE2C2780@ubiquity.net>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Neil Deason wrote:
> 
> > A redirect or user agent server (a proxy server as well, I guess)
> > receiving a CANCEL request responds with a status code 200 (OK) if the
> > transaction exists and a status 481 (Transaction Does Not Exist) if not.
> 
> Just to be clear are you saying that you should send back 481 and proxy
> the CANCEL? 

Yes. BTW, 481 means a 481 response to CANCEL, _not_ a 481 to the
original request.

> I thought that a stateful proxy should always forward on
> the CANCEL as while it may have lost state a UAS may not have and
> find the CANCEL useful.  (See Jonathon's posting earlier on this thread).

I don't really see a contradiction here. How sending a 481 is different
from sending a 200?
 
> 
> I agree that sending a 100 is not very sensible for CANCELS.
> However 12.4 states a forking proxy MUST send back 100 immediately.
> This contradicts what we think is the right thing to do here and the
> case with ACKs where the draft also says you shouldn't generate any
> responses. If we are right maybe the bis draft needs clarifying here.
 
I agree that this needs some clarification. Probably the 200 ms rule
from 7.1 should be repeated in 12.4 as well.

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  Wed Apr 26 15:40: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 PAA03478
	for ; Wed, 26 Apr 2000 15:40: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 B2DF344337; Wed, 26 Apr 2000 15:36:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by lists.bell-labs.com (Postfix) with ESMTP id 39C7044336
	for ; Wed, 26 Apr 2000 15:36:13 -0400 (EDT)
Received: from l3107mxr.atl.hp.com (l3107mxr.atl.hp.com [15.19.254.19])
	by atlrel1.hp.com (Postfix) with ESMTP
	id 61ECF1BFF2; Wed, 26 Apr 2000 15:40:20 -0400 (EDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by l3107mxr.atl.hp.com (Postfix) with ESMTP
	id 85C3F4FDB6; Wed, 26 Apr 2000 15:40:13 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id UAA06724;
	Wed, 26 Apr 2000 20:40:12 +0100 (BST)
Message-ID: <39074657.5260B614@hplb.hpl.hp.com>
Date: Wed, 26 Apr 2000 20:41:11 +0100
From: Anders Kristensen 
Organization: HP Labs
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Igor Slepchin ,
        Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <200004250022.UAA00803@bounty.cisco.com> <3904EAE4.F535398A@dynamicsoft.com> <39052DAF.160A2CED@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> 
> Igor Slepchin wrote:
> >
> > Shail Bhatnagar wrote:
> > >
> > > Can someone please clarify the behavior in the following scenarios :
> > >
> > > 1) Stateful proxy server returns a final response upstream.
> > > Now it receives a CANCEL request. Should it return a 481 response ??
> >
> > It may return a 481. However, it should still try to proxy the CANCEL
> > upstream, I believe.
> 
> Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> There was no error; the CANCEL was received for a valid transaction.
> 
> As for proxying it upstream, if the proxy returned a final response
> already, there should either be no pending branches, or a CANCEL was
> already sent to cancel pending branches. In that case, there is no need
> to proxy the CANCEL.

Actually, just for the record, I believe CANCEL'ing outstanding branches
upon receiving a 2xx is optional for a proxy (12.4 in 2543bis), so in
this case proxying CANCEL would be appropriate.

-- 
Anders Kristensen ,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 00:46: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 AAA12201
	for ; Thu, 27 Apr 2000 00:46: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 19B3B4433D; Thu, 27 Apr 2000 00:42:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 0B24744338
	for ; Thu, 27 Apr 2000 00:42:03 -0400 (EDT)
Received: from dynamicsoft.com (1Cust140.tnt2.freehold.nj.da.uu.net [63.17.114.140])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA18829;
	Thu, 27 Apr 2000 00:45:52 -0400 (EDT)
Message-ID: <3907C810.DA80A316@dynamicsoft.com>
Date: Thu, 27 Apr 2000 00:54:40 -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: James Kempf , schulzrinne@cs.columbia.edu,
        hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (nosubject) )
References: <4.2.0.58.20000426114402.00cbb340@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Rohan Mahy wrote:
> 
> At 08:26 AM 4/26/00 , James Kempf wrote:
> >
> > >> 1) Paging a cell phone that currently doesn't have an ongoing call
> > >> and might even be in standby mode.
> > >
> > >Paging to initiate a call? Why is this different from an INVITE?
> > >
> >
> >An INVITE would work if the phone was being paged to set up a call, but
> >paging
> >does not necessarily lead to a call being set up. It may be done
> >for administrative reasons, for example, to flush a cached service
> >profile if the phone is no longer in the service area. My understanding is
> >that
> >INVITE is part of a precall setup process only.
> 
> Without knowing the specifics of your application it seems OPTIONS would be
> appropriate.

As has been pointed out, I believe OPTIONS is appropriate. What kind of
information are you looking to obtain from the page? Is the intent that
this page have a particular state side effect? If the page has no effect
on the state of the phone, and simply returns the current location of
the phone, its capabilities, and so on, OPTIONS is exactly what you
want. 

> 
> > >> 2) Having an IP-based phone obtain authentication credentials from a
> > network
> > >> authentication server, which may also function as a SIP proxy/call
> > agent, to
> > >> allow the IP-based cell phone to authenticate INVITEs as having
> > >> come from a valid source.
> > >
> > >I assume that public key mechanisms are not acceptable?
> > >
> >
> >Sure, but I'm talking about setting up the keying in the first place.
> >Something lightweight is needed. It may be possible to leverage
> >off the mobile IP keying here.
> 
> seems reasonable to exchange keying information either before or during a
> REGISTER.  several methods for "securing" signalling have been proposed:
> Basic, Digest, RADIUS, Kerberos, IKE, TLS.....    stay tuned, this is a
> complex topic.

SIP is not meant as a keying exchange protocol. There are already keying
exchange protocols out there, as Rohan has pointed out. I am very queasy
about trying to invent a new one ontop of SIP just to avoid having to
implement "another" protocol. In reality, you will be implementing
another protocol, but just using SIP as a transfer method between two
points. That is the easy part of any protocol. I'll also note that
security protocols are notoriously easy to get wrong. 


> 
> > >> 3) Allowing the call agent to request a list of features (tones
> > >> and announcements) from its home service database for delivery to the
> > mobile
> > >> terminal (FeatureRequest in IS-41). Athough this message would most
> > likely be
> > >> encountered during setup or execution of a call (when the INFO method
> > could
> >be
> > >> used), it may occur outside of that context and it will require
> > communication
> > >> between two network elements, one of which (the home service database)
> > is not
> > >> involved in routing the call.

> >I thought that OPTIONS was only allowed in the context of either
> >setting up a call or an ongoing call. With regard to what the "tones
> >and announcents" are, that's all the IS-41 spec says about the return
> >value for FeatureRequest. I presume its something like the
> >announcement you get when somebody's phone is off and you try to
> >call it. Though that is in the context of a call setup, FeatureRequest
> >is not restricted to an in progress call, as far as I can determine.

Without more specifics, its hard to say what the right way to do it is.

Related to this, there is a tendency of folks to try and support legacy
features within SIP by using the same legacy mechanisms used to
implement those legacy features. I don't think this is the right
approach. Rather, figure out the service requirement, generalize it, and
then consider how it can be done in SIP. Saying we need the equivalent
of "FeatureRequest" makes me nervous since the mechanism for services
within SIP is not the same as PSTN. Consider the specific case you
mention, that of getting an announcement when someones phone is off. In
SIP, it seems like this would work as follows:

1. A calls B, which is routed to B's "home" proxy
2. B is registered elsewhere, at this "remote" proxy, so B's home proxy
forwards the request there
3. at the remote proxy, the call is forwarded the current location of
the user
4. the user does not answer, so the remote proxy returns 408
5. the home proxy receives 408. It has the service enabled so that if it
receives no answer, the call is forwarded to a media server which
responds with a 183, plays the announcement, and then responds with a
final 400.

This achieves the desired service without inheriting the particulars of
how it was implemented within IS-41. 

I'll also observe that one of the absolutely essential components of the
SIP-T work, which also supports legacy signaling, is that call semantics
are always derived from SIP, not the tunneled protocols. INFO carries
messages which have no impact on call or session state, and are
basically "passed to the application", which is a gateway in this case.
This ensures that any features are still  being provided by SIP, in a
SIP fashion, while the ISUP is carrying only information that is "FYI".
This is possible since ISUP signaling is honestly not radically
different from SIP, just that it has lots of extra bits and information
that is not really needed for SIP itself.

So, for people considering INFO method for something or other, be aware
of this. The INFO draft explicitly states a very limited scope for INFO.
Using it as a catchall way for anything will definitely cause
interoperability nightmares. 

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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 01:34:43 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16211
	for ; Thu, 27 Apr 2000 01:34: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 373A144337; Thu, 27 Apr 2000 01:30:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E15B644336
	for ; Thu, 27 Apr 2000 01:30:00 -0400 (EDT)
Received: from dynamicsoft.com (1Cust140.tnt2.freehold.nj.da.uu.net [63.17.114.140])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA18856;
	Thu, 27 Apr 2000 01:31:59 -0400 (EDT)
Message-ID: <3907D2DF.8D60DE79@dynamicsoft.com>
Date: Thu, 27 Apr 2000 01:40:47 -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: Neil Deason , Jo Hornsby ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] CANCEL related questions
References: <002b01bfaf80$4092a410$4e34c3c1@ubiquity.co.uk> <3907300F.2E01C5C4@dynamicsoft.com> <39073CD7.AE2C2780@ubiquity.net> <3907413E.9D08BA66@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Igor Slepchin wrote:
> 
> Neil Deason wrote:
> >
> > > A redirect or user agent server (a proxy server as well, I guess)
> > > receiving a CANCEL request responds with a status code 200 (OK) if the
> > > transaction exists and a status 481 (Transaction Does Not Exist) if not.
> >
> > Just to be clear are you saying that you should send back 481 and proxy
> > the CANCEL?
> 
> Yes. BTW, 481 means a 481 response to CANCEL, _not_ a 481 to the
> original request.
> 
> > I thought that a stateful proxy should always forward on
> > the CANCEL as while it may have lost state a UAS may not have and
> > find the CANCEL useful.  (See Jonathon's posting earlier on this thread).
> 
> I don't really see a contradiction here. How sending a 481 is different
> from sending a 200?

There are three possibilities about what a proxy might do (as far as
responses to the CANCEL) when it receives one for which no transaction
exists:

1. not respond at all, but rather forward the response from the next hop
upstream (this is what a stateless proxy will do)
2. respond with 200 OK immediately
3. respond with 481 immediately

All three will work just fine. Igor has pointed out correctly that the
client behavior remains unchanged if it gets a 200 as opposed to 481. I
can think of unsubstantial reasons for one over the other. Note that the
spec does not say that a PROXY should return 481 if the call leg is
unknown, only UA and redirects:

> A redirect or user agent server receiving a CANCEL request responds
>    with a status of 200 (OK) if the transaction exists and a status of
>    481 (Transaction Does Not Exist) if not, but takes no further action.
>    In particular, any existing call is unaffected.

I could not find anything in the spec which recommends 481 or 200 for
proxies in this case. 



> 
> >
> > I agree that sending a 100 is not very sensible for CANCELS.
> > However 12.4 states a forking proxy MUST send back 100 immediately.
> > This contradicts what we think is the right thing to do here and the
> > case with ACKs where the draft also says you shouldn't generate any
> > responses. If we are right maybe the bis draft needs clarifying here.
> 
> I agree that this needs some clarification. Probably the 200 ms rule
> from 7.1 should be repeated in 12.4 as well.

100 is definitely useless for CANCEL. We'll clarify that.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 01:37: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 BAA16621
	for ; Thu, 27 Apr 2000 01:37: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 24AD444344; Thu, 27 Apr 2000 01:33:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id B8E9144343
	for ; Thu, 27 Apr 2000 01:33:05 -0400 (EDT)
Received: from dynamicsoft.com (1Cust140.tnt2.freehold.nj.da.uu.net [63.17.114.140])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA18860;
	Thu, 27 Apr 2000 01:38:36 -0400 (EDT)
Message-ID: <3907D46C.5B6E1CAA@dynamicsoft.com>
Date: Thu, 27 Apr 2000 01:47:24 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Benny Prijono 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Session timer comments (2)
References: <3906CB2A.12DC455C@theseventhson.freeserve.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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Benny Prijono wrote:
> 
> >From Session Timer draft dated March 2000 (page 5):
> 
>    If no 200 OK response to a refreshing re-INVITE is
>    received before the expiration of the session, the
>    UAC SHOULD send a BYE request to terminate the call.
>    It SHOULD send this BYE slightly before   expiration
>    of the session. Ten seconds is RECOMMENDED.
> 
> I believe this paragraph is intended to deal with two different issues.
> First, when the re-INVITE failed, and, second when the UAC doesn't want
> to send re-INVITE to refresh the timer.
> 
> For the first issue, ie. when the re-INVITE failed, I think the UAC
> should send the BYE immediately. 

What do you mean by failed? Generated a non-200 class response? In this
case, definitely not, since the re-INVITE can fail for legitimate
reasons, for which you don't want to hang up the call.

If you mean fail in the sense that no response is received at all, I
guess you can send a BYE immediately if thats what you want. However,
the problem may be some kind of temporary network partition, in which
case I can envision other implementations which might prefer to retry
until the expiration of the session timer. I do believe the spec should
discuss options in the case where no response is ever received for
re-INVITE (no final response, that is).


> If my interpretation above correct, then that paragraph needs to be
> modified because it is confusing. And also you need to change comments
> in sample call flow in page 9:
> 
>    For whatever reason, the calling UA decides not
>    to refresh. So, after 120 seconds, it sends a BYE.
> 
> The correct timeout value should be 110 seconds.

Right, thanks.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 01: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 BAA17082
	for ; Thu, 27 Apr 2000 01:41: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 4598D44337; Thu, 27 Apr 2000 01:36:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id F3C0744336
	for ; Thu, 27 Apr 2000 01:36:45 -0400 (EDT)
Received: from dynamicsoft.com (1Cust140.tnt2.freehold.nj.da.uu.net [63.17.114.140])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA18865;
	Thu, 27 Apr 2000 01:42:29 -0400 (EDT)
Message-ID: <3907D555.5F276277@dynamicsoft.com>
Date: Thu, 27 Apr 2000 01:51:17 -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: sip@lists.bell-labs.com
Subject: Re: [SIP] Proxies enforcing UA compliance
References: <200004261758.NAA09264@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



David Daiker wrote:
> 
> I have a general question about the recommended behavior of a proxy that
> receives a non-compliant message from a UAC.
> 
> Specifically, what should a proxy do with a final response to an INVITE
> that lacks a 'tag' parameter in its 'To' field.
> 
> Should it be forwarded and let the UA figure it out ?
> or drop it until the callee gives up and quits re-transmitting it ?

Proxies don't really care about tags in the To fields (they do need to
be aware of them for matching rules of responses to requests, but thats
it). So, they should definitely forward the response upstream. 

-Jonathan R.



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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 01:47: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 BAA17586
	for ; Thu, 27 Apr 2000 01:47:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 72D6244350; Thu, 27 Apr 2000 01:42:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D9C4A4434F
	for ; Thu, 27 Apr 2000 01:42:42 -0400 (EDT)
Received: from dynamicsoft.com (1Cust140.tnt2.freehold.nj.da.uu.net [63.17.114.140])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA18873;
	Thu, 27 Apr 2000 01:48:26 -0400 (EDT)
Message-ID: <3907D6BA.B08BA4EA@dynamicsoft.com>
Date: Thu, 27 Apr 2000 01:57:14 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eber Mello 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Third-party call control with already initiated call
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Eber Mello wrote:
> 
> Hi,
> 
> The third-party call control draft (expires September 2000) describes a
> generic way of setting up parties using a "controller".
> It also mentions in section 4 that "if a participant initiates
> the call, the controller must step in as a virtual UAC/UAS and
> act as a termination and re-initiation point". I have a couple of
> questions regarding this mechanism:
> 
> 1) A Re-Invite initiated by the controller to one of the UAs to
> put it on hold would use the same call-leg ids of the original
> Invite transaction? 

They would use the call-leg ids in place between the controller and the
given UA.

Note that the original Invite was not
> addressed to the controller but rather to a third UA. The controller
> happened to be on the signalling path and was only monitoring the
> messages between the UAs and decided to step in.

Yup. You can think of it as a gateway, much like SIP to H.323 or SIP to
ISUP, but here its SIP to SIP.

> 
> 2)Could the controller be used to "intercept" Invite requests
> to third-party users and respond to them with 200 OK in order to, say,
> connect (in the RTP sense) the UAC to a non-SIP enabled entity (e.g.
> a music source). In this case would the 200 OK use the same call-leg ids
> of the original Invite?

Of course. Here, the controller is just a UAS. It follows the rules for
UAS.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 04:22: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 EAA25103
	for ; Thu, 27 Apr 2000 04:22: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 0C0764433E; Thu, 27 Apr 2000 04:17: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 89F9D44336
	for ; Thu, 27 Apr 2000 04:17:45 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA22262; Thu, 27 Apr 2000 09:20:12 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Igor Slepchin 
Subject: Re: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
Date: Thu, 27 Apr 2000 09:00:30 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Sip Mail List 
References: <00042612595802.02452@gethin> <390720D8.44210C96@dynamicsoft.com>
In-Reply-To: <390720D8.44210C96@dynamicsoft.com>
MIME-Version: 1.0
Message-Id: <00042709181600.04398@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

On Wed, 26 Apr 2000, Igor Slepchin wrote:
> I agree that escaping characters in host name makes little sense as that
> host name wouldn't be resolvable anyway; it is explicitly disallowed by
> the BNF, and the example is inconsistent with the BNF as you correctly
> noted. However, I don't think the spec prohibits escaped chars in url
> parameters:
> 
> other-param     = ( token | ( token "=" ( token | quoted-string )))
> 
> and BNF of token allows '%' sign (explicitly in 2543bis).
> 

I almost agree.

Yes, the `%' is allowed in tokens, but only as a character in its own right,
not as the start of an escaped value.  The format ("%" HEX HEX) of escaped 
values are valid but escaped values themselves are not explicity 
allowed or defined in a token.

Thus, if a url parameter has the value:

%61

is this considered to be the char `a' or the three characters `%' `6' and `1'

As the bnf stands, it would be the latter.

> ---
> Igor Slepchin
> 
> Gethin Liddell wrote:
> > 
> > Hi,
> > 
> > I'm querying the idea of escaped characters in Sip Url's.
> > This is discussed in both the rfc and bis in Section 2.
> > 
> > The RFC says:
> > 
> > "Note that reserved characters have to be
> >    escaped and that the "set of characters reserved within any given URI
> >    component is defined by that component. In general, a character is
> >    reserved if the semantics of the URI changes if the character is
> >    replaced with its escaped US-ASCII encoding" [12]."
> > 
> > What I am querying is the use of this escaped notation within the hostname
> > of the SIP-URL.
> > 
> > The bnf in Section 2 Figure 3 defines the hostname to consist of only alphas,
> > numbers and `-' characters.  It does NOT allow for escaped characters to
> > exist as no `%' char is allowed.
> > 
> > However, the bis draft provides an example at the end of Section 2.1 as follows:
> > 
> > "Thus, the following URLs are equivalent:
> > 
> > sip:juser@%65xample.com:5060
> > sip:juser@ExAmPlE.CoM;Transport=UDp"
> > 
> > Thus we have a contradication to the bnf with the address "%65xample.com".
> > It seems to me that there would be no cause to have escaped characters in the
> > host name as it could never be resolved to an actual IP address.  And to have to
> > revert the escaped char back to its original form is very inefficent as extra checks
> > will have to be made for each character to see if it is in the escaped form.  Plus the
> > actual escaped char may be reverted to an invalid char for a host.
> > 
> > The bnf does however allow escaped characters in the userinfo and header elements,
> > but not in parameter values.
> > 
> > To summarize, as I understand it:
> > 
> > Escaped characters can only be used in the following elements:
> > 
> > 1) user
> > 2) password
> > 3) hname
> > 4) hvalue
> > 
> > and in these cases, when doing a comparison check, the escaped values MUST be
> > compared in their reverted (non-escaped form).
> > 
> > Escaped values MUST not be used in the following elements:
> > 1) host
> > 2) url-parameter
> > 
> > Please can you confirm and clarify this matter.
> > 
> > thanx
> > 
> > gethin
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 27 07:41:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26980
	for ; Thu, 27 Apr 2000 07:41: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 63D2744337; Thu, 27 Apr 2000 07:36:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cmailg6.svr.pol.co.uk (cmailg6.svr.pol.co.uk [195.92.195.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 68B7744336
	for ; Thu, 27 Apr 2000 07:36:26 -0400 (EDT)
Received: from modem-64.antenna-lion.dialup.pol.co.uk ([62.136.223.64] helo=theseventhson.freeserve.co.uk)
	by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 12kmf7-00083B-00; Thu, 27 Apr 2000 12:40:54 +0100
Message-ID: <39082801.353D24DF@theseventhson.freeserve.co.uk>
Date: Thu, 27 Apr 2000 12:44:01 +0100
From: Benny Prijono 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Session timer comments (2)
References: <3906CB2A.12DC455C@theseventhson.freeserve.co.uk> <3907D46C.5B6E1CAA@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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Benny Prijono wrote:
> >
> > >From Session Timer draft dated March 2000 (page 5):
> >
> > ...
> > For the first issue, ie. when the re-INVITE failed, I think the UAC
> > should send the BYE immediately.
> 
> What do you mean by failed? Generated a non-200 class response? In this
> case, definitely not, since the re-INVITE can fail for legitimate
> reasons, for which you don't want to hang up the call.
> 

Quite on the contrary, I think most of the time I will disconnect the
call when non-200 response is received, because it just means
something is wrong. The only exception I can think of is when the
re-INVITE failed because glare condition happens, which in this case
the client should retry the re-INVITE.

> If you mean fail in the sense that no response is received at all, I
> guess you can send a BYE immediately if thats what you want. However,
> the problem may be some kind of temporary network partition, in which
> case I can envision other implementations which might prefer to retry
> until the expiration of the session timer. I do believe the spec should
> discuss options in the case where no response is ever received for
> re-INVITE (no final response, that is).
> 

It's a good idea to discuss the options, but I think the spec should
not recommend any actions, because this will be too specific to the
applications. Some applications (like yours?) use session-expires to
keep the call alive, while some others (like mine) use it to clean-up
resources when the remote party is suspected to be dead. The
difference is that the later is more willing to send BYE than the
first.

Thanks,

Bennylp



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


From sip-admin@lists.bell-labs.com  Thu Apr 27 07:44: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 HAA27027
	for ; Thu, 27 Apr 2000 07:44: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 37B5344340; Thu, 27 Apr 2000 07:39:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 459334433E
	for ; Thu, 27 Apr 2000 07:39:20 -0400 (EDT)
Received: from qhars002.nortel.com (actually zhars00t) by qnsgs000.nortel.com;
          Thu, 27 Apr 2000 11:44:18 +0100
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Thu, 27 Apr 2000 11:43:53 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2650.21) id ;
          Thu, 27 Apr 2000 11:43:52 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304BEF3@nwcwi1a.europe.nortel.com>
From: "Mark Watson" 
To: sip@lists.bell-labs.com, "'Chip Sharp'" ,
        "'Rosen, Brian'" 
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
Date: Thu, 27 Apr 2000 11:43:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFB035.7A92B154"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
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_01BFB035.7A92B154
Content-Type: text/plain;
	charset="iso-8859-1"

If we have CS(A) --bicc ---CS(B)---sip --- CS(C)---bicc---CS(D)

where 'CS' is 'Call Server', for want of a better term, then there are two
cases:

(i) with the bearer path routed directly between Gateways controlled by
CS(A) and CS(D), and

(ii) with further 'packet-to-packet' gateways contolled by CS(B) and CS(C)
i.e. there are three 'domains' which are physically interworked at both the
call and bearer layer.

There is some doubt as to whether (i) will be possible at all - this depends
on how the support of IP in BICC is defined over the next few months. If it
is possible, I think that it should involve maping the bearer control
mechanism in BICC to the equivalent in SIP (SDP) so that the call can still
work if it terminates on a pure SIP agent. If you don't include this
compatibility, it's not SIP at all. You mention that SDP will be including
an equivalent to BNC-ID (I believe it's called EECID ?). As I understand it
this would allow you to do exactly what I'm suggesting.

If you do this mapping, then you've removed from the BICC information
everything which makes it BICC and not ISUP, so you're not carrying BICC
inside SIP at all.

In case (ii), the three domains are completely independent from each other
when it comes to setup of the bearer connection. Again, the only information
from BICC left to carry over the SIP domain is the ISUP part.

If we were to carry the BICC APM parameter, which contains the Bearer
related information, over SIP, we would be inventing a new way of carrying
out bearer setup on a SIP call - an alternative to SDP. I do not think we
should do this as it would be non-backwards-compatible.

Regards,

Mark Watson
Nortel Networks



> ----------
> From: 	Rosen, Brian
> Sent: 	Wednesday, April 26, 2000 7:36 pm
> To: 	Watson, Mark [MAIFP:EP11-M:EXCH]; sip@lists.bell-labs.com; 'Chip
> Sharp'
> Subject: 	RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
> 
> I don't agree.  One of the interesting cases of SIP-T, for which the whole
> notion
> of the ISUP MIME type was invented was to allow ISUP SIP ISUP connections.
> Allowing BICC SIP BICC should be allowed.  Of course, the BNC-ID, the
> ?ADM?
> message, etc introduced in Q.BICC could just go through the MIME encap.
>  
> Of course, the cool thing would be to eventually get the media to flow
> through all
> three networks as one IP end-to-end stream!
>  
> I'll note that we plan to have the BNC-ID be an item specifiable in SDP
> for other reasons
> soon.
>  
> Brian
> 
> 	-----Original Message-----
> 	From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> 	Sent: Wednesday, April 26, 2000 12:44 PM
> 	To: sip@lists.bell-labs.com; 'Chip Sharp'
> 	Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP
> 
> 
> 
> 	There will defintely be a need to consider interworking between
> SIP(-T) and BICC, but whether this should be done by this group or ITU-T
> SG11, I am not so sure about.
> 
> 	I do not think we need to carry BICC inside SIP-T though. BICC is
> basically ISUP with extensions for controlling an IP or ATM bearer. SIP-T
> can already control IP/ATM bearers using SDP so it wouldn't make sense to
> carry the extra BICC stuff as well. It should instead be interworked to
> the equivalent SIP mechanism for setting up the bearer.
> 
> 	I expect there will be discussions on this kind of issue at the next
> SG11 meeting on BICC (1-5 May). 
> 
> 	Regards, 
> 
> 	Mark Watson 
> 	Nortel Networks, UK 
> 
> 		---------- 
> 	From:   Chip Sharp 
> 	Sent:   Monday, April 10, 2000 1:27 pm 
> 	To:     sip@lists.bell-labs.com 
> 	Subject:        [SIP] Carrying Q.BICC as an Mime-type in SIP 
> 
> 		ITU (SG11) is currently defining a variant of ISUP that is
> being called 
> 	"Bearer Independent Call Control" (BICC).  I'm sure many of you are
> aware 
> 	of this. 
> 
> 		They have completed work for Q.BICC to handle Narrowband
> ISDN services over 
> 	ATM (this is now numbered Q.1901) and they are now beginning work on
> IP and 
> 	other networks. 
> 
> 		It seems that networks using SIP will have to interwork with
> these networks 
> 	as well as the current PSTN that uses ISUP. 
> 
> 		Could (or should) this be included in the SIP-T draft?
> Would it be its own 
> 	type or could/should it be included as a value for the version or
> spec field? 
> 
> 		Chip 
> 	http://www.netaid.org 
> 	
> ------------------------------------------------------------------------- 
> 	Chip Sharp                 CTO Consulting Engineering 
> 	Cisco Systems 
> 	Reality - Love it or Leave it.                  
> 	
> ------------------------------------------------------------------------ 
> 
> 
> 
> 		_______________________________________________ 
> 	SIP mailing list 
> 	SIP@lists.bell-labs.com 
> 	http://lists.bell-labs.com/mailman/listinfo/sip 
> 
> 

------_=_NextPart_001_01BFB035.7A92B154
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Carrying Q.BICC as an Mime-type in SIP




If we have CS(A) =
--bicc ---CS(B)---sip --- CS(C)---bicc---CS(D)




where 'CS' is 'Call =
Server', for want of a better term, then there are two cases:




(i) with the bearer =
path routed directly between Gateways controlled by CS(A) and CS(D), =
and




(ii) with further =
'packet-to-packet' gateways contolled by CS(B) and CS(C) i.e. there are =
three 'domains' which are physically interworked at both the call and =
bearer layer.



There is some doubt =
as to whether (i) will be possible at all - this depends on how the =
support of IP in BICC is defined over the next few months. If it is =
possible, I think that it should involve maping the bearer control =
mechanism in BICC to the equivalent in SIP (SDP) so that the call can =
still work if it terminates on a pure SIP agent. If you don't include =
this compatibility, it's not SIP at all. You mention that SDP will be =
including an equivalent to BNC-ID (I believe it's called EECID ?). As I =
understand it this would allow you to do exactly what I'm =
suggesting.



If you do this =
mapping, then you've removed from the BICC information everything which =
makes it BICC and not ISUP, so you're not carrying BICC inside SIP at =
all.



In case (ii), the =
three domains are completely independent from each other when it comes =
to setup of the bearer connection. Again, the only information from =
BICC left to carry over the SIP domain is the ISUP part.



If we were to carry =
the BICC APM parameter, which contains the Bearer related information, =
over SIP, we would be inventing a new way of carrying out bearer setup =
on a SIP call - an alternative to SDP. I do not think we should do this =
as it would be non-backwards-compatible.



Regards,




Mark Watson

Nortel =
Networks







    

    ----------

    From:   Rosen, Brian

    Sent:   Wednesday, April 26, 2000 7:36 pm

    To:     =
Watson, Mark [MAIFP:EP11-M:EXCH]; =
sip@lists.bell-labs.com; 'Chip Sharp'

    Subject: =
       RE: =
[SIP] Carrying Q.BICC as an Mime-type in SIP

    


    I don't agree.=A0 =
One of the interesting cases of SIP-T, for which the whole =
notion

    of the ISUP MIME =
type was invented was to allow ISUP SIP ISUP connections.

    Allowing BICC SIP =
BICC should be allowed.=A0 Of course, the BNC-ID, the ?ADM?

    message, etc =
introduced in Q.BICC could just go through the MIME encap.

    =A0

    Of course, the cool =
thing would be to eventually get the media to flow through all

    three networks as =
one IP end-to-end stream!

    =A0

    I'll note that we =
plan to have the BNC-ID be an item specifiable in SDP for other =
reasons

    soon.

    =A0

    Brian

    

      

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

      From: Mark Watson [mailto:mwatson@nortelnetworks=
.com]

      Sent: Wednesday, April 26, 2000 12:44 PM

      To: sip@lists.bell-labs.com; 'Chip Sharp'

      Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in =
SIP

      

      

      


      There will =
defintely be a need to consider interworking between SIP(-T) and BICC, =
but whether this should be done by this group or ITU-T SG11, I am not =
so sure about.
      


      I do not think we =
need to carry BICC inside SIP-T though. BICC is basically ISUP with =
extensions for controlling an IP or ATM bearer. SIP-T can already =
control IP/ATM bearers using SDP so it wouldn't make sense to carry the =
extra BICC stuff as well. It should instead be interworked to the =
equivalent SIP mechanism for setting up the bearer.
      


      I expect there will =
be discussions on this kind of issue at the next SG11 meeting on BICC =
(1-5 May). 

      


      Regards, 

      


      Mark =
Watson 

      Nortel Networks, =
UK 

      


              ---------- 

      From: =A0 Chip =
Sharp 

      Sent: =A0 Monday, April =
10, 2000 1:27 pm 

      To: =A0=A0=A0 sip@lists.bell-labs.com =


      Subject: =A0=A0=A0=A0=A0=A0 [SIP] Carrying Q.BICC as an Mime-type in =
SIP 

      


              ITU (SG11) is currently defining a variant of ISUP that =
is being called=20

      "Bearer Independent Call =
Control" (BICC).=A0 I'm sure many of you are aware=20

      of this. =


      


              They have completed work for Q.BICC to handle Narrowband =
ISDN services over=20

      ATM (this is now numbered Q.1901) and =
they are now beginning work on IP and=20

      other networks. 

      


              It seems that networks using SIP will have to interwork =
with these networks=20

      as well as the current PSTN that uses =
ISUP. 

      


              Could (or should) this be included in the SIP-T =
draft?=A0 Would it be its own=20

      type or could/should it be included =
as a value for the version or spec field? =


      


              Chip 

      http://www.netaid.org 

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

      Chip =
Sharp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CTO Consulting =
Engineering 

      Cisco Systems 

      Reality - Love it or Leave it.=A0 =
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=20

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

      

      

      


              _______________________________________________ 

      SIP mailing list 

      SIP@lists.bell-labs.com 

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

      

      




------_=_NextPart_001_01BFB035.7A92B154--


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 10:38: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 KAA01142
	for ; Thu, 27 Apr 2000 10:38: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 E971744338; Thu, 27 Apr 2000 10:33:34 -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 25AE944336
	for ; Thu, 27 Apr 2000 03:57:30 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 27 04:00:18 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 245DE44345; Thu, 27 Apr 2000 03:47:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id F06B444341
	for ; Thu, 27 Apr 2000 03:47:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 829EB52BB; Thu, 27 Apr 2000 03:47:07 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id B47FE52B6
	for ; Thu, 27 Apr 2000 03:47:04 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Apr 27 03:46:31 EDT 2000
Received: from mailgate.lgcit.com ([150.150.83.41]) by dusty; Thu Apr 27 03:46:30 EDT 2000
Received: (from root@localhost)
	by mailgate.lgcit.com (8.9.3/8.9.3) id QAA21978
	for sip@lists.research.bell-labs.com.procmail; Thu, 27 Apr 2000 16:57:30 +0900 (KST)
Received: from mail.lgcit.com (mail.lgcit.com [150.150.64.170])
	by mailgate.lgcit.com (8.9.3/8.9.3) with ESMTP id QAA21968
	for ; Thu, 27 Apr 2000 16:57:29 +0900 (KST)
Received: from mail.lgcit.com (leslie.lgcit.com [150.150.87.76]) by mail.lgcit.com (8.8.8/8.8.8) with ESMTP id QAA02134 for ; Thu, 27 Apr 2000 16:41:35 +0900 (KST)
Message-ID: <3907F02B.CFD2005D@mail.lgcit.com>
Date: Thu, 27 Apr 2000 16:45:47 +0900
From: Dohoon Kim 
Reply-To: leslie@lgcit.com
Organization: Networked Multimedia, Innovation Center, LGCIT
X-Mailer: Mozilla 4.51 [ko] (Win95; I)
X-Accept-Language: ko,en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Subject: [SIP] Question in draft-ietf-call-flows-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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

at F5  in page 61 User B sends "486 Busy Here" response to Proxy 2, but
does not add tag value at To header field.

Then at F6 Proxy 2 sends ACK to UserB with tag value "314159"

Is this correct?





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


From sip-admin@lists.bell-labs.com  Thu Apr 27 10:39: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 KAA01206
	for ; Thu, 27 Apr 2000 10:39: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 323E444345; Thu, 27 Apr 2000 10:33:40 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 3F56344336
	for ; Wed, 26 Apr 2000 21:53:32 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 26 21:56:20 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id C1D8E44344; Wed, 26 Apr 2000 21:43:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 8BC1444341
	for ; Wed, 26 Apr 2000 21:43:10 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3B47952BB; Wed, 26 Apr 2000 21:43:09 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 3451D52B6
	for ; Wed, 26 Apr 2000 21:43:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Apr 26 21:41:24 EDT 2000
Received: from kevlar.softarmor.com ([63.64.250.82]) by dusty; Wed Apr 26 21:41:22 EDT 2000
Received: from dwillis (dwillis2.directlink.net [63.64.250.83])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id HAA11158
	for ; Thu, 27 Apr 2000 07:42:57 -0500
Message-ID: <00cd01bfafe9$b8b9fa60$53fa403f@directlink.net>
From: "Dean Willis" 
To: "IETF SIP" 
Date: Wed, 26 Apr 2000 20:40:41 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [SIP] Draft minutes, SIP WG IETF 47
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


Minutes primarily taken from notes of Tom Taylor, who once again
volunteered his indispensable sevices in this heroic effort. Thanks.

These are the minutes of the SIP WG at the 47th IETF in Adelaide.  The
WG met for two sessions, Monday morning and Tuesday afternoon.

1. Agenda Bashing
=================

The proposed agenda was accepted.  Presenters from Kyoto University
asked to be added to the agenda.  The request was denied because their
draft had not been submitted in time to be published by the IETF.

2. Status
=========

Dean Willis presented a summary of status of the WG work items,
followed by a brief discussion of potential charter items. There was
discussion as to whether the DCS drafts would be considered for
adoption by the WG. The current drafts still have RFC2026 complienace
issues preventing WG adoption as work items, but these issues may soon
be resolved. The general consensus seems that several of the DCS
drafts are likely to be adopted once the IPS is resolved.


The WG indicated consensus to adopt several tasks as chartered WG
activities, including:
SIP server features (standards track)
Call flows (informational)
Session Timer (standards track)
Reliability of provisional messages (standards track)
SIP-T efforts:
ISUP MIME types (standards)
ISUP mapping (undetermined)
Single Line Extension (undetermined)
Guidelines for Extensions.


As a general note regarding the management of the work of the WG:
Jonathan Rosenberg is attempting to assemble teams around specific work
items, with the proviso that individual participants should not be
over-committed.  The "single line extension" team is an example of this.



3. Summary of Current Discussion On The List
============================================

Jonathan Rosenberg summarized the status of discussion of a number of
current issues.

3.1 draft-nair-sip-dhcp-00.txt

No issues have been raised on the list, nor comments received from the
DHCP WG.  The fast-track procedure applied to this work appears to be
acceptable to the SIP WG.

3.2 Content In INVITE

Discussion in late December of how to include of content such as JPEG
images in INVITEs brought out a number of points:
 -- whether to include the actual content, include it indirectly through
provision of a URI, or include it indirectly as a media stream
 -- location of the content, in a header or in the body
 -- the need to identify how the content is to be used.
Jonathan perceived no consensus on these items, due to lack of comment
on specific proposals made to the list.


3.3 WWW-Authenticate Syntax

There is a proposal before the list, but no comments have been received.

3.4 tel:// vs. sip:// URLs

Jonathan emphasized the importance of the issue, discussion of which has
stalled.  He would like to see a new push to resolve it.

3.5 URL Parameters For Telephone Numbers

A couple of issues have been discussed under this heading: how to
indicate that the number shown is the result of an LNP lookup, and how
to indicate private dialing plans.  Again, Jonathan would like to see
a renewed effort to resolve these issues.

3.6 To Quote Or Not To Quote: Digest-URI

Robert Sparks commented that most implementations use quotes around the
digest-URI.  Usage for other fields is variable.  He suggests that all
fields be quoted.

3.7 Re-INVITE Glare

Jonathan noted that three proposals are on the table for handling of
coincident re-INVITEs.  Scott Petrack noted the need for a solution that
works with more than two parties.  Jonathan responded that SIP states
are shared only on a per-call-leg basis, except possibly in the case of
multicast, so multileg coincidental invites may not be an issue.

[A couple of points in Jonathan's charts were skipped because they are
being considered by the SIP security task force.]

3.8 When To Send 183 Response

Jonathan presented the rules for use of the 183 response which had come
out of discussion on the list.  A brief discussion followed, in which a
problem with the first rule was noted and resolved.

3.9 Overlap Dialling

Jonathan noted that there was no easy solution to the possibility of
forking for a call in which overlap dialling is being used.  David Oran
suggested that when the gateway rejects the first call, it should return
a contact which redirects all subsequent INVITEs to the same gateway.
Jonathan noted that this changed the meaning of the Contact: header
slightly, but its usage remains within acceptable bounds.

3.10 Early Media Criticality

Jonathan noted a continuing unresolved issue of how to distinguish
between critical and non-critical early media.

In general Jonathan intends to put out notes to the list to stimulate
further discussion of the open issues.

4. Status Of I-Ds (Jonathan Rosenberg)[charts]
======================================

4.1 Caller Preferences
 (draft-ietf-sip-callerprefs-01.txt)

Jonathan summarized a number of changes in the current draft.  There
have been no objections to the use of case-sensitive matching.  The
draft is due to go to the IESG, but Jonathan is looking for volunteeers
to check it out first.

4.2 Supported: Header
 (draft-ietf-sip-serverfeatures-02.txt)

The draft has undergone a major overhaul.  The one open point had to do
with use of the header with ACK.  This has been fixed and the draft has
been forwarded to the IESG.

4.3 Reliable Provisional Responses
 (draft-ietf-sip-100rel-00.txt)

A number of open issues still remain.
 -- cumulative acknowledgements: looking for an application to justify
inclusion of the mechanism
 -- response to PRACK: retain mechanism
 -- CANCEL for PRACK: disallow
We are looking to pass this document to the IESG as a Proposed Standard
by mid-April.

4.4 Guidelines For Authors Of SIP Extensions
 (draft-rosenberg-sip-guidelines-00.txt)


Jonathan proposed that this be a WG work item.  It would eventually
become a BCP, but not for another year.  For now it would be a living
document as the WG accumulates experience.  The sense of the meeting was
to adopt the work item, but there were mixed views on how quickly it
should be given formal status, with some arguing for near-term RFC
status.  This point will be taken to the list.  Jonathan has volunteered
to maintain the document if the WG chooses to make it a long-term
project as he proposes.

4.5 Third-Party Call Control
 (draft-rosenberg-sip-3pcc-00.txt)
This document has a number of dependencies, and various models of
control are possible.  In general the work does not involve an
extension to SIP, but only a description of the usage of its
mechanisms.  For this reason Jonathan does not propose that it be a WG
work item, but would like people to comment on it.

5. DCS Drafts
=============

5.1 Resource Reservation (Bill Marshall) [charts]
 (draft-manyfolks-sip-resource-00.txt)

This draft came about through the compromise merger of
draft-ietf-mmusic-qos-00.txt and draft-dcsgroup-sip-resource-01.txt.
The two-stage INVITE has been discarded.  SDP enhancements in support
of QOS and security negotiation include two new attributes (a=qos: and
a=security:), with syntax provided for confirmation that the requested
attribute values have been granted.  Extensions to SIP in support of
the negotiation of these attributes are covered in the same document
as the SDP changes, with AD approval. SIP extensions include use of a
header indicating that preconditions have been met.

The question was raised, whether there was any problem with using the
a=qos: attribute with provisional responses to allow the invitee to
set preconditions.  Bill made the point that the first user of the
attribute has to know whether the other end would understand it.

5.2 Caller Identity (Flemming Andreasen) [charts]
 (draft-dcsgroup-sip-privacy-01.txt)

Flemming summarized changes in the draft.  Earlier work has been
extended to recognize the possibility of boundaries between
proxies. In geneal, rather than requiring a nounary proxy to remove
calling party information, any proxy may encrypt the field and list
itself as an authenticator.  A new header, "Remote-Party-ID", has been
defined.  The set of possible operator services has been generalized.

Scott Petrack suggested that a specific tag for operator services might
not be in the spirit of SIP.  Jonathan agreed that an alternate approach
might be possible.  The basic idea, as always in SIP, is to define a
small set of reusable features rather than a variety of specialized
ones.

5.3 Distributing Call State (Bill Marshall) [charts]
 (draft-dcsgroup-sip-state-01.txt)

The mechanism has changed completely since the previous draft, in an
attempt to make it more general.  The draft now takes care to
distinguish between transaction state, connection state, and call
state.  The rules for including the "State" header have been
simplified.  There was a comment to the effect that the state
information must include the information necessary to ensure that it is
not used for a different call from the one which generated it.

5.4 Proxy-to-Proxy Extensions (Mike Mannette) [charts]
 (draft-dcsgroup-sip-proxy-proxy-01.txt)

Mike reviewed the changes from the previous draft.  LNP support has been
provided and hostport is now a required field in the "Gate" header.  The
"Billing-Info" and "Billing-Id" headers are unchanged.

5.5 Media Authorization (B. Beser) [charts]
 (draft-dcsgroup-sip-call-auth-01.txt)

This draft addresses the need for a per-call mechanism to authorize the
flow of media.  The new draft has been changed to focus only on the
client.  The former "DCS-Local-Gate" header has been renamed to
"Media-Auth".  The content has been generalized to hexadecimal.

6. Subscribe-Notify (Adam Roach)
==========================================
 (draft-roach-sip-subscribe-notify-00.txt)

Motivation: there is a need for a central definition of concepts which
have been mentioned in various documents.

The draft formalizes the methods and headers associated with
subscription and notification.  Distinctions are made between
call-related and resource-related subscriptions, with the latter
typically being of interest to third parties.  Rules are set down for
notifications and for duration of subscriptions.  The author attempted
to avoid disruption to PINT, but it might be possible to combine the
PINT work with this new material.

Scott Petrack noted that PINT had spent a great deal of time working
to make their mechanisms sufficiently generic.  He urged Adam to
review the PINT archives.  Unsubscription proved to be a tricky topic,
and PINT found it preferable to list events in bodies rather than in
headers.  Scott and Adam will discuss this further off-line.

Henry Sinnreich asked what measures had been taken to coordinate with
the Instant Messaging and Presence (IMPP) WG.  Jonathan replied that
IMPP is addressing a different problem and had already judged SIP to
be unsuitable for their purposes.  He also recalled that a general
subscription/notification BOF was held, but nothing came out of it
because the problem was too broad.

Scott Petrack noted that PINT will change if necessary to conform to
SIP.

An example subscription/notification service was presented, where the
caller is rung back when the callee becomes free.  There are open issues
where further work is required.  Jonathan proposed that another task
force be set up on the Egroup mail server, to refine the problem
statement.

Michael Thomas questioned whether SIP really needed an asynchronous
method of completing a call when the current protocol can support a
blocking approach.

7. Mobility (S. Baba) [charts]
=========================
 (draft-itsumo-sip-mobility-req-00.txt)

The draft provides requirements, open issues, and relevant work items
in SIP and other WGs.  The requirements are organized on a functional
basis.

Addressing the charts, Lawrence Conroy asked what was meant by the
requirement to "utilize" CDMA soft hand-off.  He saw this as invisible
at the IP level.  The presenter pointed out that the process might
involve multiple IP addresses for the same UA.  This would represent a
major extension to SIP.

James Polk noted that the forthcoming Location Information BOF might
be relevant to this problem.

[end of first session]

8. Review Of Charter Work Items  (Dean Willis) [charts]
===============================

Dean asked for comments on the proposed work items before the WG
chairs reviewed them and passed the results of the review on to the
list.  There were no comments.

9. INFO Method, Session Timer, 183 Session Progress (Steve Donovan)
[charts]
===================================================

9.1 INFO Method

Work on the INFO method, draft-ietf-sip-info-method-01.txt, is basically
done.

9.2 Session Timer

The Session Timer draft (draft-ietf-sip-session-timer-01.txt) underwent
significant change to reflect the new "Supported" header.  Some issues
remain before WG Last Call:
 -- refreshing of the timer.  Jonathan suggested that this be done by
re-INVITE, rather than a new method.  Agreed.
 -- Session-Expires header problematic in anything but INVITE -- will be
allowed with INVITE only.
 -- Can a proxy add Required headers? -- could end up with multiple
Required headers if the UAC also includes one.  This doesn't seem to
break anything, but there is an interaction with authorization.  In the
absence of comment from anyone but Jonathan, this should be checked out
on the list.
 -- the question was asked: what happens if the called UA includes
Session-Expires with a re-INVITE and it contradicts the one set by the
calling UA?  Steve suggested that it would be up to the implementation
to sort this out.  The list will be invited to comment.

Next steps:
 -- agreed that this becomes an official WG work item
 -- submit shortly to WG Last Call.

9.3 183 Session Progress

draft-ietf-sip-183-00.txt has a lot of dependencies, resulting in
improved understanding of the issues.  It may be used for early media
and for pre-conditions.  Summarizing the extensions involved:
 -- full session description bodies in 18x responses
 -- add the 183 response
 -- provide the "Session" header to indicate the purpose of the session
description body
The first two items are in 2543 bis already.

It is proposed that the Session header draft be refined to narrow its
focus, taking advantage of the 183 documentation.

10. Call Control (Robert Sparks) [charts]
================================

10.1 Framework For Call Control Extensions
 (draft-campbell-sip-cc-framework-00.txt)

Needs to be aligned with the guidelines.

10.2 Call Transfer
 (draft-sparks-sip-cc-transfer-00.txt)

Proposes a new TRANSFER method (not BYE ALSO), which does not alter the
original session.  Open issues:
 -- name of the method.  Jonathan interjected that he does not want to
build protocols for specific services, hence the method should have a
more abstract name and definition. Dean Willis suggested "Introduce".
 -- whether the method can carry bodies
 -- authentication.  Dean Willis suggested an "Introduced-By" header,
signed by the transferor.

10.3 Service Context -- Use of the SIP Request URI
 (draft-campbell-sip-service-control-00.txt)

This is an informational draft proposing the transmission of service
context through use of a distinctive Request-URI.  Robert provided an
example application and described the advantages of the mechanism.

David Oran was unclear on the intent of the work.  He noted that it
takes the opposite approach to that of HTML, by using the left side of
the URL rather than the right.  The syntax conflict could make the
result different depending on the server. Dean Willis pointed out that
SMTP also uses the left hand side, and that web URLs lack the @ and
therefore HAVE no left hand side.

Robert responded that the URL is intended to be an opaque entity bound
as a whole against a particular service.  David agreed that under these
conditions the format was acceptable.

The work was accepted as a Working Group Informational work item.

10.4 Call Flow Examples (Presentd by Robert Sparks)
 (draft-ietf-sip-call-flows-00a.txt)

The draft has had a number of updates.  Please forward any further flows
to Alan Johnston (alan.johnston@wcom.com).

Jonathan noted that the document is getting too large to handle easily.
He proposes to farm out subsections to volunteers to review.  Ideally
they should simulate the flows to validate them.  Alan Johnston will
coordinate the work.

There is an issue with dependencies on work in progress.  The document
will be partitioned so that the stable part is processed first.

11. IETF SIP MIB (David Walker)
 (draft-ietf-sip-mib-00.txt)

Issue: the document is 70 pages long.  Can this be reduced?  It covers
RFC 2543 plus the INFO method and the 183 response.  Items are defined
within configuration, statistics, and notification groups for each of
the UAC, UAS, proxy, registrar, and redirect server, except that
elements common to all of these are grouped separately.  (Nothing has
been defined as yet to be specific to the redirect server.)

Concern: too many measurements.  Discussion of this brought out the
following:
 -- measurements should be defined only if there is a stated use for
them
 -- they are used as a troubleshooting tool, but a message history tool
would do a better job
David will send a note to the list to provoke further discussion.
Comments on how measurements are used will be welcome.  The note will
also raise a number of other questions for comment.

The current draft contains a couple of known errors.

12. BCP For SIP to ISUP Mapping (Gonzalo Camarillo) [charts]
 (draft-camarillo-sip-isup-bcp-00.txt)

This draft covers requirements, call flow examples, and the mapping of
parameters between the two protocols.  Gonzalo went over the changes to
the draft:
 -- new name
 -- additional extension: umbrella REQUIRE
 -- refinement of scope
 -- a discussion of SIP bridging between ISUP networks
 -- corrections to the handling of overlap signalling
 -- added examples.

He presented a walk-through of the overlap signalling case.  There is a
lot of messaging, but, unlike in the previous draft, it works.  There is
an open issue of how to control routing of overlap signalling in the
case of a stateless proxy forwarding to loadsharing MGCs.

A question was asked: how is connection redundancy handled -- for
example, UA multihoming.  What if the successive messages arrive at
different answers.  The reply was that this issue was out of scope of
the draft.  Jonathan remarked that SCTP transport for SIP is a topic
for the future.

Gonzalo concurrently presented a report on the status of the SIP-T
work.  It was noted that of the SIP-T work, the highest priority is to
obtain approval of the ISUP MIME types document. This is currently
planned for May 2000.

13. SIP Mapping Of MLPP (James Polk) [charts]
 (draft-polk-sip-mlpp-mapping-00.txt)

There is a mismatch between SIP "priority" levels and MLPP levels.
The draft proposals are to add a level and add administrative hooks.
Jonathan remarked that the standard is not the place to specify the
administrative hooks -- they belong in an RFP.

Subsequent discussion brought out two points:
 -- added priority level in RFC 2543bis
 -- additional document describing operation of MLPP.  This would cover
a number of items besides SIP, so it should not be a SIP WG document.

Jonathan also wondered whether MLPP really impacts SIP except at the
gateway, since it is concerned with preemption of limited call
resources in the face of higher-priority demand and IP resources are
not so obviously limited as circuits.  Brian Rosen disagreed, pointing
out that MLPP is not only about preeemption.

The outcome of the discussion was consensus to discuss adding another
priority level to 2543bis, or possibly adding "token" to the grammar
allowing arbitrary extension. This will require list review. James
Polk may submit a detailed fraft showing how the SIP priority levels
can be used to implement MLPP requirements.


14. Update On ISUP MIME Types (Lyndon Ong)
 (draft-ong-sip-qsig-mime-00.txt)

The draft has one open issue: the amount of ISUP version information
required. Followup is occuring in the SIP-T subteam and will be
reviewed on the main list when ready.

15. SIP and QOS (Henry Sinnreich) [charts]
 (draft-sinnreich-sip-qos-osp-01.txt)

Henry presented a list of "to do" items associated with the work.  He
hypothesized that a new WG may be required.  As evidence of this he
cited the need for a framework, within which different QOS models might
operate.

Radhika Roy mentioned that ITU-T Study Group 16 is also doing QOS work,
and the two groups could share their results.  Henry agreed that this
was possible.

Patrice Calhoun asked about the relationship between QOS and OSP (Open
Settlement Protocol, which appeared on Henry's charts).  Henry indicated
that OSP was relevant because it supports the clearing house model of
settlements, and the latter differs from the AAA WG model.

Melinda Shore remarked that overall (thinking also of DCS) there seemed
to be some strange QOS work going on, driven by charging models.  Hooks
within SIP are in scope for SIP WG discussion, but the general topic of
QOS for VoIP is out of scope.

Continuing in his presentation, Henry presented call flows showing the
tight coupling between signalling, QOS, and AAA.

Jonathan remarked again that ONLY changes required to SIP are within
the SIP WG's scope.

Dave Oran observed that DCS covers the "push model" of QOS: policy is
pushed to the enforcement point.  There is a need to develop a system
for the pull model, with open security issues standing in the
way. Dave proposed COPS-PR for this role.

Dean Willis suggested that perhaps the Transport Area WG could tackle the
larger problem.  Jonathan proposed discussing the matter with the ADs.

16. SIP Through Firewalls and NATs (Jonathan Rosenberg) [charts]
 (draft-rosenberg-sip-firewalls-00.txt)

Jonathan noted that the topic of firewall/NAT traversal is being covered
by the foglamps BOF.  The question is whether the SIP WG wants to do an
Informational RFC on the specific topic of SIP operation through these
barriers.

Dean Willis suggested that the question of whether this work belongs
in SIP is of the same order as whether MLPP does -- that is, both are
enablements for SIP within specific sectors.

There was a weak hum in favour of the work item.

17. Usage of TRIP For Gateway Registration (Jonathan Rosenberg)
 (draft-rs-trip-gw-00.txt)

This was simply an alert to the topic, which had been raised in the
meeting of the IPTEL WG the previous day.

18. Transferring User Control Information In SIP REGISTER Payloads
(Jonathan Rosenberg)
 (draft-lennox-sip-reg-payload-00.txt)

We need a way to pass scripts from the client to the server.  This
draft is the same as the original version a year ago, with minor
changes.  There are several open issues.  Jonathan asked "Should this
be a SIP work item?", which started a lively discussion.

Radhika Roy suggested there was a relationship to and potential impact
on mobility; Jonathan disagreed.  Lawrence Conroy wondered how the
scripts would be authenticated.  Dean Willis mentioned several
approaches that have been suggested.

Dean put the question: "even with the other alternatives, is it useful
to do this function via REGISTER?"  There was a slight hum in favour,
no opposition, with most registering no opinion.  The work was
accepted subject to approval on the list.

19. Finding A SIP Server With SLP (James Kempf)
 (draft-kempf-sip-findsrv-00.txt)

The intention is to add a template to the IANA service type registry.

Motivation: there are several ways to locate a SIP server through DNS --
for example, by use of a naming convention.  The method presented allows
location by characteristics.  This is useful because different proxies
in a domain can have different characteristics.  The approach taken is
to have one SLP abstract service type: "service-sip", with two concrete
service types.

Jim presented an example: find a registrar supporting CPL.

An open issue is how to handle incoming calls.  With other methods of
DNS usage, one can parse down the hierarchy of server names.  With SLP
it may be necessary to use SIP forking or multicast.

Should this be a WG work item or an individual draft?  IANA approval
requires RFC documentation and approval by Eric Guttman (servloc
Chair).  Comments on the draft can go to Jim directly or to the list.

Jonathan noted that this is one of many possible methods, but that's
OK.  There is certainly no point in discussing whether this work
should go forward as opposed to some other approach. The consensus was
to not adopt this as a WG task at this time, but to follow the work as
it matures and reconsider at a futue point.

20. CGI Interface (Jonathan Rosenberg)
 (draft-lennox-sip-cgi-03.txt)

The draft is being cleaned up.  A couple of issues have been resolved.
There are alternative methods for transfer of the CGI scripts. There
appears to be no intent to make this a WG item at this time.

21. Distributed Multipoint Conferences Using SIP (Jeff Mark) [charts]
 (draft-mark-sip-dmcs-00.txt)

Jeff provided some examples, showing manipulation of full mesh
conferences.  Is there SIP interest in further such full mesh work?

Jonathan noted that conference control is not part of the SIP WG mandate.
The problem of topology management is overly complicated because call
control should be separated from link state propagation.  The latter is not
something SIP is good at.

Jonathan will organize a first pass at rearchitecting the proposal,
but there are other approaches to multi-party conferencing that may prove
worth discussing.


--
Dean Willis
dwillis@greycouncil.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 Apr 27 10:41: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 KAA01303
	for ; Thu, 27 Apr 2000 10:41: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 7E2B54433A; Thu, 27 Apr 2000 10:33: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 F10AD44336
	for ; Tue, 25 Apr 2000 15:10:00 -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 OAA09106;
	Tue, 25 Apr 2000 14:11:38 -0500
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <2FJKFBC7>; Tue, 25 Apr 2000 14:07:18 -0500
Message-ID: 
From: "Culpepper, Bert" 
To: James Kempf , schulzrinne@cs.columbia.edu
Cc: hiren.shah@wipro.com, sip@lists.bell-labs.com, brosen@fore.com,
        mjh@aciri.org, nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: RE: [SIP] SIP and network element signalling (formerly: (no subje
	ct) )
Date: Tue, 25 Apr 2000 14:07:16 -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:  
X-BeenThere: sip@lists.bell-labs.com

If those of us in the telecommunications industry are going to embrace SIP
as a signaling protocol (as it appears we have), we are going to have to
find ways to do the things in the IP network that we've done in the
circuit-switched network (and wireless network).  The use of the SIP INFO
method, along with new MIME Type proposals, for ISUP and QSIG "tunneling"
appears to be generally endorsed.  It was defined as a solution to providing
much of the circuit-switched network functionality in a SIP network.  I may
be wrong, but the intention of the authors of the SIP INFO ID appears to be
for its use in solving many outstanding issues with converging the
circuit-switched network with packet networks.

Extending (where appropriate) and using existing protocols is preferable to
defining new ones in my opinion.  I do not want to see the INFO method
become a catch-all though.  Obviously, more thought and work is needed to
bring about interoperability between the two telecommunications network with
the IP network.

Regards,
Bert

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Tuesday, April 25, 2000 12:35 PM
> To: James.Kempf@eng.sun.com; schulzrinne@cs.columbia.edu
> Cc: hiren.shah@wipro.com; sip@lists.bell-labs.com; brosen@fore.com;
> mjh@aciri.org; nara@syndeocorp.com; mauricio.arango@eng.sun.com
> Subject: Re: [SIP] SIP and network element signalling (formerly: (no
> subject) )
> 
> 
> >
> >It might be helpful to describe those things that are different for
> >"network element" signaling and what information needs to be
> conveyed. I
> >don't see (yet) why this needs to be a hack, but I would stay away
> from
> >"let's just use the INFO hammer" approach.
> >
> 
> The particular ones I've encountered so far in my work with IS-41 are:
> 
> 1) Paging a cell phone that currently doesn't have an ongoing call
> and might even be in standby mode.
> 
> 2) Having an IP-based phone obtain authentication credentials from a
> network 
> authentication server, which may also function as a SIP proxy/call
> agent, to
> allow the IP-based cell phone to authenticate INVITEs as having
> come from a valid source.
> 
> 3) Allowing the call agent to request a list of features (tones
> and announcements) from its home service database for delivery to the
> mobile 
> terminal (FeatureRequest in IS-41). Athough this message would most
> likely be 
> encountered during setup or execution of a call (when the INFO method
> could be
> used), it may occur outside of that context and it will require
> communication 
> between two network elements, one of which (the home service database)
> is not 
> involved in routing the call.
> 
> There are likely to be others. 
> 
> >I wouldn't read too much into a protocol name. This is more of a
> >historical accident than a political platform. As far as I can tell,
> SIP
> >should be able to handle the tasks typically done by signaling
> >protocols. It is not a multimedia transport protocol such as RTP or a
> >replacement for email or ftp.
> 
> Using SIP or enhancing it if necessary is certainly an attractive
> option.
> I'm a bit concerned that the INFO method might become a catchall, in
> which people start dumping in signalling information in a
> uncoordinated
> manner. 
> 
> Perhaps an auxillary protocol, like, SDP for the INFO method would
> work,
> along with opening up the use of INFO between network elements when
> a call is not in progress (currently it is only defined for when
> a call is in progress).
> 
> 		jak
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 27 10:42: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 KAA01324
	for ; Thu, 27 Apr 2000 10:42:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 33EF84434E; Thu, 27 Apr 2000 10:33:48 -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 73BD344336
	for ; Wed, 26 Apr 2000 10:24:05 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20732;
	Wed, 26 Apr 2000 08:27:45 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14680;
	Wed, 26 Apr 2000 07:27:44 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA20806;
	Wed, 26 Apr 2000 07:26:49 -0700 (PDT)
From: Mauricio Arango 
Message-Id: <200004261426.HAA20806@nasnfs.eng.sun.com>
Date: Wed, 26 Apr 2000 10:30:22 -0400
To: "Henning Schulzrinne" ,
        "James Kempf" 
Cc: , , ,
        , , 
Reply-To: 
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
X-Mailer: Sun NetMail 2.3
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

>> 
>> 1) Paging a cell phone that currently doesn't have an ongoing call
>> and might even be in standby mode.
>
>Paging to initiate a call? Why is this different from an INVITE?
>

Not necessarily to initiate a call but to find the location (cell) of the 
station, or obtain other station information before the call is made. 

I think one of the points Jim is making is that if INVITE is used for both 
these type of queries and for initiating a call, there doesn't seem to be
a way in SIP to tell a station or any other element to treat INVITEs used
for different purposes in a different way. A possibility could be a SIP
pre-call query method.


Mauricio

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

>
>
>James Kempf wrote:
>> 
>> >
>> >It might be helpful to describe those things that are different for
>> >"network element" signaling and what information needs to be conveyed. I
>> >don't see (yet) why this needs to be a hack, but I would stay away from
>> >"let's just use the INFO hammer" approach.
>> >
>> 
>> The particular ones I've encountered so far in my work with IS-41 are:
>> 
>> 1) Paging a cell phone that currently doesn't have an ongoing call
>> and might even be in standby mode.
>
>Paging to initiate a call? Why is this different from an INVITE?
>
>> 
>> 2) Having an IP-based phone obtain authentication credentials from a network
>> authentication server, which may also function as a SIP proxy/call agent, to
>> allow the IP-based cell phone to authenticate INVITEs as having
>> come from a valid source.
>
>I assume that public key mechanisms are not acceptable?
>
>> 
>> 3) Allowing the call agent to request a list of features (tones
>> and announcements) from its home service database for delivery to the mobile
>> terminal (FeatureRequest in IS-41). Athough this message would most likely be
>> encountered during setup or execution of a call (when the INFO method could
>be
>> used), it may occur outside of that context and it will require communication
>> between two network elements, one of which (the home service database) is not
>> involved in routing the call.
>
>Might help to define 'call agent', as I'm not sure I have the same
>understanding of this term as you might. Sounds like an OPTIONS request
>to me, but then I'm not sure how 'tones and announcements' fit into
>this, as that sounds like media, not signaling.
>
>> 
>> There are likely to be others.
>> 
>> >I wouldn't read too much into a protocol name. This is more of a
>> >historical accident than a political platform. As far as I can tell, SIP
>> >should be able to handle the tasks typically done by signaling
>> >protocols. It is not a multimedia transport protocol such as RTP or a
>> >replacement for email or ftp.
>> 
>> Using SIP or enhancing it if necessary is certainly an attractive option.
>> I'm a bit concerned that the INFO method might become a catchall, in
>> which people start dumping in signalling information in a uncoordinated
>> manner.
>
>I share your concern - INFO should be used very sparingly. There is no
>cost in SIP in defining new methods, for example, which allows one to
>express what actually is meant rather than somehow being implied in the
>body or a collection of headers.
>
>> 
>> Perhaps an auxillary protocol, like, SDP for the INFO method would work,
>> along with opening up the use of INFO between network elements when
>> a call is not in progress (currently it is only defined for when
>> a call is in progress).
>> 
>>                 jak
>> 
>> _______________________________________________
>> SIP mailing list
>> SIP@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/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 Apr 27 10:44:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01352
	for ; Thu, 27 Apr 2000 10:44: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 C98FF44341; Thu, 27 Apr 2000 10:33: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 AB44E44336
	for ; Wed, 26 Apr 2000 06:38: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 GAA22732;
	Wed, 26 Apr 2000 06:42:54 -0400 (EDT)
Message-Id: <200004261042.GAA22732@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, 26 Apr 2000 06:42:54 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-dhcp-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:  
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		: DHCP Option for SIP Servers
	Author(s)	: G. Nair, H. Schulzrinne
 	Filename	: draft-ietf-sip-dhcp-01.txt
	Pages		: 5
	Date		: 07-Apr-00
	
This document defines a DHCP option that contains a pointers to one
or more SIP servers. This is one of the many methods that a SIP
client can use to obtain the addresses of a local oubound SIP server.

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

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

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

Content-Type: text/plain
Content-ID:	<20000425113849.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 Apr 27 10:45: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 KAA01399
	for ; Thu, 27 Apr 2000 10:45: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 4158644359; Thu, 27 Apr 2000 10:33:58 -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 F1DE344336
	for ; Thu, 27 Apr 2000 10:29:39 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18202;
	Thu, 27 Apr 2000 08:33:54 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25809;
	Thu, 27 Apr 2000 07:33:53 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA06015;
	Thu, 27 Apr 2000 07:32:32 -0700 (PDT)
From: Mauricio Arango 
Message-Id: <200004271432.HAA06015@nasnfs.eng.sun.com>
Date: Thu, 27 Apr 2000 10:36:25 -0400
To: "Henning Schulzrinne" ,
        
Cc: , , ,
        , "James Kempf" 
Reply-To: 
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
X-Mailer: Sun NetMail 2.3
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:  
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Henning Schulzrinne wrote:
>What about just using OPTIONS? It is a query method that gets routed in
>the same way that other SIP requests, such as INVITE, would be.
>
>

Yes, OPTONS would work.


Mauricio
--------------------------


>Mauricio Arango wrote:
>> 
>> >>
>> >> 1) Paging a cell phone that currently doesn't have an ongoing call
>> >> and might even be in standby mode.
>> >
>> >Paging to initiate a call? Why is this different from an INVITE?
>> >
>> 
>> Not necessarily to initiate a call but to find the location (cell) of the
>> station, or obtain other station information before the call is made.
>> 
>> I think one of the points Jim is making is that if INVITE is used for both
>> these type of queries and for initiating a call, there doesn't seem to be
>> a way in SIP to tell a station or any other element to treat INVITEs used
>> for different purposes in a different way. A possibility could be a SIP
>> pre-call query method.
>
>What about just using OPTIONS? It is a query method that gets routed in
>the same way that other SIP requests, such as INVITE, would be.
>
>
>-- 
>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 Apr 27 10:47:03 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01429
	for ; Thu, 27 Apr 2000 10:47:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 73E3E4435D; Thu, 27 Apr 2000 10:34:02 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id A538D44336
	for ; Thu, 27 Apr 2000 04:15:29 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 27 04:18:23 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 9C3D344344; Thu, 27 Apr 2000 04:05:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 7612F44341
	for ; Thu, 27 Apr 2000 04:05:14 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 23A5552BB; Thu, 27 Apr 2000 04:05:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5DA6C52B6
	for ; Thu, 27 Apr 2000 04:05:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Apr 27 04:03:37 EDT 2000
Received: from smtp1.cluster.oleane.net ([195.25.12.16]) by dusty; Thu Apr 27 04:03:36 EDT 2000
Received: from oleane  (dyn-1-1-092.Vin.dialup.oleane.fr [195.25.4.92])  by smtp1.cluster.oleane.net  with SMTP id KAA47954 for ; Thu, 27 Apr 2000 10:03:35 +0200 (CEST)
Message-ID: <006901bfb01e$59503780$0401a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Thu, 27 Apr 2000 09:58:17 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0066_01BFB02F.1C7D7A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] SIP International Conference
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id:  
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

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

Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm


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











Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. 


Visit the SIP 2000 International Conference programme:


http://www.upperside.fr/basip.=
htm


 


------=_NextPart_000_0066_01BFB02F.1C7D7A00--




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


From sip-admin@lists.bell-labs.com  Thu Apr 27 11:24:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02176
	for ; Thu, 27 Apr 2000 11:24:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4CBE944337; Thu, 27 Apr 2000 11:20:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A423244336
	for ; Thu, 27 Apr 2000 11:19:57 -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 LAA19709;
	Thu, 27 Apr 2000 11:25:41 -0400 (EDT)
Message-ID: <39085E09.C6F2AA73@dynamicsoft.com>
Date: Thu, 27 Apr 2000 11:34:33 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Benny Prijono 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Session timer comments (2)
References: <3906CB2A.12DC455C@theseventhson.freeserve.co.uk> <3907D46C.5B6E1CAA@dynamicsoft.com> <39082801.353D24DF@theseventhson.freeserve.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



Benny Prijono wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Benny Prijono wrote:
> > >
> > > >From Session Timer draft dated March 2000 (page 5):
> > >
> > > ...
> > > For the first issue, ie. when the re-INVITE failed, I think the UAC
> > > should send the BYE immediately.
> >
> > What do you mean by failed? Generated a non-200 class response? In this
> > case, definitely not, since the re-INVITE can fail for legitimate
> > reasons, for which you don't want to hang up the call.
> >
> 
> Quite on the contrary, I think most of the time I will disconnect the
> call when non-200 response is received, because it just means
> something is wrong.

Thats not a good idea. Re-invites may fail for many reasons, including
the fact that the far side doesn't want to change the media session to
what was requested. For example, if the caller wants to add a video
stream, but the server doesn't.

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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 12:06: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 MAA02942
	for ; Thu, 27 Apr 2000 12:06: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 4DA3C44366; Thu, 27 Apr 2000 11:49:30 -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 D016044365
	for ; Thu, 27 Apr 2000 11:49:27 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 27 11:52:18 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id C25B544344; Thu, 27 Apr 2000 11:39:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 88D2644341
	for ; Thu, 27 Apr 2000 11:39:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 49DD252BB; Thu, 27 Apr 2000 11:39:07 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 62D5552B6
	for ; Thu, 27 Apr 2000 11:39:05 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Apr 27 11:39:00 EDT 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Apr 27 11:38:59 EDT 2000
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA19809;
	Thu, 27 Apr 2000 11:39:48 -0400 (EDT)
Message-ID: <39086157.7BFF038D@dynamicsoft.com>
Date: Thu, 27 Apr 2000 11:48:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: leslie@lgcit.com
Cc: sip@lists.research.bell-labs.com
Subject: Re: [SIP] Question in draft-ietf-call-flows-00.txt
References: <3907F02B.CFD2005D@mail.lgcit.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



Dohoon Kim wrote:
> 
> at F5  in page 61 User B sends "486 Busy Here" response to Proxy 2, but
> does not add tag value at To header field.

It should.

> 
> Then at F6 Proxy 2 sends ACK to UserB with tag value "314159"
> 
> Is this correct?

No; the UAC should not insert the tag into ACK. The 486 should have a
tag, and this should be mirrored in the ACK.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 12:11: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 MAA03057
	for ; Thu, 27 Apr 2000 12:11:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 12AD644373; Thu, 27 Apr 2000 11:55:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by lists.bell-labs.com (Postfix) with ESMTP id CBA4044364
	for ; Thu, 27 Apr 2000 11:55:24 -0400 (EDT)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id RAA24854 for ; Thu, 27 Apr 2000 17:58:59 +0200 (MET DST)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id RAA02316 for ; Thu, 27 Apr 2000 17:57:57 +0200 (MET DST)
Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id RAA19442
	for ; Thu, 27 Apr 2000 17:58:13 +0200 (MET DST)
Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it
          (Netscape Messaging Server 3.5)  with ESMTP id AAA5C2D;
          Thu, 27 Apr 2000 18:07:25 +0200
Message-ID: <390863D1.CE156E0B@italtel.it>
Date: Thu, 27 Apr 2000 17:59:14 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: James Kempf , hiren.shah@wipro.com,
        sip@lists.bell-labs.com, brosen@fore.com, mjh@aciri.org,
        nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004251632.JAA03455@nasnfs.eng.sun.com> <3906564C.9992B1E7@cs.columbia.edu>
Content-Type: multipart/alternative;
 boundary="------------F9C12536E4D125064035F794"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


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



Henning Schulzrinne wrote:

> James Kempf wrote:
> >
> > >
> > >It might be helpful to describe those things that are different for
> > >"network element" signaling and what information needs to be conveyed. I
> > >don't see (yet) why this needs to be a hack, but I would stay away from
> > >"let's just use the INFO hammer" approach.
> > >
> >

Henning,

I'd like to add another example where the need of an extention to SIP might be
analyzed.

I found your "Mobility support using SIP" paper very interesting.
I think it provides a very clear picture with respect to the scope of SIP (terminal)
mobility, what should be inplemented in SIP, what in L3, what in L2 and the
advantages of SIP mobility, in those cases where it should be applied.

However there are some (very important) scenarios  that are not covered by that
paper, and I didn't manage to figure out whether all the pieces needed to implement
them are already there/something should be added to SIP/another protocol should be
used.

Let' s assume that (for a some reasons that go beyond the technical aspects) we
always have at least 3 SIP proxies betwen two mobile endpoints. (Well, they may also
be something more complicated  than a proxy, but let's call them proxys now)

   * One proxy is in the "serving" domain: the domain where I' m currently
     registered
   * One proxy is in the "home" domain: the domain where I subscribed my mobility
     service
   * One proxy is in the "requesting" domain: the domain of the calling party

Let's now say that the terminal either changes its "serving" domain or, for some
reasons, wants to change its "serving proxy", within the same domain. Everything
happens without a call being in progress (therefore we cannot use the Info method)

What happens when the request to change the "serving proxy" comes

   * (a) from the terminal
   * (b) from the current serving proxy itself
   * (c) from the home proxy

In case (a), the terminal can send a REGISTER message to the new "serving proxy",
but then how is the "home proxy" notified of the change ?

In case (b), how does the "serving proxy" notify the terminal it has to re-register
with another proxy? Is the OPTIONS method appropriate ?

Aren't we misusing it?

Again, how is the "home proxy" notified of the change ?

In case (c), how are both the serving proxy and the terminal notified ?

In general, a call-unrelated signalling exchange might be required between the home
proxy, the current serving proxy, and the new serving proxy.

Does the SUBSCRIBE & NOTIFY mechanism (draft-roach-sip-subscribe-notify-00.txt)
cover all these cases? In particular:

   * the handover  mechanism must work independently of the existence of a call
     involving the same two entities. Call-related subscribe requests expire at the
     end of the call. The I-D mentions the possibilty (but only for a proxy ?) to
     issue a "third-party" subscribe between the same two entities involved in a
     call. It is unclear to me whether this mechanism allows for a generic
     subscription (for example by one of the endpoints towards his proxy) performed
     during a call, that extends beyond the duration of the call itself.
   * to my understanding, the duration of the subscription should be indefinite
     (minor issue: 5 days would do, anyway)
   * Wouldn' t a generic call-unrelated notification mechanism would put a lower
     burden on the involved parties?

Best Regards
Giuseppe Ricagni


----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------


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



 

Henning Schulzrinne wrote:

James Kempf wrote:

>

> >

> >It might be helpful to describe those things that are different
for

> >"network element" signaling and what information needs to be conveyed.
I

> >don't see (yet) why this needs to be a hack, but I would stay away
from

> >"let's just use the INFO hammer" approach.

> >

>




Henning,

I'd like to add another example where the need of an extention to SIP
might be analyzed.

I found your "Mobility support using SIP" paper very interesting.

I think it provides a very clear picture with respect to the scope
of SIP (terminal) mobility, what should be inplemented in SIP, what in
L3, what in L2 and the advantages of SIP mobility, in those cases where
it should be applied.

However there are some (very important) scenarios  that are not
covered by that paper, and I didn't manage to figure out whether all the
pieces needed to implement them are already there/something should be added
to SIP/another protocol should be used.

Let' s assume that (for a some reasons that go beyond the technical
aspects) we always have at least 3 SIP proxies betwen two mobile endpoints.
(Well, they may also be something more complicated  than a proxy,
but let's call them proxys now)

    

  • 
One proxy is in the "serving" domain: the domain where I' m currently registered
    • 


  • 
One proxy is in the "home" domain: the domain where I subscribed my mobility
service
    • 


  • 
One proxy is in the "requesting" domain: the domain of the calling party
    • 


Let's now say that the terminal either changes its "serving" domain or,
for some reasons, wants to change its "serving proxy", within the same
domain. Everything happens without a call being in progress (therefore
we cannot use the Info method)

What happens when the request to change the "serving proxy" comes

    

  • 
(a) from the terminal
    • 


  • 
(b) from the current serving proxy itself
    • 


  • 
(c) from the home proxy
    • 


In case (a), the terminal can send a REGISTER message to the new "serving
proxy", but then how is the "home proxy" notified of the change ?

In case (b), how does the "serving proxy" notify the terminal it has
to re-register with another proxy? Is the OPTIONS method appropriate ?

Aren't we misusing it?

Again, how is the "home proxy" notified of the change ?

In case (c), how are both the serving proxy and the terminal notified
?

In general, a call-unrelated signalling exchange might be required between
the home proxy, the current serving proxy, and the new serving proxy.

Does the SUBSCRIBE & NOTIFY mechanism (draft-roach-sip-subscribe-notify-00.txt)
cover all these cases? In particular:

    

  • 
the handover  mechanism must work independently of the existence of
a call involving the same two entities. Call-related subscribe requests
expire at the end of the call. The I-D mentions the possibilty (but only
for a proxy ?) to issue a "third-party" subscribe between the same two
entities involved in a call. It is unclear to me whether this mechanism
allows for a generic subscription (for example by one of the endpoints
towards his proxy) performed during a call, that extends beyond the duration
of the call itself.
    • 


  • 
to my understanding, the duration of the subscription should be indefinite
(minor issue: 5 days would do, anyway)
    • 


  • 
Wouldn' t a generic call-unrelated notification mechanism would put a lower
burden on the involved parties?
    • 





Best Regards

Giuseppe Ricagni

 

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

Giuseppe RICAGNI

System Architecture and Product Planning

Broadband Networks

Italtel

via Reiss Romoli - C10

20019 Castelletto di Settimo Milanese (MILANO)

ITALY

mailto:giuseppe.ricagni@italtel.it

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

 

--------------F9C12536E4D125064035F794--




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


From sip-admin@lists.bell-labs.com  Thu Apr 27 12: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 MAA03137
	for ; Thu, 27 Apr 2000 12:16: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 D8E634433B; Thu, 27 Apr 2000 12:11:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by lists.bell-labs.com (Postfix) with ESMTP id 844B944336
	for ; Thu, 27 Apr 2000 12:10:52 -0400 (EDT)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA15949;
        Thu, 27 Apr 2000 17:53:11 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA26852;
        Thu, 27 Apr 2000 17:57:09 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA28226;
	Thu, 27 Apr 2000 17:57:13 +0200 (MET DST)
Received: from young.dinsunnet (young [188.9.34.36])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id RAA21941;
	Thu, 27 Apr 2000 17:57:10 +0200 (MET DST)
Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4)
	id RAA14221; Thu, 27 Apr 2000 17:57:12 +0200 (MET DST)
Message-ID: <39086357.DE8ADE52@ms.alcatel.fr>
Date: Thu, 27 Apr 2000 17:57:11 +0200
From: Francois-Xavier Guitton 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg ,
        SIP 
Subject: Re: [SIP] Status of Also and Requested-By header fields
References: <3905A119.AB248267@ms.alcatel.fr> <3905A963.D9650F47@dynamicsoft.com>
Content-Type: multipart/alternative;
 boundary="------------0493C8FD2806A378478D8ED0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


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

Thanks for the information. So can we consider Also and Requested-By header
fields MUST NOT be used for future SIP implementations ???
Do you know when the new distributed multiparty conferencing draft is
published ?

Regards,

Fxg./.

Jonathan Rosenberg wrote:

> These fields were defined in the original call control draft:
> http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sip-cc-01.txt
>
> which has now expired. The group decided that the scope of this was too
> large, and so has decided to attack the problem differently. Transfer is
> split out, and is now described in:
>
> http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-cc-transfer-00.txt
>
> a new draft on distributed multiparty conferencing is pending.
>
> -Jonathan R.
>
> Francois-Xavier Guitton wrote:
> >
> > All,
> >
> > Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony Call
> > Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed Multipoint
> > Conferences using SIP) use the Also and Requested-By header fields to
> > allow conferencing features. But I did not find out where these fields
> > are specified. Even in the last RFC2543bis (April 2000) these fields are
> > not described.
> >
> > Can someone tell me which document specifies these header fields ?
> >
> > Regards,
> >
> > Francois-Xavier Guitton
> > ALCATEL Corporate Research Center
> >
> > mailto:Francois-Xavier.Guitton@ms.alcatel.fr
> >
> > _______________________________________________
> > 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:   (732) 741-4778
> 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

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



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



Thanks for the information. So can we consider Also and Requested-By header
fields MUST NOT be used for future SIP implementations ???

Do you know when the new distributed multiparty conferencing draft
is published ?

Regards,

Fxg./.

Jonathan Rosenberg wrote:

These fields were defined in the original call control
draft:

http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sip-cc-01.txt

which has now expired. The group decided that the scope of this was
too

large, and so has decided to attack the problem differently. Transfer
is

split out, and is now described in:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-cc-transfer-00.txt

a new draft on distributed multiparty conferencing is pending.

-Jonathan R.

Francois-Xavier Guitton wrote:

>

> All,

>

> Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony
Call

> Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed Multipoint

> Conferences using SIP) use the Also and Requested-By header fields
to

> allow conferencing features. But I did not find out where these fields

> are specified. Even in the last RFC2543bis (April 2000) these fields
are

> not described.

>

> Can someone tell me which document specifies these header fields
?

>

> Regards,

>

> Francois-Xavier Guitton

> ALCATEL Corporate Research Center

>

> mailto:Francois-Xavier.Guitton@ms.alcatel.fr

>

> _______________________________________________

> 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:   (732) 741-4778

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



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

 

--------------0493C8FD2806A378478D8ED0--



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


From sip-admin@lists.bell-labs.com  Thu Apr 27 12:27:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03348
	for ; Thu, 27 Apr 2000 12:27:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4DE4444341; Thu, 27 Apr 2000 12:22:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhost.ttimail.com (mailhost.ttimail.com [209.136.128.4])
	by lists.bell-labs.com (Postfix) with ESMTP id A85E94433C
	for ; Thu, 27 Apr 2000 12:22:48 -0400 (EDT)
Received: by mailhost.tti.net with Internet Mail Service (5.5.2650.21)
	id ; Thu, 27 Apr 2000 11:27:23 -0500
Message-ID: 
From: Qishen Tang 
To: sip@lists.bell-labs.com
Date: Thu, 27 Apr 2000 11:27:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [SIP] Free SIP bench mark software????
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@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,
Anybody know where I can get a free SIP bench mark software????

Thanks,


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 13:14: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 NAA04092
	for ; Thu, 27 Apr 2000 13:14: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 13E4744353; Thu, 27 Apr 2000 13:08:51 -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 6F62C4434D
	for ; Thu, 27 Apr 2000 13:08:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17707;
	Thu, 27 Apr 2000 11:12:56 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19])
	by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA27315;
	Thu, 27 Apr 2000 10:12:53 -0700 (PDT)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA09779;
	Thu, 27 Apr 2000 10:12:51 -0700 (PDT)
Message-Id: <200004271712.KAA09779@nasnfs.eng.sun.com>
Date: Thu, 27 Apr 2000 10:15:26 -0700 (PDT)
From: James Kempf 
Reply-To: James Kempf 
Subject: Re: [SIP] SIP and network element signalling (formerly: (nosubject) )
To: rohan@cisco.com, jdrosen@dynamicsoft.com
Cc: James.Kempf@eng.sun.com, schulzrinne@cs.columbia.edu, hiren.shah@wipro.com,
        sip@lists.bell-labs.com, brosen@fore.com, mjh@aciri.org,
        nara@syndeocorp.com, mauricio.arango@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: AuaRj/RAsi1sorkJfwPMPw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@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. A calls B, which is routed to B's "home" proxy
>2. B is registered elsewhere, at this "remote" proxy, so B's home proxy
>forwards the request there
>3. at the remote proxy, the call is forwarded the current location of
>the user
>4. the user does not answer, so the remote proxy returns 408
>5. the home proxy receives 408. It has the service enabled so that if it
>receives no answer, the call is forwarded to a media server which
>responds with a 183, plays the announcement, and then responds with a
>final 400.
>
>This achieves the desired service without inheriting the particulars of
>how it was implemented within IS-41. 
>

183 looks like the right solution.

		jak



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


From sip-admin@lists.bell-labs.com  Thu Apr 27 13:54: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 NAA04491
	for ; Thu, 27 Apr 2000 13:54: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 AB88244338; Thu, 27 Apr 2000 13:50:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 274C444336
	for ; Thu, 27 Apr 2000 13:50: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 NAA20410;
	Thu, 27 Apr 2000 13:51:58 -0400 (EDT)
Message-ID: <39087D61.CC5EE322@dynamicsoft.com>
Date: Thu, 27 Apr 2000 13:48:17 -0400
From: Igor Slepchin 
Organization: dynamicsoft Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Gethin Liddell 
Cc: Sip Mail List 
Subject: Re: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
References: <00042612595802.02452@gethin> <390720D8.44210C96@dynamicsoft.com> <00042709181600.04398@gethin>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I think BNF is only supposed to define grammar (i.e., syntax), not
semantics. Thus, it's sufficient for the BNF to allow the % sign in
tokens; it's up to the application to interpret % HEX HEX as an escaped
char. I agree that the grammar would be cleaner and easier to parse if
the BNF for token listed "escaped" instead of '%' (otherwise you should
pay attention to things like %XYZ - not an escaped char).

---
Igor Slepchin


Gethin Liddell wrote:
> 
> On Wed, 26 Apr 2000, Igor Slepchin wrote:
> > I agree that escaping characters in host name makes little sense as that
> > host name wouldn't be resolvable anyway; it is explicitly disallowed by
> > the BNF, and the example is inconsistent with the BNF as you correctly
> > noted. However, I don't think the spec prohibits escaped chars in url
> > parameters:
> >
> > other-param     = ( token | ( token "=" ( token | quoted-string )))
> >
> > and BNF of token allows '%' sign (explicitly in 2543bis).
> >
> 
> I almost agree.
> 
> Yes, the `%' is allowed in tokens, but only as a character in its own right,
> not as the start of an escaped value.  The format ("%" HEX HEX) of escaped
> values are valid but escaped values themselves are not explicity
> allowed or defined in a token.
> 
> Thus, if a url parameter has the value:
> 
> %61
> 
> is this considered to be the char `a' or the three characters `%' `6' and `1'
> 
> As the bnf stands, it would be the latter.


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 15: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 PAA05939
	for ; Thu, 27 Apr 2000 15:55: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 A92A744338; Thu, 27 Apr 2000 15:50:50 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6CAA044336
	for ; Thu, 27 Apr 2000 15:50:47 -0400 (EDT)
Received: from cs.columbia.edu (dhcp5.cs.columbia.edu [128.59.19.205])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA22575;
	Thu, 27 Apr 2000 15:54:23 -0400 (EDT)
Message-ID: <39089CAA.1E96D746@cs.columbia.edu>
Date: Thu, 27 Apr 2000 16:01:46 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Giuseppe Ricagni 
Cc: James Kempf , hiren.shah@wipro.com,
        sip@lists.bell-labs.com, brosen@fore.com, mjh@aciri.org,
        nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004251632.JAA03455@nasnfs.eng.sun.com> <3906564C.9992B1E7@cs.columbia.edu> <390863D1.CE156E0B@italtel.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

> Let' s assume that (for a some reasons that go beyond the technical
> aspects) we always have at least 3 SIP proxies betwen two mobile
> endpoints. (Well, they may also be something more complicated  than a
> proxy, but let's call them proxys now)
> 
>    * One proxy is in the "serving" domain: the domain where I' m
>      currently registered
>    * One proxy is in the "home" domain: the domain where I subscribed
>      my mobility service
>    * One proxy is in the "requesting" domain: the domain of the
>      calling party
> 
> Let's now say that the terminal either changes its "serving" domain
> or, for some reasons, wants to change its "serving proxy", within the
> same domain. Everything happens without a call being in progress
> (therefore we cannot use the Info method)
> 
> What happens when the request to change the "serving proxy" comes
> 
>    * (a) from the terminal
>    * (b) from the current serving proxy itself
>    * (c) from the home proxy
> 
> In case (a), the terminal can send a REGISTER message to the new
> "serving proxy", but then how is the "home proxy" notified of the
> change ?

Through registration proxying or via two separate REGISTER. The former
is probably better. In that case, the serving proxy is simply an
"outbound" proxy as far as the registration is concerned.

> 
> In case (b), how does the "serving proxy" notify the terminal it has
> to re-register with another proxy? Is the OPTIONS method appropriate ?

This would be third-party registration. Feasible, but not necessary, I
believe.

> 
> Aren't we misusing it?
> 
> Again, how is the "home proxy" notified of the change ?
> 
> In case (c), how are both the serving proxy and the terminal notified
> ?
> 
> In general, a call-unrelated signalling exchange might be required
> between the home proxy, the current serving proxy, and the new serving
> proxy.

> 
> Does the SUBSCRIBE & NOTIFY mechanism
> (draft-roach-sip-subscribe-notify-00.txt) cover all these cases? In
> particular:

No, REGISTER is the appropriate mechanism here.


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


From sip-admin@lists.bell-labs.com  Thu Apr 27 21:43:29 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10007
	for ; Thu, 27 Apr 2000 21:43:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D221344338; Thu, 27 Apr 2000 21:38:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from rmx09.globecomm.net (rmx09.iname.net [165.251.8.95])
	by lists.bell-labs.com (Postfix) with ESMTP id 4337D44336
	for ; Thu, 27 Apr 2000 21:38:40 -0400 (EDT)
Received: from web304-mc.mail.com  by rmx09.globecomm.net (8.9.1/8.8.0) with SMTP id VAA09067
Message-ID: <381437587.956886193104.JavaMail.root@web304-mc.mail.com>
Date: Thu, 27 Apr 2000 21:43:13 -0400 (EDT)
From: Bernard Hamilton 
To: sip@lists.bell-labs.com, Qishen.Tang@ttimail.com
Subject: [SIP] Free SIP bench mark software????
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: mail.com
X-Originating-IP: 63.204.201.74
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
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: Qishen Tang 
To: sip@lists.bell-labs.com
Date: Thu, 27 Apr 2000 11:27:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [SIP] Free SIP bench mark software????
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@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,
Anybody know where I can get a free SIP bench mark software????
Thanks,

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


Qishen Tang:
See attached Internet Telephony Newsletter. 7) SS8 Networks Announces Free
SIP Protocol Stacks

SS8 Networks today announced to potential partners and customers the
availability of free Session Initiation Protocol (SIP) client and server
stacks. The protocol stacks have been successfully tested for
interoperability with SIP products from other industry participants' in the
4th SIP Bake-Off held in Chicago this week. For more information, follow
this link:
http://www.tmcnet.com/newsletters/it/042100.htm#SS
_________________________________________________

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup



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


From sip-admin@lists.bell-labs.com  Fri Apr 28 02:16: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 CAA25077
	for ; Fri, 28 Apr 2000 02:16: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 5672C44338; Fri, 28 Apr 2000 02:11:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C557B44336
	for ; Fri, 28 Apr 2000 02:11:26 -0400 (EDT)
Received: from dynamicsoft.com (1Cust212.tnt2.freehold.nj.da.uu.net [63.17.114.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA22210;
	Fri, 28 Apr 2000 02:13:19 -0400 (EDT)
Message-ID: <39092E14.DCE8FE67@dynamicsoft.com>
Date: Fri, 28 Apr 2000 02:22:12 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois-Xavier Guitton 
Cc: SIP 
Subject: Re: [SIP] Status of Also and Requested-By header fields
References: <3905A119.AB248267@ms.alcatel.fr> <3905A963.D9650F47@dynamicsoft.com> <39086357.DE8ADE52@ms.alcatel.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

These headers may or may not end up being used in the final drafts. For
TRANSFER, I think we are calling them something else. If they end up not
being used I guess you could reuse them for something else, but that
doesn't seem wise. I'm not sure if thats what you were suggesting.

As for timelines, I think it was summer sometime.

-Jonathan R.

Francois-Xavier Guitton wrote:
> 
> Thanks for the information. So can we consider Also and Requested-By
> header fields MUST NOT be used for future SIP implementations ???
> Do you know when the new distributed multiparty conferencing draft is
> published ?
> 
> Regards,
> 
> Fxg./.
> 
> Jonathan Rosenberg wrote:
> 
> > These fields were defined in the original call control draft:
> > http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-
> > ip-cc-01.txt
> >
> > which has now expired. The group decided that the scope of this was
> > too
> > large, and so has decided to attack the problem differently.
> > Transfer is
> > split out, and is now described in:
> >
> > http://www.softarmor.com/sipwg/draf
> > s/draft-sparks-sip-cc-transfer-00.txt
> >
> > a new draft on distributed multiparty conferencing is pending.
> >
> > -Jonathan R.
> >
> > Francois-Xavier Guitton wrote:
> > >
> > > All,
> > >
> > > Some drafts like draft-ietf-sip-call-flows-00.txt (SIP Telephony
> > Call
> > > Flow Examples) and draft-mark-sip-dmcs-00.txt (Distributed
> > Multipoint
> > > Conferences using SIP) use the Also and Requested-By header fields
> > to
> > > allow conferencing features. But I did not find out where these
> > fields
> > > are specified. Even in the last RFC2543bis (April 2000) these
> > fields are
> > > not described.
> > >
> > > Can someone tell me which document specifies these header fields ?
> >
> > >
> > > Regards,
> > >
> > > Francois-Xavier Guitton
> > > ALCATEL Corporate Research Center
> > >
> > > mailto:Francois-Xavier.Guitton@ms.alcatel.fr
> > >
> > > _______________________________________________
> > > 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:   (732) 741-4778
> > 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
> 
> --
> Francois-Xavier Guitton (SWD/UAA/GSA)
> mailto:Francois-Xavier.Guitton@ms.alcatel.fr
> Tel: +33 (0)1 69 63 47 52
> Fax: +33 (0)1 69 63 17 89
> 
> 

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


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


From sip-admin@lists.bell-labs.com  Fri Apr 28 02:43: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 CAA25242
	for ; Fri, 28 Apr 2000 02:43: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 322714433A; Fri, 28 Apr 2000 02:38:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A6D9D44336
	for ; Fri, 28 Apr 2000 02:38:46 -0400 (EDT)
Received: from dynamicsoft.com (1Cust212.tnt2.freehold.nj.da.uu.net [63.17.114.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA22236;
	Fri, 28 Apr 2000 02:44:38 -0400 (EDT)
Message-ID: <3909356B.3045BF7F@dynamicsoft.com>
Date: Fri, 28 Apr 2000 02:53:31 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ilya Slain 
Cc: sip@lists.bell-labs.com, binguyen@cisco.com
Subject: Re: [SIP] mwi in SIP: supplying waiting message lists
References: <20000423170750.2723.qmail@web219.mail.yahoo.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

Message waiting has come up numerous times. I agree we should have a
solution based on a subscribe/notify method. Just to note, I do believe
there are other ways to do this that can make use of other existing
protocols. For systems that use email-based voicemail storage (like
VPIM), IMAP may actually be the appropriate protocol for message
waiting. I accept that IMAP is gross overkill for systems that just want
voicemail only message waiting lamps, so something a little more focused
would be useful.

As pointed out in another thread, the described mechanism of enumerating
events in SUBSCRIBE is too restrictive and not compatible with pint.
Rather than attacking these bit at a time, I think it would be
tremendously valuable to list the general set of events and state
associated with SIP communications systems that one might wish to
subscribe to. This will help us figure out the set of things we might
like to build in to some set of "sip presence subscription documents",
which are carried in SUBSCRIBE messages to indicate what is being
subscribed to.

-Jonathan R.

Ilya Slain wrote:
> 
> There has recently been some discussion on the way to
> do message waiting indication (mwi) using SUBSCRIBE/
> NOTIFY SIP extensions.  However, I am not aware of
> any proposals to for specifying waiting message list
> summary, supplied in mwi NOTIFY message.  In other
> words, there is no proposed way to supply the summary
> of messages being available in the voice mail system.
> 
> So I would like to submit a brief sample proposal to
> do
> message waiting indication with message summary using
> SIP
> SUBSCRIBE/NOTIFY.  This is based on the recent
> SUBSCSRIBE/
> NOTIFY IETF draft:
> http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt
> 
> The main purpose of this proposal is to start the
> discussion
> on the topic with the aim of eventually submitting an
> Inf. Draft.
> 
> 1. Subscription
> ----------------
> Event field specifies "mwi" field (message waiting
> indication).
> There is no message body.
> 
> SUBSCRIBE ...
> To:             ...
> From:           ...
> Call-ID:        ...
> CSeq:           ...
> Contact:        ...
> Expires:        ...
> Event:          mwi
> Content-Length: 0
> 
> 2. Notification
> -----------------
> Event field specifies "mwi".
> Message body specifies the message summary.
> 
> NOTIFY
> To:             ...
> From:           ...
> Call-ID:        ...
> CSeq:           ...
> Contact:        ...
> Expires:        ...
> Event:          mwi
> Content-Type:   application/um
> Content-Length: 148
> 
> VOICEMAIL: ; U:n1/n2; S:n1/n2;
> F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
> EMAIL:     ; U:n1/n2; S:n1/n2;
> F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
> FAX:       ; U:n1/n2; S:n1/n2;
> F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
> VIDEO:     ; U:n1/n2; S:n1/n2;
> F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
> 
> where TOTAL_MESSAGES, n1, n2 are integers
> U = UNTOUCHED
> S = SKIPPED
> F = FLAGGED
> R = READ
> A = ANSWERED
> D = DELETED
> 
> For example:
> voicemail: 10; U:3/1; S:1/0; F:0/0; R:5/2; A:1/0;
> D:0/0
> where U: 3/1  indicates that there are 3 untouched
> messages, 1 of which is urgent.
> 
> More formal grammar for the application/um message
> body:
> 
> application_um_message_body = message_summary_list
> message_summary_list = message_summary "\n"
> message_summary_list | NULL
> message_summary = message_type ": " total_messages ";
> " typed_summary_list
> message_type = "VOICEMAIL" | "EMAIL" | "FAX" | "VIDEO"
> total_messages = INTEGER
> typed_summary_list = typed_summary ";"
> typed_summary_list | NULL
> typed_summary = type ":" number_of_messages "/"
> number_of_urgent_messages
> type = "U" | "S" | "F" | "R" | "A" | "D"
> number_of_messages = INTEGER
> number_of_urgent_messages = INTEGER
> 
> ______________________________________________________________________________
> 
> Ilya Slain                       ||        ||
>   Cisco Systems, Inc.
> Technology Center               .||.      .||.
>            Building 9
>                                .||||.    .||||.
> 170 West Tasman Drive
> Tel:    408.527.9446       ...||||||||..||||||||...
>   San Jose, CA  95134
> Fax:    408.527.1221       C i s c o  S y s t e m s
> E-Mail: islain@cisco.com
> ____________________________________________________________________________
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.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:   (732) 741-4778
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 Apr 28 05:15: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 FAA26168
	for ; Fri, 28 Apr 2000 05:15: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 41EE344338; Fri, 28 Apr 2000 05:10:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id E276244336
	for ; Fri, 28 Apr 2000 05:10:44 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA06543; Fri, 28 Apr 2000 10:13:19 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Igor Slepchin 
Subject: Re: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
Date: Fri, 28 Apr 2000 09:37:55 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Sip Mail List 
References: <00042612595802.02452@gethin> <00042709181600.04398@gethin> <39087D61.CC5EE322@dynamicsoft.com>
In-Reply-To: <39087D61.CC5EE322@dynamicsoft.com>
MIME-Version: 1.0
Message-Id: <00042810111502.08630@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, 27 Apr 2000, Igor Slepchin wrote:
> I think BNF is only supposed to define grammar (i.e., syntax), not
> semantics. Thus, it's sufficient for the BNF to allow the % sign in
> tokens; it's up to the application to interpret % HEX HEX as an escaped
> char. I agree that the grammar would be cleaner and easier to parse if
> the BNF for token listed "escaped" instead of '%' (otherwise you should
> pay attention to things like %XYZ - not an escaped char).
> 

That is fundamentally incorrect.

The "escaped" BNF element is a lexeme in its own right.  The "token" BNF element
is a separate lexeme.  One does not exist in / is not part of the other.  During lexical
analysis, the format "% HEX HEX" will NOT be put into the "escaped" lexeme IF it
is analyzing a "token". 

i.e. The bnf DOES define the semantics.

or put another way, consider the tree representation of BNF. When parsing a token, 
the only lower nodes that exist are those of alphanum and  

"-"  "."  "!" "%" "*" "_" "+" "`" "'"

the "escaped" element does not exist below token so it knows nothing about it.  The two
are used in isolation to each other.

This is the only way the grammar can remain context-free.

If it was not context-free then it would be impossible to parse correctly as it would not be
known which context is being used.


> ---
> Igor Slepchin
> 
> 
> Gethin Liddell wrote:
> > 
> > On Wed, 26 Apr 2000, Igor Slepchin wrote:
> > > I agree that escaping characters in host name makes little sense as that
> > > host name wouldn't be resolvable anyway; it is explicitly disallowed by
> > > the BNF, and the example is inconsistent with the BNF as you correctly
> > > noted. However, I don't think the spec prohibits escaped chars in url
> > > parameters:
> > >
> > > other-param     = ( token | ( token "=" ( token | quoted-string )))
> > >
> > > and BNF of token allows '%' sign (explicitly in 2543bis).
> > >
> > 
> > I almost agree.
> > 
> > Yes, the `%' is allowed in tokens, but only as a character in its own right,
> > not as the start of an escaped value.  The format ("%" HEX HEX) of escaped
> > values are valid but escaped values themselves are not explicity
> > allowed or defined in a token.
> > 
> > Thus, if a url parameter has the value:
> > 
> > %61
> > 
> > is this considered to be the char `a' or the three characters `%' `6' and `1'
> > 
> > As the bnf stands, it would be the latter.
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 28 05: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 FAA26179
	for ; Fri, 28 Apr 2000 05:18: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 E5A1C44345; Fri, 28 Apr 2000 05:13:38 -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 827D744344
	for ; Fri, 28 Apr 2000 05:13:31 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA10507
	for ; Fri, 28 Apr 2000 11:18:11 +0200 (MET DST)
Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Fri, 28 Apr 2000 11:16:43 +0200
Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.32
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 28 Apr 2000 09:16:43 0000 (GMT)
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Fri, 28 Apr 2000 11:14:45 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2448.0)
	id ; Fri, 28 Apr 2000 11:17:59 +0200
Message-ID: 
From: "Velibor Cakarevic (ECS)" 
To: "'sip@lists.bell-labs.com'" 
Date: Fri, 28 Apr 2000 11:17:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-OriginalArrivalTime: 28 Apr 2000 09:14:45.0062 (UTC) FILETIME=[319D2660:01BFB0F2]
Subject: [SIP] I would like to subscribe
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@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 mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Apr 28 05:38: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 FAA26338
	for ; Fri, 28 Apr 2000 05:38: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 41D8944338; Fri, 28 Apr 2000 05:33:44 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from felix.intertex.se (unknown [195.22.82.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 24B0A44336
	for ; Fri, 28 Apr 2000 05:33:41 -0400 (EDT)
Date: Fri, 28 Apr 2000 11:41:27 +0200 (CEST)
From: Lars Berggren 
To: sip@lists.bell-labs.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SIP] inconsistency 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


Section 10.2.1 :
>10.2.1 Unicast UDP
>Responses are returned to the network address and port listed in the Via
>header field (Section 6.45), not the source address of the request.

While this is true for proxies forwarding a response, it contradicts what
is stated for UA and redirect servers in 6.45.4 :

>   A UAS or redirect server sends a response based on one of the
>   following rules:
>
>        o  If the first Via header field in the request contains a
>          "maddr" parameter, send the response to the multicast address
>          listed there, using the port indicated in "sent-by", or port
>          5060 if none is present. The response SHOULD be sent using the
>          TTL indicated in the "ttl" parameter, or with a TTL of 1 if
>          that parameter is not present. For robustness, responses MUST
>          be sent to the address indicated in the "maddr" parameter even
>          if it is not a multicast address.
>
>        o  If the address in the "sent-by" value of the first Via field
>          differs from the source address of the packet, send the
>          response to the actual packet source address, similar to the
>          treatment for receiver-tagged Via header fields (Section
>          6.40.2).
>
>        o  If neither of these conditions is true, send the response to
>          the address contained in the "sent-by" value. If the request
>          was sent using TCP, use the existing TCP connection if
>          available.

If the intention is that 10.2.1 only applies to proxies forwarding a
response, I think 10.2.1 should be updated to explicitly say that.

/Lars

--
Lars Berggren       
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414



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


From sip-admin@lists.bell-labs.com  Fri Apr 28 06: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 GAA26772
	for ; Fri, 28 Apr 2000 06:42: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 57C3944339; Fri, 28 Apr 2000 06:37:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 88DAE44336
	for ; Fri, 28 Apr 2000 06:37:27 -0400 (EDT)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id MAA04155 for ; Fri, 28 Apr 2000 12:41:07 +0200 (MET DST)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id MAA21340 for ; Fri, 28 Apr 2000 12:40:05 +0200 (MET DST)
Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id MAA18921
	for ; Fri, 28 Apr 2000 12:40:19 +0200 (MET DST)
Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it
          (Netscape Messaging Server 3.5)  with ESMTP id AAA4AF;
          Fri, 28 Apr 2000 12:49:34 +0200
Message-ID: <39096BD1.792ECFE7@italtel.it>
Date: Fri, 28 Apr 2000 12:45:45 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: James Kempf , hiren.shah@wipro.com,
        sip@lists.bell-labs.com, brosen@fore.com, mjh@aciri.org,
        nara@syndeocorp.com, mauricio.arango@eng.sun.com
Subject: Re: [SIP] SIP and network element signalling (formerly: (no subject) )
References: <200004251632.JAA03455@nasnfs.eng.sun.com> <3906564C.9992B1E7@cs.columbia.edu> <390863D1.CE156E0B@italtel.it> <39089CAA.1E96D746@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:

>
> > What happens when the request to change the "serving proxy" comes
> >
> >    * (a) from the terminal
> >    * (b) from the current serving proxy itself
> >    * (c) from the home proxy
> >
> > In case (a), the terminal can send a REGISTER message to the new
> > "serving proxy", but then how is the "home proxy" notified of the
> > change ?
>
> Through registration proxying or via two separate REGISTER. The former
> is probably better. In that case, the serving proxy is simply an
> "outbound" proxy as far as the registration is concerned.
>
> >
> > In case (b), how does the "serving proxy" notify the terminal it has
> > to re-register with another proxy? Is the OPTIONS method appropriate ?
>
> This would be third-party registration. Feasible, but not necessary, I
> believe.

As far as I know, in current GSM, handover is always initiated by the
network, not by the terminal (based on radio subsystem criteria (RF level,
quality, distance) as well as network directed criteria (e.g. current
traffic loading per cell, maintainance requests etc) ).

Case a) I was suggesting was more for the sake of generality than for other
purposes (even if it has some important applications)

Even if we are here talking about a L7 handover, hand we can assume that a
lower level subsystem can handle most of the intra-proxy handovers, I
believe the same concept should apply or, at least, we should have the
possibility, for handovers, to be initiated by the nework. I don't want to
go into too much detail, also because many of such details have yet to be
agreed.

With third party registration, do you mean that the old proxy registers the
terminal on the new proxy by putting the terminal's URI in the To header and
its own (old proxy) URI in the From header ?

The home proxy can be notifed by means of a registration proxying mechanism,
fine. But how is the terminal notified about the change, anyway? There are
(technical and non-technical) reasons why it must be aware of the change.

Thanks and
Best Regards
Giuseppe



----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------




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


From sip-admin@lists.bell-labs.com  Fri Apr 28 10:08: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 KAA01619
	for ; Fri, 28 Apr 2000 10:08: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 3E76744339; Fri, 28 Apr 2000 10:03:31 -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 A4DC644336
	for ; Fri, 28 Apr 2000 10:03:28 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr 28 10:06:19 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 8C37B44344; Fri, 28 Apr 2000 09:53:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 57BA144341
	for ; Fri, 28 Apr 2000 09:53:10 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 0454652BB; Fri, 28 Apr 2000 09:53:09 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 2E15852B6
	for ; Fri, 28 Apr 2000 09:53:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Apr 28 09:52:56 EDT 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Fri Apr 28 09:52:55 EDT 2000
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FTQ00D8KBW3IA@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Fri, 28 Apr 2000 13:52:51 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0FTQ00601BPA7G@pmismtp04.wcomnet.com>;
 Fri, 28 Apr 2000 13:48:48 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FTQ004B1BOXT7@pmismtp04.wcomnet.com>; Fri,
 28 Apr 2000 13:48:34 +0000 (GMT)
Received: from wcom.com ([166.44.154.217])
 by omzmta01.mcit.com (InterMail v03.02.07.05 118-131)
 with ESMTP id <20000428135235.GGTU16259@wcom.com>; Fri,
 28 Apr 2000 13:52:35 +0000
Date: Fri, 28 Apr 2000 08:55:11 -0500
From: Alan Johnston 
Subject: Re: [SIP] Question in draft-ietf-call-flows-00.txt
To: Jonathan Rosenberg 
Cc: leslie@lgcit.com, sip@lists.research.bell-labs.com
Message-id: <3909983D.92B6A093@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <3907F02B.CFD2005D@mail.lgcit.com>
 <39086157.7BFF038D@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

The tag will be added to the response.  Thanks for the feedback.

Alan Johnston
MCI WorldCom

Jonathan Rosenberg wrote:

> Dohoon Kim wrote:
> >
> > at F5  in page 61 User B sends "486 Busy Here" response to Proxy 2, but
> > does not add tag value at To header field.
>
> It should.
>
> >
> > Then at F6 Proxy 2 sends ACK to UserB with tag value "314159"
> >
> > Is this correct?
>
> No; the UAC should not insert the tag into ACK. The 486 should have a
> tag, and this should be mirrored in the ACK.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Apr 28 10:51: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 KAA02559
	for ; Fri, 28 Apr 2000 10:51: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 C3D5244340; Fri, 28 Apr 2000 10:47:10 -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 2CC144433C
	for ; Fri, 28 Apr 2000 10:47:08 -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 KAA05029;
	Fri, 28 Apr 2000 10:51:46 -0400 (EDT)
Message-ID: <3909A582.588A75D1@cisco.com>
Date: Fri, 28 Apr 2000 10:51:46 -0400
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Questions about Register scenario 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
Content-Transfer-Encoding: 7bit

In section 16.1 of RFC2543bis there is an example of Registration. I have
a couple of questions about this scenario. I would appreciate any responses.

1) What would be the To header of the REGISTER that T. Watson sends to
the registrar at example.com. Would it be tawatson@example.com or
tawatson@bell-tel.com ?? As per the description in section 4.2.6, To header
domain could be different from the domain of the Request-URI in the REGISTER.

2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to the
proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com.
As per the latest registration, the Contact is tawatson@example.com, so 
the proxy at bell-tel.com rewrites the Request-URI and sends it to the
proxy at example.com - INVITE tawatson@example.com. Now what is the search
key at the registrar - is it user@domain or simply user. If it is simply user,
then domain of To header in REGISTER is meaningless. If it is user@domain,
then To header of the REGISTER sent to the registrar at example.com must be
tawatson@example.com.

3) What if there already exists a user tawatson at the domain example.com.
Should the registrar at example.com reject the registration ?? If yes,
what response code should be used ??

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  Fri Apr 28 11: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 LAA03294
	for ; Fri, 28 Apr 2000 11:15: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 CF9A34433C; Fri, 28 Apr 2000 11:10:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6110444336
	for ; Fri, 28 Apr 2000 11:10:05 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA20693;
	Fri, 28 Apr 2000 11:14:23 -0400 (EDT)
Message-ID: <3909AACF.2FF10793@cs.columbia.edu>
Date: Fri, 28 Apr 2000 11:14:23 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Ilya Slain , sip@lists.bell-labs.com, binguyen@cisco.com
Subject: Re: [SIP] mwi in SIP: supplying waiting message lists
References: <20000423170750.2723.qmail@web219.mail.yahoo.com> <3909356B.3045BF7F@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:
> 
> Message waiting has come up numerous times. I agree we should have a
> solution based on a subscribe/notify method. Just to note, I do believe
> there are other ways to do this that can make use of other existing
> protocols. For systems that use email-based voicemail storage (like
> VPIM), IMAP may actually be the appropriate protocol for message
> waiting. I accept that IMAP is gross overkill for systems that just want
> voicemail only message waiting lamps, so something a little more focused
> would be useful.

It should also be noted that IMAP and POP are client-initiated, i.e.,
the client has to poll periodically.

> 
> As pointed out in another thread, the described mechanism of enumerating
> events in SUBSCRIBE is too restrictive and not compatible with pint.
> Rather than attacking these bit at a time, I think it would be
> tremendously valuable to list the general set of events and state
> associated with SIP communications systems that one might wish to
> subscribe to. This will help us figure out the set of things we might
> like to build in to some set of "sip presence subscription documents",
> which are carried in SUBSCRIBE messages to indicate what is being
> subscribed to.

We should also avoid a new syntax for each type of event, if at all
possible.

-- 
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 Apr 28 12: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 MAA05788
	for ; Fri, 28 Apr 2000 12:43: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 617A94433A; Fri, 28 Apr 2000 12:38:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BA00844336
	for ; Fri, 28 Apr 2000 12:38:46 -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 MAA23320;
	Fri, 28 Apr 2000 12:44:42 -0400 (EDT)
Message-ID: <3909C211.5777AEC1@dynamicsoft.com>
Date: Fri, 28 Apr 2000 12:53:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] inconsistency in rfc2543bis
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 agree this statement in 10.2.1 is very confusing, and probably
incorrect given the most obvious interpretation. It was pointed out to
me during the bakeoff by someone else also. Rules for where to send the
response should ultimately be the same for UAS or a proxy. The rules in
6.45 will result in the response being sent to the source address, and
so the same should apply to proxies. In fact, they do for a response
that a proxy forwards upstream (since the received-by address is used
first, which is the source address when not the same as sent-by). SO, if
a proxy receives a request, and just responds to it directly (rather
than proxying the request and then proxying a response), the response
goes to the source address of the request. If the request is proxied,
and then a response is received which is forwarded, it will end up being
sent to the source address the request originally came in on, since the
construction of the Via header guarantees this.

-Jonathan R.

Lars Berggren wrote:
> 
> Section 10.2.1 :
> >10.2.1 Unicast UDP
> >Responses are returned to the network address and port listed in the Via
> >header field (Section 6.45), not the source address of the request.
> 
> While this is true for proxies forwarding a response, it contradicts what
> is stated for UA and redirect servers in 6.45.4 :
> 
> >   A UAS or redirect server sends a response based on one of the
> >   following rules:
> >
> >        o  If the first Via header field in the request contains a
> >          "maddr" parameter, send the response to the multicast address
> >          listed there, using the port indicated in "sent-by", or port
> >          5060 if none is present. The response SHOULD be sent using the
> >          TTL indicated in the "ttl" parameter, or with a TTL of 1 if
> >          that parameter is not present. For robustness, responses MUST
> >          be sent to the address indicated in the "maddr" parameter even
> >          if it is not a multicast address.
> >
> >        o  If the address in the "sent-by" value of the first Via field
> >          differs from the source address of the packet, send the
> >          response to the actual packet source address, similar to the
> >          treatment for receiver-tagged Via header fields (Section
> >          6.40.2).
> >
> >        o  If neither of these conditions is true, send the response to
> >          the address contained in the "sent-by" value. If the request
> >          was sent using TCP, use the existing TCP connection if
> >          available.
> 
> If the intention is that 10.2.1 only applies to proxies forwarding a
> response, I think 10.2.1 should be updated to explicitly say that.
> 
> /Lars
> 
> --
> Lars Berggren       
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Apr 28 16:06: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 QAA10753
	for ; Fri, 28 Apr 2000 16:06: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 2C5F24433B; Fri, 28 Apr 2000 16:01:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 91C5944336
	for ; Fri, 28 Apr 2000 16:01: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 QAA24001;
	Fri, 28 Apr 2000 16:03:57 -0400 (EDT)
Message-ID: <3909EDF0.4106D91D@dynamicsoft.com>
Date: Fri, 28 Apr 2000 16:00:48 -0400
From: Igor Slepchin 
Organization: dynamicsoft Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Gethin Liddell 
Cc: Sip Mail List 
Subject: Re: [SIP] Sip URL and escaped characters. RFC 2543 Section 2
References: <00042612595802.02452@gethin> <00042709181600.04398@gethin> <39087D61.CC5EE322@dynamicsoft.com> <00042810111502.08630@gethin>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I see what you are saying. I guess you might have a point here; however,
I'm still not sure that the BNFs in the SIP specs are (or even should
be) designed in a way that allows feeding them directly into a parser
generator and not worrying about anything else. Note that there are
still quite a few places in the spec where the behavior of the grammar
needs to be explained in words. In general, BNF has its limitations and
cannot describe everything, e.g., if you go by the book, you'll notice
that many header BNFs allow multiple instances of the same parameter,
even though this is often meaningless; a special wording is needed to
describe the use of brackets in To headers, etc. The combination of the
BNF and the description gives you the complete grammar and semantics, at
least currently.

With that said, it surely is nice to make BNF as expressive as possible.
Having a separate ecsape-token to describe tokens with % HEX HEX might
make the life of parser implementors somewhat easier. Does this mean the
current BNF is broken (or doesn't allow escaped chars in url-params,
which started this thread)? I don't believe so.

Regards,
Igor Slepchin


Gethin Liddell wrote:
> <...>
> i.e. The bnf DOES define the semantics.
> 
> or put another way, consider the tree representation of BNF. When parsing a token,
> the only lower nodes that exist are those of alphanum and
> 
> "-"  "."  "!" "%" "*" "_" "+" "`" "'"
> 
> the "escaped" element does not exist below token so it knows nothing about it.  The two
> are used in isolation to each other.
> 
> This is the only way the grammar can remain context-free.
> 
> If it was not context-free then it would be impossible to parse correctly as it would not be
> known which context is being used.


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


From sip-admin@lists.bell-labs.com  Fri Apr 28 18:48:09 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13905
	for ; Fri, 28 Apr 2000 18: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 801E44433F; Fri, 28 Apr 2000 18:43:18 -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 EA23044336
	for ; Fri, 28 Apr 2000 18:43:15 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Apr 28 18:46:40 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 1AA6344344; Fri, 28 Apr 2000 18:33:31 -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 E3B0944341
	for ; Fri, 28 Apr 2000 18:33:30 -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 SAA28807
	for ; Fri, 28 Apr 2000 18:33:30 -0400 (EDT)
Message-ID: <390A11BB.80E92106@cs.columbia.edu>
Date: Fri, 28 Apr 2000 18:33:31 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP bake-off 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

See http://www.cs.columbia.edu/sip/bakeoff/faq.html

Since participants of the 4th bake-off are probably working with their
PR folks, note in particular the item about press releases.

Comments and questions are appreciated.

Henning


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


From sip-admin@lists.bell-labs.com  Fri Apr 28 20:14:09 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20382
	for ; Fri, 28 Apr 2000 20:14:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 747434433F; Fri, 28 Apr 2000 20:09:19 -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 DFC4E44336
	for ; Fri, 28 Apr 2000 20:09:16 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr 28 20:12:05 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id A40CF44344; Fri, 28 Apr 2000 19:58:56 -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 7629B44341
	for ; Fri, 28 Apr 2000 19:58:56 -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 TAA00786;
	Fri, 28 Apr 2000 19:58:51 -0400 (EDT)
Message-ID: <390A25BC.BAFEA3B1@cs.columbia.edu>
Date: Fri, 28 Apr 2000 19:58:52 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Lars Berggren , sip@lists.bell-labs.com
Subject: Re: [SIP] inconsistency in rfc2543bis
References:  <3909C211.5777AEC1@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

There's another wrinkle: While the server effectively returns the
response to the source *IP address*, it does not necessarily use the
source *port*, at least for UDP. (TCP will try to re-use the same
connection, so it will be the source port in most cases.)

Unfortunately, NAPTs rewrite both address and port and even if we wanted
to fix this, this would break the desirable feature of letting the
client specify the return port (e.g., to have everything arrive on
5060).

I fixed 10.2.1 to refer to the Via rules (I think the confusion in
10.2.1 comes partially from this address/port distinction, where port is
meant).


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


From sip-admin@lists.bell-labs.com  Sat Apr 29 14: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 OAA19483
	for ; Sat, 29 Apr 2000 14: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 2793544337; Sat, 29 Apr 2000 14:32:34 -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 870A244336
	for ; Sat, 29 Apr 2000 14:32:31 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA12339;
	Sat, 29 Apr 2000 14:37:21 -0400 (EDT)
Message-ID: <390B2BE1.F0866994@cs.columbia.edu>
Date: Sat, 29 Apr 2000 14:37:21 -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 ,
        Sip Mail List 
Subject: Re: [Fwd: [SIP] Sip URL and escaped characters. RFC 2543 Section 2]
References: <39092496.2C0ABAE6@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

Maybe time to summarize and see if there's an issue left:

- The host part of the URL cannot contain %, either as itself or as an
escape mechanism:

host          = hostname | IPv4address
hostname      = *( domainlabel "." ) toplabel [ "." ]
domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
alphanum      = alpha | digit

- For "token" elements in URLs, this is a bit tricky, since we have two
escape mechanisms that are intersecting:

  (1) the normal token definition, i.e., any letter, digit, and a large
number of symbols (-, #, $, &, %, ^, *, _, +, |, ~, ')

  (2) the rules for URLs, where some of these characters (&, +) are
reserved and thus need to be escaped if there's the possibility of
confusion with a separator. As far as I can tell, neither of them are
syntactically relevant for SIP URLs in this context (the & is only used
to separate 'header' items), so neither of them would need to be
escaped.

Thus, it might be better to define

other-param = pname [ "=" pvalue ]

pname     = 1*tokenchar
pvalue    = 1*tokenchar | quoted-string
tokenchar = alphanum | escaped | "!" | "'" | "*" | "." 
            | "^" | "_" | "~" | "|" | "%" | "-" | "#" | "/" | ":" | "@"
| "&" | "+" | "$"

(since "," is not valid in token, I didn't include it. Any that I'm
missing?)

Here, escaped can only refer to the legal characters (alphanum and the
others) to maintain "tokenness", but I can't express this in the BNF.
However, in practice this is not a problem except for spec-writers since
the pname and pvalue tokens have to be drawn from an enumeration, so
that most character combinations are invalid simply because they are not
valid parameter names.

- To make matters slightly more confusing, we do have a different
potential problem, namely the " in the quoted string. The <"> is a
"delims" character and thus must be escaped (RFC 2396, pg. 9/10). One
could argue that it only needs to be escaped if there's a possibility
for confusion, e.g., on a web page or if the URL appears in a quoted
string. However, either should be accepted by the parser.


- In URLs, %hex hex (where allowed) is always interpreted as an escape
mechanism. It is mechanically translated to the equivalent character,
while maintaining its distinct identity as a non-separator (if it could
be treated as such). Thus, 

foo%40bar@host.com

can't just be translated into foo@bar@host.com and then be parsed, since
the result would not be as expected. This is not fundamentally different
from other escape mechanisms for delimiters, like \" or "".

Thus, one should *first* split the URL into components and then
translate those parts where escaping is possible (which is pretty much
anywhere except in scheme and host).

- As was pointed out, BNF specifies syntax. It cannot express certain
things, including
  . restrictions on ordering  (an | does not imply that the elements
have to appear in order)
  . any restriction on duplication
  . the role of identifiers or restrictions on their names (e.g., "int
int" may be legal in a BNF specification but the compiler may still
complain)

  For details, see for example, pg. 172 of Aho/Sethi/Ullman:

  "Certain constraints on the input, such as the requirement that
identifiers be declared before they are used, cannot be described by a
context-free grammar."


If there are places where the grammar needs to be tightened up, 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