RE: not able to understand the call flow for Home Phone = implement ation

From owner-sip-outgoing@lists.research.bell-labs.com Sun Jan 2 05:04:06 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 FAA06812 for ; Sun, 2 Jan 2000 05:04:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CC71452BB; Sun, 2 Jan 2000 04:59:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3DF8452DD; Sun, 2 Jan 2000 04:59:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8E93552BB for ; Sun, 2 Jan 2000 04:59:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Jan 2 04:57:49 EST 2000 Received: from tlv.radvision.com ([192.116.213.132]) by dusty; Sun Jan 2 04:56:03 EST 2000 Received: by firewall.tlv.radvision.com id <115202>; Sun, 2 Jan 2000 10:55:32 +0200 Message-Id: <00Jan2.105532ist.115202@firewall.tlv.radvision.com> From: Itamar Gilad To: "'SIP List'" Subject: Call services MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5507.99A85510" Date: Sun, 2 Jan 2000 10:55:32 +0200 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF5507.99A85510 Content-Type: text/plain; charset="windows-1252" Am I right in assuming that draf-ietf-mmusic-sip-cc-01.txt ('SIP Call Control Services") and draft-sparks-sip-service-examples-00.txt ("SIP Telephony Service Examples With Call Flows") are the only authoritative documents describing call services in SIP? Any others? Thanks Itamar Gilad ------_=_NextPart_001_01BF5507.99A85510 Content-Type: text/html; charset="windows-1252"

Am I right in assuming that draf-ietf-mmusic-sip-cc-01.txt ('SIP Call Control Services") and draft-sparks-sip-service-examples-00.txt ("SIP Telephony Service Examples With Call Flows") are the only authoritative documents describing call services in SIP? Any others?

Thanks

Itamar Gilad

------_=_NextPart_001_01BF5507.99A85510-- From owner-sip-outgoing@lists.research.bell-labs.com Sun Jan 2 09:31:57 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 JAA08521 for ; Sun, 2 Jan 2000 09:31:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CA2DE52DD; Sun, 2 Jan 2000 09:29:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1D08452DE; Sun, 2 Jan 2000 09:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1DC3352DD for ; Sun, 2 Jan 2000 09:29:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Jan 2 09:28:58 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Sun Jan 2 09:27:11 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41714) id <0FNP00701PK79I@firewall.mcit.com> for sip@lists.research.bell-labs.com; Sun, 2 Jan 2000 14:28:55 +0000 (GMT) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #41714) with ESMTP id <0FNP00234PK7CJ@firewall.mcit.com>; Sun, 02 Jan 2000 14:28:55 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id OAA14973; Sun, 02 Jan 2000 14:23:54 +0000 (GMT) Received: from C25766A ([166.44.57.192]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000102142854.MIGO16500@C25766A>; Sun, 02 Jan 2000 14:28:54 +0000 Date: Sun, 02 Jan 2000 08:28:53 -0600 From: Henry Sinnreich Subject: RE: Call services In-reply-to: <00Jan2.105532ist.115202@firewall.tlv.radvision.com> To: Itamar Gilad , "'SIP List'" 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: multipart/alternative; boundary="Boundary_(ID_zmDJoW2w5ltG6YJMB/ezVw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_zmDJoW2w5ltG6YJMB/ezVw) Content-type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit See also johnston-sip-call flows. A pdf. version is available at http://www.greycouncil.com/sip/drafts/draft-johnston-sip-call-flows-00.pdf There is also a draft on multi-proxy authorization at http://www.greycouncil.com/sip/drafts/ Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Itamar Gilad Sent: Sunday, January 02, 2000 2:56 AM To: 'SIP List' Subject: Call services Am I right in assuming that draf-ietf-mmusic-sip-cc-01.txt ('SIP Call Control Services") and draft-sparks-sip-service-examples-00.txt ("SIP Telephony Service Examples With Call Flows") are the only authoritative documents describing call services in SIP? Any others? Thanks Itamar Gilad --Boundary_(ID_zmDJoW2w5ltG6YJMB/ezVw) Content-type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

See=20 also johnston-sip-call flows. A pdf. version is available = at

http://www.greycouncil.com/sip/drafts/draft-johnston-sip-call-= flows-00.pdf

There=20 is also a draft on multi-proxy authorization at

http://www.greycouncil.co= m/sip/drafts/

Henry

-----Original Message-----
From:=20 owner-sip@lists.research.bell-labs.com=20 [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of = Itamar=20 Gilad
Sent: Sunday, January 02, 2000 2:56 AM
To: = 'SIP=20 List'
Subject: Call services

Am I = right in=20 assuming that draf-ietf-mmusic-sip-cc-01.txt ('SIP Call Control = Services") and=20 draft-sparks-sip-service-examples-00.txt ("SIP Telephony Service = Examples With=20 Call Flows") are the only authoritative documents describing call = services in=20 SIP? Any others?

Thanks

=20 Itamar Gilad

=20

--Boundary_(ID_zmDJoW2w5ltG6YJMB/ezVw)-- From owner-sip-outgoing@lists.research.bell-labs.com Sun Jan 2 13:09:55 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 NAA09584 for ; Sun, 2 Jan 2000 13:09:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4415B52B6; Sun, 2 Jan 2000 13:07:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8B7B652D5; Sun, 2 Jan 2000 13:07:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D230652B6 for ; Sun, 2 Jan 2000 13:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Jan 2 13:05:26 EST 2000 Received: from sj-mailhub-2.cisco.com ([171.69.43.88]) by dusty; Sun Jan 2 13:03:39 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA18003; Sun, 2 Jan 2000 10:06:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19583; Sun, 2 Jan 2000 10:04:23 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14447.37671.565541.682968@thomasm-u1.cisco.com> Date: Sun, 2 Jan 2000 10:04:23 -0800 (PST) To: Jonathan Rosenberg Cc: Scott Petrack , Henning Schulzrinne , "Daniel G. Petrie" , Henning Schulzrinne , Taji Rachid , "'Alvir Alisic (ECS)'" , sip@lists.research.bell-labs.com Subject: Re: JPEG in INVITE In-Reply-To: <3866C754.7A94606D@dynamicsoft.com> References: <3866C754.7A94606D@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > The issue is, if the content is referenced by indirection, is it better > to be in the body or in a header. Henning is arguing in favor of a > header. I agree with him that this is simpler. Both he and Dan are also > arguing that we need a way to identify the purpose of the content. > Providing such data also argues for it being a header. My concern, > though, is that there are so many uses for displaying of content, we > have no hope of enumerating them all. I suppose we could enumerate a few > and leave others to future standardization. Also, using a URI list in > the body is something thats doable now (since we support MIME already), > whereas a new header is yet-another-extension that I'd rather avoid. The > notion of a generic "body contains content to display", with the body > either in-line or referenced via a URI list, is appealing to me because > of its generality. Yes, we could have both, but then this seems to make > things even more complicated for a designer that now has to choose > whether to use the header or the indirect content in the body. With UDP, fragmentation, etc, vs other MIME headers would they not always have to choose? > Am I the only one who prefers the indirect references in the body > approach? I tend to think that URI is a much better method overall since the receiving side can make a determination of whether they want the content or not, and the timing of fetching the content. However, one thing to be said is that absent an existing IPSEC session between the two hosts (or possibly a third party), there will be delay to pay for the indirect method. Maybe this extra delay is managable for things like X-faces though. Mike From owner-sip-outgoing@lists.research.bell-labs.com Mon Jan 3 00:24:58 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 AAA15490 for ; Mon, 3 Jan 2000 00:24:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 46A6652AB; Mon, 3 Jan 2000 00:20:04 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8DA8152D5; Mon, 3 Jan 2000 00:20:03 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 83C0852AB for ; Mon, 3 Jan 2000 00:19:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Jan 3 00:17:29 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Mon Jan 3 00:15:43 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwiv27774; Mon, 3 Jan 2000 05:17:27 GMT Received: from dynamicsoft.com (1Cust165.tnt1.freehold.nj.da.uu.net [63.17.113.165]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id AAA02004; Mon, 3 Jan 2000 00:17:25 -0500 (EST) Message-ID: <38703297.E8D264B0@dynamicsoft.com> Date: Mon, 03 Jan 2000 00:24:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'SIP List'" Subject: Re: Call services References: <00Jan2.105532ist.115202@firewall.tlv.radvision.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 Many services are possible without having to explicitly define how they are done. A classic example is call screening. There are many varieties of this serivice (caller based, time of day based, priority based), all of which are possible in SIP, but none of which I think are described in the documents you mention. It only requires the server to reject the call based on some logic. -Jonathan R. > Itamar Gilad wrote: > > Am I right in assuming that draf-ietf-mmusic-sip-cc-01.txt ('SIP Call > Control Services") and draft-sparks-sip-service-examples-00.txt ("SIP > Telephony Service Examples With Call Flows") are the only > authoritative documents describing call services in SIP? Any others? > > Thanks > > Itamar Gilad > -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Mon Jan 3 16:45:58 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 QAA08000 for ; Mon, 3 Jan 2000 16:45:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1700C52B6; Mon, 3 Jan 2000 16:43:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 746F852BB; Mon, 3 Jan 2000 16:43:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 916C752B6 for ; Mon, 3 Jan 2000 16:43:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Jan 3 16:41:12 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Jan 3 16:39:21 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id QAA07534; Mon, 3 Jan 2000 16:41:05 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <3871274A.79CEC3B6@vovida.com> Date: Mon, 03 Jan 2000 16:48:42 -0600 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 Subject: Retransmissions behaviour on 1xx response Content-Type: multipart/alternative; boundary="------------C9A1664D9A0F8A488B4B0348" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------C9A1664D9A0F8A488B4B0348 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: It is given in the SIP spec, that retrans for INVITE stops when either a definitive or provisioan response is received. My question is on provisional response. If the caller gets a 100 Trying response,, which is essentially that the user has not yet been contacted, should the retrans. stop? Thanks. -- Sunitha Kumar --------------C9A1664D9A0F8A488B4B0348 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi:

It is given in the SIP spec, that retrans for INVITE stops when either a definitive or provisioan response is received. My question is on provisional response. If the caller gets a 100 Trying response,, which is essentially that the user has not yet been contacted, should the retrans. stop?

Thanks.

-- 
Sunitha Kumar

--------------C9A1664D9A0F8A488B4B0348-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Jan 3 17:25:43 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 RAA08403 for ; Mon, 3 Jan 2000 17:25:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0BE4652AB; Mon, 3 Jan 2000 17:23:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6916852C4; Mon, 3 Jan 2000 17:23:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A7A0752AB for ; Mon, 3 Jan 2000 17:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Jan 3 17:21:33 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Mon Jan 3 17:19:43 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwll10476; Mon, 3 Jan 2000 22:21:31 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id RAA01420; Mon, 3 Jan 2000 17:21:29 -0500 (EST) Message-ID: <3871229C.980AAA05@dynamicsoft.com> Date: Mon, 03 Jan 2000 17:28:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: Retransmissions behaviour on 1xx response References: <3871274A.79CEC3B6@vovida.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 Yes. Since request reliability is hop by hop, the next hop will retransmit the request to achieve end to end reliability. A UA should stop retransmitting an INVITE when it receives any response to it. -Jonathan R. Sunitha Kumar wrote: > > Hi: > > It is given in the SIP spec, that retrans for INVITE stops when either > a definitive or provisioan response is received. My question is on > provisional response. If the caller gets a 100 Trying response,, which > is essentially that the user has not yet been contacted, should the > retrans. stop? > > Thanks. > > -- > Sunitha Kumar > > -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 15:11:50 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 PAA05505 for ; Tue, 4 Jan 2000 15:11:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CEF4452DB; Tue, 4 Jan 2000 15:09:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3782E52DD; Tue, 4 Jan 2000 15:09:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C7B5E52DB for ; Tue, 4 Jan 2000 15:09:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jan 4 15:07:51 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Tue Jan 4 15:06:01 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id OAA20077; Tue, 4 Jan 2000 14:07:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA19007; Tue, 4 Jan 2000 14:07:41 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA15094; Tue, 4 Jan 2000 14:07:40 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA15261; Tue, 4 Jan 2000 14:07:39 -0600 (CST) Message-Id: <200001042007.OAA15261@b04a24.exu.ericsson.se> Subject: Re: JPEG in INVITE To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Tue, 4 Jan 2000 14:07:39 -0600 (CST) Cc: eussean@exu.ericsson.se (Sean Olson), scott.petrack@metatel.com (Scott Petrack), schulzrinne@cs.columbia.edu, Rachid.Taji@srit.siemens.fr, Alvir.Alisic@ecs.ericsson.se, sip@lists.research.bell-labs.com In-Reply-To: <3867BEC6.52B1A1AD@dynamicsoft.com> from "Jonathan Rosenberg" at Dec 27, 1999 02:32:22 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >There are some definite problems with this, but interestingly its more >or less conceptually how the PSTN guarantees caller ID service (sans the >crypto, of course). The service provider verifies the identity of the >caller's terminal based on the physical wires the call comes in on, and >inserts the name of the caller. This name is assumed known from offline >administrative procedures. ...which actually aren't even as secure as you suggest. I could call up Southwestern Bell and tell them that the name I want to go out when I call people is "Albert Einstein," "Superman," or "Jonathan Rosenberg." There is no verification of ID with caller ID. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 15:27:45 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 PAA05752 for ; Tue, 4 Jan 2000 15:27:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8066E52C4; Tue, 4 Jan 2000 14:51:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EAEF952DB; Tue, 4 Jan 2000 14:51:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 918E052C4 for ; Tue, 4 Jan 2000 14:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Jan 4 14:49:44 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Tue Jan 4 14:47:56 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA15132; Tue, 4 Jan 2000 13:49:42 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA13462; Tue, 4 Jan 2000 13:49:42 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA14024; Tue, 4 Jan 2000 13:49:41 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA15095; Tue, 4 Jan 2000 13:49:40 -0600 (CST) Message-Id: <200001041949.NAA15095@b04a24.exu.ericsson.se> Subject: Re: URL Generalization for Portability (was TRIP) To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Tue, 4 Jan 2000 13:49:40 -0600 (CST) Cc: Adam.Roach@ericsson.com (Adam B. Roach), dean.willis@wcom.com, sip@lists.research.bell-labs.com In-Reply-To: <385AB575.60B1CFCD@dynamicsoft.com> from "Jonathan Rosenberg" at Dec 17, 1999 05:13:09 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >I'm honestly queasy about this. One of things IP did right was to make >its addresses and domain names always well defined independent of where >you are located. With IP addresses, we never send just the last byte, >assuming that the router fills in the rest. In SIP, we did the same. We >pass around URLs, which are interpretable independent of the context. I think this is an argument, however unintentional, to eliminate the tel: URI. Without a tag to indicate context (which you are arguing against), they are not "Uniform" Resource Indicators. >I fully agree that users should not need to know about dial and number >plans. I also agree that users should be able to dial extensions and >local numbers as they do today in a PBX. I'd like to understand the >costs involved in having internationalization of numbers done within the >UA. Obtaining a dial plan automatically through a REGISTER response >would still allow an administrator to control it, and to modify it >(registrations get refreshed, so you can send updated versions in the >responses of refreshes). So, my questions are: how complex can a dial >plan be? How many entries in a dial plan table are there usually? How >much processing power does it take to compare a number against a dial >plan and internationalize it? It's not as much a matter of processing power as the code to perform internationalization and the size of the data necessary to do so. As both Dean and Rick have pointed out, the dialing plans which a phone may be required to understand can be very large and complicated (especially within an enterprise or VPN environment). As Rick has pointed out, he is currently running into very real memory limitations that make this processing impossible on the user agent. You can argue about theoretical processing power and memeory necessary to perform these sorts of things, but I'm afraid that real-world experience is going to have to trump theory. Imbedded clients are *already* running into limitations that prevent them from doing what you suggest they do. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 15:55:50 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 PAA06303 for ; Tue, 4 Jan 2000 15:55:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F34FC52BB; Tue, 4 Jan 2000 15:53:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6199352DE; Tue, 4 Jan 2000 15:53:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7FD5E52BB for ; Tue, 4 Jan 2000 15:53:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Jan 4 15:51:29 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Jan 4 15:49:40 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41714) id <0FNT00G01WE9G7@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 4 Jan 2000 20:46:58 +0000 (GMT) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #41714) with ESMTP id <0FNT00DLWWE4SN@firewall.mcit.com>; Tue, 04 Jan 2000 20:46:52 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id UAA05334; Tue, 04 Jan 2000 20:41:50 +0000 (GMT) Received: from C25766A ([166.35.153.18]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000104204701.MUUH16210@C25766A>; Tue, 04 Jan 2000 20:47:01 +0000 Date: Tue, 04 Jan 2000 14:46:49 -0600 From: Henry Sinnreich Subject: RE: URL Generalization for Portability (was TRIP) In-reply-to: <200001041949.NAA15095@b04a24.exu.ericsson.se> To: "Adam B. Roach" , Jonathan Rosenberg Cc: dean.willis@wcom.com, sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Adam, >As both Dean and Rick have pointed out, the dialing plans which >a phone may be required to understand can be very large and complicated >(especially within an enterprise or VPN environment). IP telephony gateways are now the priority model, but will not stay so forever. At that point in time, a non-legacy oriented solution may be far preferable, IMHO. A PDA or display phone screen may just be right for name@host.net... BTW: The practically the only place in the WSJ where you can find phone numbers are in ads. URLs dominate in all articles (quip credited to Chris Cunningham). Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Adam B. Roach Sent: Tuesday, January 04, 2000 1:50 PM To: Jonathan Rosenberg Cc: Adam B. Roach; dean.willis@wcom.com; sip@lists.research.bell-labs.com Subject: Re: URL Generalization for Portability (was TRIP) >I'm honestly queasy about this. One of things IP did right was to make >its addresses and domain names always well defined independent of where >you are located. With IP addresses, we never send just the last byte, >assuming that the router fills in the rest. In SIP, we did the same. We >pass around URLs, which are interpretable independent of the context. I think this is an argument, however unintentional, to eliminate the tel: URI. Without a tag to indicate context (which you are arguing against), they are not "Uniform" Resource Indicators. >I fully agree that users should not need to know about dial and number >plans. I also agree that users should be able to dial extensions and >local numbers as they do today in a PBX. I'd like to understand the >costs involved in having internationalization of numbers done within the >UA. Obtaining a dial plan automatically through a REGISTER response >would still allow an administrator to control it, and to modify it >(registrations get refreshed, so you can send updated versions in the >responses of refreshes). So, my questions are: how complex can a dial >plan be? How many entries in a dial plan table are there usually? How >much processing power does it take to compare a number against a dial >plan and internationalize it? It's not as much a matter of processing power as the code to perform internationalization and the size of the data necessary to do so. As both Dean and Rick have pointed out, the dialing plans which a phone may be required to understand can be very large and complicated (especially within an enterprise or VPN environment). As Rick has pointed out, he is currently running into very real memory limitations that make this processing impossible on the user agent. You can argue about theoretical processing power and memeory necessary to perform these sorts of things, but I'm afraid that real-world experience is going to have to trump theory. Imbedded clients are *already* running into limitations that prevent them from doing what you suggest they do. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 17:02:01 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 RAA07767 for ; Tue, 4 Jan 2000 17:02:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 11D0952DD; Tue, 4 Jan 2000 16:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 871B152DF; Tue, 4 Jan 2000 16:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A567F52DD for ; Tue, 4 Jan 2000 16:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jan 4 16:58:29 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Jan 4 16:56:40 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwpb01150; Tue, 4 Jan 2000 21:58:27 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id QAA02189; Tue, 4 Jan 2000 16:58:25 -0500 (EST) Message-ID: <38726EB9.9F1FFFED@dynamicsoft.com> Date: Tue, 04 Jan 2000 17:05:45 -0500 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: dean.willis@wcom.com, sip@lists.research.bell-labs.com Subject: Re: URL Generalization for Portability (was TRIP) References: <200001041949.NAA15095@b04a24.exu.ericsson.se> 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 "Adam B. Roach" wrote: > > >I'm honestly queasy about this. One of things IP did right was to make > >its addresses and domain names always well defined independent of where > >you are located. With IP addresses, we never send just the last byte, > >assuming that the router fills in the rest. In SIP, we did the same. We > >pass around URLs, which are interpretable independent of the context. > > I think this is an argument, however unintentional, to eliminate > the tel: URI. Without a tag to indicate context (which you are > arguing against), they are not "Uniform" Resource Indicators. No, its more an argument for using the tel URL when in its internationalized form: tel:+17327417244 The tel URL does allow for phone contexts that help identify where the URL is valid. For example, you can include a prefix as a context (like +1 516) to indicate that the number can only be called from that area: tel:5551212;phone-context=+1516 This is useful when you imbed a tel URL in a web page in an intranet for a company on Long Island. This way, the modem in the PC just dials 5551212; no area code is needed from there. Our application of the tel URL is slightly different. We are not using them to actual dial numbers from web pages. Rather, they point to resources in the PSTN. In that sense, I agree with Adam that what I think we want is for them to be uniform, so that they are resolvable from everywhere. This means they should either be international numbers, or be sip URLs which indicate where to go to get them resolved. So, in the case of a gateway sending just dialed digits to a proxy, I argued that we should use a SIP URL and put the contexts and stuff into the user portion. Several folks complained about that; is it more palatable to use the phone-context from the tel URL as part of the SIP URL? sip:334@wcom.com;phone-context=0000034 -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 19:05:56 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 TAA10068 for ; Tue, 4 Jan 2000 19:05:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6975852C4; Tue, 4 Jan 2000 19:03:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CB88452DF; Tue, 4 Jan 2000 19:03:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 02F4B52C4 for ; Tue, 4 Jan 2000 19:03:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jan 4 19:01:07 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Tue Jan 4 18:59:18 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id SAA19213; Tue, 4 Jan 2000 18:01:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id SAA17614; Tue, 4 Jan 2000 18:01:03 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA26116; Tue, 4 Jan 2000 18:01:03 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id SAA25174; Tue, 4 Jan 2000 18:01:02 -0600 (CST) Date: Tue, 4 Jan 2000 18:01:02 -0600 (CST) Message-Id: <200001050001.SAA25174@b04a45.exu.ericsson.se> To: Adam.Roach@ericsson.com, jdrosen@dynamicsoft.com Subject: Re: URL Generalization for Portability (was TRIP) Cc: dean.willis@wcom.com, sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > Our application of the tel URL is slightly different. We are > not using them > to actual dial numbers from web pages. Rather, they point to resources > in the PSTN. In > that sense, I agree with Adam that what I think we want is for them to > be uniform, so > that they are resolvable from everywhere. This means they should either > be international > numbers, or be sip URLs which indicate where to go to get them resolved. > But you can do this with the tel: URL as well by providing the tsp parameter. The main distinction that I see between the sip: and tel: URLs is that with the tel: URL, you know DEFINITIVELY that the resource that you are referring to is a PSTN telephone. With the sip: URL this becomes trickier. Are you referring to an IP/PC SIP client with a numeric ID that is convenient to dial from a plain black phone, or are you actually referring to a genuine PSTN terminal? The distinction is (usefully) blurred. > So, in the case of a gateway sending just dialed digits to a proxy, I > argued that we should use a SIP URL and put the contexts and stuff into > the user portion. Several folks complained about that; is it more > palatable to use the phone-context from the tel URL as part of the SIP > URL? > > sip:334@wcom.com;phone-context=0000034 > It seems more logical, IMHO, to stuff everything into the user portion. This allows you to easily distinguish between parameters directly related to the user and parameters related to, for example, the preferred SIP transport. > -Jonathan R. > > -- > 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 > ----------------------------------------------------------------- Sean Olson mailto:sean.olson@ericsson.com Ericsson Inc. tel:(972)583-5472 fax:(972)669-0154 From owner-sip-outgoing@lists.research.bell-labs.com Tue Jan 4 19:09:43 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 TAA10154 for ; Tue, 4 Jan 2000 19:09:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D6E6252DF; Tue, 4 Jan 2000 19:07:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4FF3052E0; Tue, 4 Jan 2000 19:07:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CC75F52DF for ; Tue, 4 Jan 2000 19:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jan 4 19:06:15 EST 2000 Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Tue Jan 4 19:04:26 EST 2000 Received: from jmpolk-8k ([171.71.126.142] (may be forged)) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA24225; Tue, 4 Jan 2000 16:06:12 -0800 (PST) Message-Id: <4.1.20000104175635.00bcc6e0@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Jan 2000 18:06:31 -0600 To: sip@lists.research.bell-labs.com From: "James M. Polk" Subject: Prioritization limitation question Cc: rtbell@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26036514==_.ALT" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --=====================_26036514==_.ALT Content-Type: text/plain; charset="us-ascii" Anyone/everyone Reading the ANSI document T1.619-1992 a colleague pointed out to me, I came across its MLPP Prioritization requirements as being the following: 1) 0 Flash Override (Highest) 2) 1 Flash 3) 2 Immediate 4) 3 Priority 5) 4 Routine (Lowest) But looking at SIP grammar/syntax, it only stipulates 4 levels of priority as the following: priority-value = "emergency" | "urgent" | "normal" | "non-urgent" Question: Has there been any discussion (which I haven't found yet) on matching these two specifications? And for clarification, I strongly prefer SIP moving up to having 5 levels instead of ANSI moving down to 4 levels in order to meet current US Government/Military Regulations I really don't want to ask them to change. Comments/clarifications are welcome, thank you. _______________________________________________________ A sobering reflection upon this century's greatest accomplishments and discoveries: "There is no keystroke that rewrites racism... nor is there any software that takes care of Mother Earth" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5199 www.cisco.com --=====================_26036514==_.ALT Content-Type: text/html; charset="us-ascii"

Anyone/everyone

Reading the ANSI document T1.619-1992 a colleague pointed out to me, I came across its MLPP Prioritization requirements as being the following:

1) 0 Flash Override (Highest)

2) 1 Flash

3) 2 Immediate

4) 3 Priority

5) 4 Routine (Lowest)

But looking at SIP grammar/syntax, it only stipulates 4 levels of priority as the following:

priority-value = "emergency" | "urgent" | "normal" | "non-urgent"

Question: Has there been any discussion (which I haven't found yet) on matching these two specifications? And for clarification, I strongly prefer SIP moving up to having 5 levels instead of ANSI moving down to 4 levels in order to meet current US Government/Military Regulations I really don't want to ask them to change.

Comments/clarifications are welcome, thank you.

_______________________________________________________
A sobering reflection upon this century's greatest accomplishments and discoveries:
"There is no keystroke that rewrites racism... nor is there any software that takes care of Mother Earth"

Adam

Brian states the conclusions I wish to accomplish. There are quite a few IP only Voice environments being planned and implemented -- with PSTN access in and out very controlled or non-existent. In this case, having the 5 priorities explicitly allows SIP into environments requiring MLPP. Not having all 5 completely eliminates SIP -- as "Flash Override" is a very required feature/application. I do understand why there needs to be a great amount of individuality within the development of a protocol with specific interoperability interfacing requirements defined and limited to not overwhelm the new protocol's intent. But with inclusion of this 5th priority, virtually all MLPP implementations will at that point include SIP as viable; likely not before this time though.

I'm just suggesting the addition of a single value within a defined variable-set. I'm not suggesting a new variable, or taking the protocol in a new direction.

At 08:16 AM 1/5/2000 -0500, Rosen, Brian wrote:

>What if you were trying to implement MLPP where the individual

>stations were trusted, in particular, for a customer like the

>government? You are saying SIP cannot be used for a government application,

>which typically require MLPP.

>There isn't any reason NOT to use the existing convention; they

>do everything the current SIP priority does. If you make them

>backwards compatible, you lose nothing, you gain compatibility.

>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: Adam B. Roach [mailto:Adam.Roach@Ericsson.com]

>> Sent: Tuesday, January 04, 2000 8:35 PM

>> To: jmpolk@cisco.com

>> Cc: sip@lists.research.bell-labs.com; rtbell@cisco.com

>> Subject: Re: Prioritization limitation question

>> >Anyone/everyone

>> >

>> >Reading the ANSI document T1.619-1992 a colleague pointed

>> out to me, I came

>> >across its MLPP Prioritization requirements as being the following:

>> >

>> >1) 0 Flash Override (Highest)

>> >2) 1 Flash

>> >3) 2 Immediate

>> >4) 3 Priority

>> >5) 4 Routine (Lowest)

>> >But looking at SIP grammar/syntax, it only stipulates 4

>> levels of priority as

>> >the following:

>> >

>> >priority-value = "emergency" | "urgent" | "normal" | "non-urgent"

>> >

>> >Question: Has there been any discussion (which I haven't

>> found yet) on matching

>> >these two specifications? And for clarification, I strongly

>> prefer SIP moving

>> >up to having 5 levels instead of ANSI moving down to 4

>> levels in order to meet

>> >current US Government/Military Regulations I really don't

>> want to ask them to

>> >change.

>> No, this has not been discussed; however, consider that SIP

>> clients are

>> not to be treated as trusted nodes (since users have direct

>> control over

>> them). If some PSTN gateway were taking my client's word for it, I'd

>> hack mine to send out whatever would generate "flash override" as the

>> priority whenever I couldn't get through. Not the sort of thing you

>> really want me to be able to do, I imagine.

>> So, given that you will only trust this information when it comes from

>> another PSTN gateway, I would propose that, instead of trying to mold

>> the SIP architecture to fit ITU and ANSI documents, it would seem to

>> make sense to tunnel your ISUP and TCAP messages end-to-end (which

>> you're obviously *already* doing, since you can't activate CCBS

>> without receiving an appropriate indicator in the diagnostic field of

>> the cause parameter of a REL message, right?).

>> It wouldn't hurt to map MLPP priorities down into the SIP priorities,

>> just in case you *do* terminate on a native SIP client (flash

>> override

>> and flash translate to emergency; immediate and priority translate to

>> urgent; routine translates to normal) -- but I wouldn't

>> actually trust

>> these going back *into* the PSTN. The reason for this is

>> that, in SIP,

>> the priorities are a heuristic, meant more for conveying

>> information to

>> the user. In the PSTN, the MLPP priorities are absolutes, meant for

>> conveying information to the network.

>> Finally, you'll note that there are actually sixteen

>> priorities available

>> for MLPP (even though only five are defined by the ITU and

>> ANSI). It's

>> possible that current proprietary or future ISUP protocols

>> will define

>> further priorities. It would, of course, be absurd to come up

>> with sixteen

>> SIP priority names to accomodate this possible eventuality,

>> and the prospect

>> of having numeric priorities for SIP has already been

>> discussed and soundly

>> rejected (if my occasonally fuzzy memory serves me well today).

>> --

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

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) 972.813.5199
www.cisco.com --=====================_1236468==_.ALT-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 12:51:56 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 MAA11902 for ; Wed, 5 Jan 2000 12:51:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BFA0B52E5; Wed, 5 Jan 2000 12:49:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3B3FD52E8; Wed, 5 Jan 2000 12:49:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9167752E5 for ; Wed, 5 Jan 2000 12:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 12:47:26 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Wed Jan 5 12:45:38 EST 2000 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id LAA25865; Wed, 5 Jan 2000 11:45:22 -0600 (CST) 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 LAA06977; Wed, 5 Jan 2000 11:45:21 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA04712; Wed, 5 Jan 2000 11:45:21 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA18290; Wed, 5 Jan 2000 11:45:18 -0600 (CST) Message-Id: <200001051745.LAA18290@b04a24.exu.ericsson.se> Subject: Re: Prioritization limitation question To: jmpolk@cisco.com (James M. Polk) Date: Wed, 5 Jan 2000 11:45:17 -0600 (CST) Cc: brosen@fore.com (Rosen Brian), Adam.Roach@ericsson.com ('Adam B. Roach'), sip@lists.research.bell-labs.com, rtbell@cisco.com In-Reply-To: <4.1.20000105105551.00a50340@diablo.cisco.com> from "James M. Polk" at Jan 05, 2000 11:05:55 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >Brian states the conclusions I wish to accomplish. There are quite a few IP >only Voice environments being planned and implemented -- with PSTN access in >and out very controlled or non-existent. In this case, having the 5 priorities >explicitly allows SIP into environments requiring MLPP. I mistook your problem to be a PSTN interworking one; sorry. >Not having all 5 >completely eliminates SIP -- as "Flash Override" is a very required >feature/application. I do understand why there needs to be a great amount of >individuality within the development of a protocol with specific >interoperability interfacing requirements defined and limited to not overwhelm >the new protocol's intent. But with inclusion of this 5th priority, virtually >all MLPP implementations will at that point include SIP as viable; likely not >before this time though. The SIP Priority: header does not currently provide anything like MLPP. It is not specified that it is to be used for call pre-emption. I beleive you'll find that most clients use it to render the incoming call (e.g. making the screen flash, or making the phone ring particularly urgently), if at all. Extending the number of priorites will merely change the syntax without adding the semantics you desire. I propose that, if you need this functionality, you write up an internet draft specifying how to negotiate between clients that MLPP is available, the exact behavior expected, and the method of conveying MLPP priority levels. For simplicity of mapping, I'd take a look at ITU Q.733.3 and Q.955.3. As an overview, I'd include a header (similar to the CCBS diagnostic) in the 486, 600, and 603 (and possibly 182) responses to INVITE which indicates that the client is CCBS-capable. The originating client would then re-launch the INVITE with some indication that it is invoking the CCBS service, along with the priority of the incoming call. But merely extending the enumeration of values allowed in the Priority: header is *wildly* insufficient for what you require. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 12:55:56 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 MAA12008 for ; Wed, 5 Jan 2000 12:55:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A329252E1; Wed, 5 Jan 2000 12:53:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 23B6552E2; Wed, 5 Jan 2000 12:53:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1990B52E1 for ; Wed, 5 Jan 2000 12:53:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jan 5 12:51:50 EST 2000 Received: from alpha.mcit.com ([199.249.19.243]) by dusty; Wed Jan 5 12:50:00 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416) id <0FNV00201IPTLH@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 5 Jan 2000 17:46:41 +0000 (GMT) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FNV002E5IPS1H@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 05 Jan 2000 17:46:40 +0000 (GMT) Received: from omzexch007.mcit.com (OMZEXCH007.mcit.com [166.37.194.38]) by omzrelay.mcit.com (8.8.7/) with ESMTP id RAA23064 for ; Wed, 05 Jan 2000 17:46:50 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id ; Wed, 05 Jan 2000 17:46:40 +0000 Content-return: allowed Date: Wed, 05 Jan 2000 17:46:38 +0000 From: "Donovan, Steven R." Subject: tel:# versus sip:#@host;user=phone To: sip@lists.research.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D8019019@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: owner-sip@lists.research.bell-labs.com Precedence: bulk Discussions in the "URL Generalization for Portability (was TRIP)" thread have me a little confused. It was my understanding that the reason for the user=phone construct in the sip url was because the tel url definition was still in draft stage. As such, I had always thought that a sip url with user=phone represented the same address as a tel url with the same number. As such, in my mind (warped as it might be) the following two INVITE messages are used to call the same PSTN phone number: INVITE sip:+19725551212@wcom.com;user=phone SIP/2.0 ... INVITE tel:+19725551212 SIP/2.0 ... In both of these cases, the caller wants to reach someone at the number 19725551212. Note that this does not necessarily mean in either case that the call will routed to a PSTN phone that has 19725551212 printed on the front of it or that is connected to a switch via a line interface that is identified by that number. There are many points between the caller and callee of the call where the caller address can be changed. It is equally valid for both of the above cases to change +19725551212 to dallas@directory-assistance.com and have the call fowarded to a SIP based directory assistance platform as illustrated in the following: Callee to Proxy Server INVITE tel:+19725551212 SIP/2.0 From: joe@home To: tel:+19725551212 ... Proxy Server to Directory Assistance Platform INVITE dallas@directory-assistance.com SIP/2.0 From: joe@home To: tel:+19725551212 ... The resent discussions imply that the tel url and sip user=phone addresses would be treated differently. This does not seem wise to me. Steve From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 13:46:13 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 NAA13058 for ; Wed, 5 Jan 2000 13:46:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 166C952E4; Wed, 5 Jan 2000 13:39:55 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8DE1752E2; Wed, 5 Jan 2000 13:39:52 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A9E1D52E2 for ; Wed, 5 Jan 2000 13:39:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jan 5 13:39:01 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Jan 5 13:37:13 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwsg04575; Wed, 5 Jan 2000 18:34:18 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id NAA05469; Wed, 5 Jan 2000 13:34:17 -0500 (EST) Message-ID: <38739067.6D7E18F2@dynamicsoft.com> Date: Wed, 05 Jan 2000 13:41:43 -0500 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: "James M. Polk" , Rosen Brian , sip@lists.research.bell-labs.com, rtbell@cisco.com Subject: Re: Prioritization limitation question References: <200001051745.LAA18290@b04a24.exu.ericsson.se> 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 I agree 100% with Adam here. The semantics of Priority are not what you want. If this feature is critical to your deployment, please do write up a draft with a proposal on how it works. -Jonathan R. "Adam B. Roach" wrote: > > The SIP Priority: header does not currently provide anything like MLPP. > It is not specified that it is to be used for call pre-emption. I beleive > you'll find that most clients use it to render the incoming call (e.g. > making the screen flash, or making the phone ring particularly urgently), > if at all. > > Extending the number of priorites will merely change the syntax without > adding the semantics you desire. > > I propose that, if you need this functionality, you write up an > internet draft specifying how to negotiate between clients that > MLPP is available, the exact behavior expected, and the method > of conveying MLPP priority levels. For simplicity of mapping, > I'd take a look at ITU Q.733.3 and Q.955.3. As an overview, > I'd include a header (similar to the CCBS diagnostic) in the > 486, 600, and 603 (and possibly 182) responses to INVITE which > indicates that the client is CCBS-capable. The originating client > would then re-launch the INVITE with some indication that it is > invoking the CCBS service, along with the priority of the incoming > call. > > But merely extending the enumeration of values allowed in the > Priority: header is *wildly* insufficient for what you require. > > -- > 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 -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 14:14:47 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 OAA13844 for ; Wed, 5 Jan 2000 14:14:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6222B52E8; Wed, 5 Jan 2000 13:39:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7896352E6; Wed, 5 Jan 2000 13:39:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AC0FE52E4 for ; Wed, 5 Jan 2000 13:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 13:37:43 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Wed Jan 5 13:35:54 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 76280819; Wed, 5 Jan 2000 10:37:38 -0800 (PST) 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 SAA03423; Wed, 5 Jan 2000 18:37:36 GMT Message-ID: <38738FEC.3F7D215A@hplb.hpl.hp.com> Date: Wed, 05 Jan 2000 18:39:40 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Scott Petrack , Henning Schulzrinne , "Daniel G. Petrie" , Henning Schulzrinne , Taji Rachid , "'Alvir Alisic (ECS)'" , sip@lists.research.bell-labs.com Subject: Re: JPEG in INVITE References: <3866C754.7A94606D@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: > > The issue is, if the content is referenced by indirection, is it better > to be in the body or in a header. Henning is arguing in favor of a > header. I agree with him that this is simpler. Both he and Dan are also > arguing that we need a way to identify the purpose of the content. > Providing such data also argues for it being a header. I would say that the reason body parts are preferrable over headers is that we're likely to wish to associate various content descriptors with the "extra" content, regardless of whether it is included inline or by reference. There may be a variety of such descriptors, some of them which we know about now (most of which are probably already well-defined), and some which we can't imagine now and which may have a purpose completely unlike other descriptors. To me it seems to make sense to have a single mechanism for associating descriptors with directly and indirectly included content (I believe this is how MHTML works also). This indicates that using MIME body parts is the more prudent choice here, even though it's tempting to go for the admittedly simpler but also more shortsighted approach of sticking URLs into headers. Incidentally, the X-Face header recognized by some XEmacs mailer holds an image inline in some obscure bitmap format. The idea was great and it's a mystery why this isn't a widely supported feature today - maybe because of the pain involved in generating a decent quality image that fits in just a couple of hundred bytes. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 14:41:50 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 OAA14423 for ; Wed, 5 Jan 2000 14:41:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4332C52E0; Wed, 5 Jan 2000 14:39:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A7FB652E6; Wed, 5 Jan 2000 14:39:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 850DE52E0 for ; Wed, 5 Jan 2000 14:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 14:38:27 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Jan 5 14:36:39 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwsk27294; Wed, 5 Jan 2000 19:38:22 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id OAA05531; Wed, 5 Jan 2000 14:38:20 -0500 (EST) Message-ID: <38739F69.88C29A2E@dynamicsoft.com> Date: Wed, 05 Jan 2000 14:45:45 -0500 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 Subject: Re: tel:# versus sip:#@host;user=phone References: <75C79E507864D3118AFC00805FEAB7D8019019@ripexch001.mcit.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 "Donovan, Steven R." wrote: > > Discussions in the "URL Generalization for Portability (was TRIP)" thread > have me a little confused. > > It was my understanding that the reason for the user=phone construct in the > sip url was because the tel url definition was still in draft stage. As > such, I had always thought that a sip url with user=phone represented the > same address as a tel url with the same number. No; the user=phone simply stated that the user portion is built using the BNF of telephone-subscriber. Beyond that, its still a SIP URL. > The resent discussions imply that the tel url and sip user=phone addresses > would be treated differently. Not differently in the sense you describe. In either case, it would still be true that the call might be routed to some other URL which is not associated with the telephone number at all (sip:directory-service@wcom.com, for example). The debate is really around numbers that are not uniform, in the sense that they aren't usable everywhere. For an international e164 number, using the tel URL for: tel:+17327417244 or sip:+17327417244@wcom.com is likely to have the same effect. But, with a number which is private, the tel URL doesn't (I've been arguing) provide sufficient information to figure out how to resolve the number, while the SIP URL form does. -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 14:47:49 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 OAA14564 for ; Wed, 5 Jan 2000 14:47:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 550A752E6; Wed, 5 Jan 2000 14:45:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF4A452E9; Wed, 5 Jan 2000 14:45:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E4D5452E6 for ; Wed, 5 Jan 2000 14:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 14:44:28 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Wed Jan 5 14:42:38 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id NAA29995; Wed, 5 Jan 2000 13:44:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA01418; Wed, 5 Jan 2000 13:44:18 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA10968; Wed, 5 Jan 2000 13:44:18 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA19383; Wed, 5 Jan 2000 13:44:15 -0600 (CST) Message-Id: <200001051944.NAA19383@b04a24.exu.ericsson.se> Subject: Re: Prioritization limitation question To: brosen@fore.com (Rosen Brian) Date: Wed, 5 Jan 2000 13:44:15 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685E9@whq-msgusr-02.fore.com> from "Rosen, Brian" at Jan 05, 2000 02:05:20 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >I agree we will have to have a fully worked out proposal >not just an additional level or two. > >Do you believe that the existing SIP priority field should be >reused (essentially having a way to state that the priority is >mandatory, not advisory), or add a whole new field? >I'd rather the former. I'd propose using different headers, simply because I don't like the philosophy of overloading existing headers in extensions to mean semanticaly different things. I propose that your callflow might look like: * I launch a normal invite to Joe: INVITE sip:joe@bob.com SIP/2.0 To: From: ;tag=13948753987 Call-Id: 13078245@ws0985.ericsson.com CSeq: 1 INVITE Via: SIP/2.0/UDP ws0985.ericsson.com * His MLPP-capable device responds with a busy, and an indication that he supports MLPP (along with a version, in case the semantics need updating in the future): SIP/2.0 486 Busy Here To: ;tag=a872-27bc-287e-7d7f From: ;tag=13948753987 Call-Id: 13078245@ws0985.ericsson.com CSeq: 1 INVITE MLPP-Version: 1 * Seeing that his phone supports a version of MLPP that my phone is capable of, my phone gives me the option of invoking the CCBS service. I activate it with a level of immediate (2). The phone re-launches my INVITE request to Joe's phone: INVITE sip:joe@bob.com SIP/2.0 To: From: ;tag=13948753987 Call-Id: 13078245@ws0985.ericsson.com CSeq: 2 INVITE Via: SIP/2.0/UDP ws0985.ericsson.com MLPP-Version: 1 MLPP-Priority: 2 * Joe's phone "does the right thing" and takes my call: SIP/2.0 200 Okay To: ;tag=7f27-237e-ab71-0277 From: ;tag=13948753987 Call-Id: 13078245@ws0985.ericsson.com CSeq: 2 INVITE Before soneone starts a discussion on the fact that the INVITE must be launched twice: note that this is the same way this service is handled in the PSTN currently. A call attempt gets a busy indication with a CCBS flag set; the call attempt is then re-launched with MLPP. Presumably, this is done for a reason. The above solution should satisfy the same requirements as the PSTN version of this service. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 18:06:05 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 SAA17659 for ; Wed, 5 Jan 2000 18:06:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DD45E52E2; Wed, 5 Jan 2000 18:03:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 562C052E5; Wed, 5 Jan 2000 18:03:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 22DF652E2 for ; Wed, 5 Jan 2000 18:03:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 18:01:31 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Jan 5 17:59:42 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwsy12857; Wed, 5 Jan 2000 23:01:28 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id SAA05973; Wed, 5 Jan 2000 18:01:26 -0500 (EST) Message-ID: <3873CF03.AEE128B9@dynamicsoft.com> Date: Wed, 05 Jan 2000 18:08:51 -0500 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: Rosen Brian , sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question References: <200001051944.NAA19383@b04a24.exu.ericsson.se> 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 Rather than using this MLPP-Version thing to indicate support for CCBS, I'd rather use the more generic Supported/Require mechanism (a draft on this is pending within the next few days). So, C->S INVITE S->C 421 Feature Available Require: com.cisco.mlpp C->S INVITE Supported: com.cisco.mlpp MLPP: 2;version=1 S->C 200 OK -Jonathan R. "Adam B. Roach" wrote: > > >I agree we will have to have a fully worked out proposal > >not just an additional level or two. > > > >Do you believe that the existing SIP priority field should be > >reused (essentially having a way to state that the priority is > >mandatory, not advisory), or add a whole new field? > >I'd rather the former. > > I'd propose using different headers, simply because I don't > like the philosophy of overloading existing headers in extensions > to mean semanticaly different things. I propose that your callflow > might look like: > > * I launch a normal invite to Joe: > > INVITE sip:joe@bob.com SIP/2.0 > To: > From: ;tag=13948753987 > Call-Id: 13078245@ws0985.ericsson.com > CSeq: 1 INVITE > Via: SIP/2.0/UDP ws0985.ericsson.com > > * His MLPP-capable device responds with a busy, and an > indication that he supports MLPP (along with a version, > in case the semantics need updating in the future): > > SIP/2.0 486 Busy Here > To: ;tag=a872-27bc-287e-7d7f > From: ;tag=13948753987 > Call-Id: 13078245@ws0985.ericsson.com > CSeq: 1 INVITE > MLPP-Version: 1 > > * Seeing that his phone supports a version of MLPP that my phone is > capable of, my phone gives me the option of invoking the CCBS service. > I activate it with a level of immediate (2). The phone re-launches > my INVITE request to Joe's phone: > > INVITE sip:joe@bob.com SIP/2.0 > To: > From: ;tag=13948753987 > Call-Id: 13078245@ws0985.ericsson.com > CSeq: 2 INVITE > Via: SIP/2.0/UDP ws0985.ericsson.com > MLPP-Version: 1 > MLPP-Priority: 2 > > * Joe's phone "does the right thing" and takes my call: > > SIP/2.0 200 Okay > To: ;tag=7f27-237e-ab71-0277 > From: ;tag=13948753987 > Call-Id: 13078245@ws0985.ericsson.com > CSeq: 2 INVITE > > Before soneone starts a discussion on the fact that > the INVITE must be launched twice: note that this is the > same way this service is handled in the PSTN currently. A > call attempt gets a busy indication with a CCBS flag set; > the call attempt is then re-launched with MLPP. Presumably, > this is done for a reason. The above solution should > satisfy the same requirements as the PSTN version of this > service. > > -- > 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 -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Wed Jan 5 18:53:45 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 SAA18394 for ; Wed, 5 Jan 2000 18:53:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BF39252C4; Wed, 5 Jan 2000 18:51:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3299652E9; Wed, 5 Jan 2000 18:51:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9CF5252C4 for ; Wed, 5 Jan 2000 18:51:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jan 5 18:50:06 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Wed Jan 5 18:48:17 EST 2000 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id RAA02466; Wed, 5 Jan 2000 17:50:04 -0600 (CST) 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 RAA01940; Wed, 5 Jan 2000 17:50:03 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA23779; Wed, 5 Jan 2000 17:50:03 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id RAA20068; Wed, 5 Jan 2000 17:50:02 -0600 (CST) Message-Id: <200001052350.RAA20068@b04a24.exu.ericsson.se> Subject: Re: Prioritization limitation question To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Wed, 5 Jan 2000 17:50:02 -0600 (CST) Cc: Adam.Roach@ericsson.com (Adam B. Roach), brosen@fore.com (Rosen Brian), sip@lists.research.bell-labs.com In-Reply-To: <3873CF03.AEE128B9@dynamicsoft.com> from "Jonathan Rosenberg" at Jan 05, 2000 06:08:51 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: >Rather than using this MLPP-Version thing to indicate support for CCBS, >I'd rather use the more generic Supported/Require mechanism (a draft on >this is pending within the next few days). So, > >C->S INVITE > >S->C 421 Feature Available >Require: com.cisco.mlpp > >C->S INVITE >Supported: com.cisco.mlpp >MLPP: 2;version=1 > >S->C 200 OK It sounds like you're adding yet another round trip: the first to agree on the feature, the second to try an invite (which gets a "busy" response), and the third to invoke the feature (am I misreading something here?) Keep in mind that MLPP is relevant only when the far side returns an indication like "busy." Only *after* the calling party is notified that the far side is busy does he make a decision that he wants to break in on the call. Also, in PSTN interoperation scenarios, the gateway won't know that you can break in on the called party until the busy indication arrives (since we're just pumping the call back into the network and don't necessarily know the capability of the end office to which the subscriber is physically connected) -- so negotiation of the feature cannot occur before an attempt is made to reach the called party. If we're going to go out of our way to borrow a service from ISUP, we'd be exceedingly foolish not to make them able to interoperate. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 09:32:21 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 JAA12874 for ; Thu, 6 Jan 2000 09:32:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A99C252E2; Thu, 6 Jan 2000 09:27:10 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 34EF052B6; Thu, 6 Jan 2000 09:27:09 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 02EBC52E0 for ; Tue, 4 Jan 2000 21:31:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jan 4 21:30:28 EST 2000 Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Tue Jan 4 21:28:39 EST 2000 Received: from rtbell-isdn4 (dhcp-dp2-158-221.cisco.com [171.71.158.221]) by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA18693; Tue, 4 Jan 2000 20:30:18 -0600 (CST) Message-Id: <4.2.0.58.20000104192345.00ae0a00@orinoco.cisco.com> X-Sender: rtbell@orinoco.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 04 Jan 2000 19:30:16 -0700 To: "Adam B. Roach" , jmpolk@cisco.com (James M. Polk) From: Bob Bell Subject: Re: Prioritization limitation question Cc: sip@lists.research.bell-labs.com In-Reply-To: <200001050135.TAA16608@b04a24.exu.ericsson.se> References: <4.1.20000104175635.00bcc6e0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Adam - Comments imbedded. At 06:35 PM 1/4/00, Adam B. Roach wrote: > >Anyone/everyone > > > >Reading the ANSI document T1.619-1992 a colleague pointed out to me, I came > >across its MLPP Prioritization requirements as being the following: > > > >1) 0 Flash Override (Highest) > >2) 1 Flash > >3) 2 Immediate > >4) 3 Priority > >5) 4 Routine (Lowest) > > >But looking at SIP grammar/syntax, it only stipulates 4 levels of > priority as > >the following: > > > >priority-value = "emergency" | "urgent" | "normal" | "non-urgent" > > > >Question: Has there been any discussion (which I haven't found yet) on > matching > >these two specifications? And for clarification, I strongly prefer SIP > moving > >up to having 5 levels instead of ANSI moving down to 4 levels in order > to meet > >current US Government/Military Regulations I really don't want to ask > them to > >change. > >No, this has not been discussed; however, consider that SIP clients are >not to be treated as trusted nodes (since users have direct control over >them). If some PSTN gateway were taking my client's word for it, I'd >hack mine to send out whatever would generate "flash override" as the >priority whenever I couldn't get through. Not the sort of thing you >really want me to be able to do, I imagine. >>>Bob In a totally IP environment, there would be no PSTN gateways. The precedence values would be used to determine the order in which packets would be dropped at congestion points so as to allow the higher priority "calls" to be undegraded under congested conditions. For the enforcement, perhaps this service requires the use of a "trusted" proxy to authenticate a user request for a high priority call. <<So, given that you will only trust this information when it comes from >another PSTN gateway, I would propose that, instead of trying to mold >the SIP architecture to fit ITU and ANSI documents, it would seem to >make sense to tunnel your ISUP and TCAP messages end-to-end (which >you're obviously *already* doing, since you can't activate CCBS >without receiving an appropriate indicator in the diagnostic field of >the cause parameter of a REL message, right?). > >It wouldn't hurt to map MLPP priorities down into the SIP priorities, >just in case you *do* terminate on a native SIP client (flash override >and flash translate to emergency; immediate and priority translate to >urgent; routine translates to normal) -- but I wouldn't actually trust >>>Bob Mapping the Flash and Flash Override into the same value basically eliminates the differences between them. There is a real, tactical difference for the distinction. <<these going back *into* the PSTN. The reason for this is that, in SIP, >the priorities are a heuristic, meant more for conveying information to >the user. In the PSTN, the MLPP priorities are absolutes, meant for >conveying information to the network. > >Finally, you'll note that there are actually sixteen priorities available >for MLPP (even though only five are defined by the ITU and ANSI). It's >possible that current proprietary or future ISUP protocols will define >further priorities. It would, of course, be absurd to come up with sixteen >SIP priority names to accomodate this possible eventuality, and the prospect >of having numeric priorities for SIP has already been discussed and soundly >rejected (if my occasonally fuzzy memory serves me well today). >>>Bob Perhaps using only a keyword followed by a numeric value could be used. <<-- >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 Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 09:34:58 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 JAA12973 for ; Thu, 6 Jan 2000 09:34:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 25DBD52B6; Thu, 6 Jan 2000 09:28:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B93AD52F0; Thu, 6 Jan 2000 09:28:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 699FD52E1 for ; Wed, 5 Jan 2000 22:59:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jan 5 22:59:02 EST 2000 Received: from rakshaka.wipsys.soft.net ([164.164.68.8]) by dusty; Wed Jan 5 22:57:11 EST 2000 Received: (from fwtk@localhost) by rakshaka.wipsys.soft.net (8.9.1b+Sun/8.9.1) id JAA08668 for ; Thu, 6 Jan 2000 09:30:39 GMT X-Authentication-Warning: rakshaka.wipsys.soft.net: fwtk set sender to using -f Received: from unknown(192.168.172.18) by rakshaka.wipsys.soft.net via smap (V2.0) id xma008651; Thu, 6 Jan 00 09:30:28 GMT Received: from wipsys.soft.net ([192.168.178.175]) by ecmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA1893 for ; Thu, 6 Jan 2000 09:24:39 +0530 Message-ID: <3874123E.5E4F14DD@wipsys.soft.net> Date: Thu, 06 Jan 2000 09:25:43 +0530 From: "ANIRBAN ROY" X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: A case related to "home Phone" type of functionality in SIP 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 hi, I am trying to figure out how to get a home phone functionality in SIP. The home phone has the following functionality 1 When a call comes all phones in the home ring 2 When one picks up, all other line must stop ringing 3 A user can picks up from any other telephone in the home and join an existing call. this a scenario where A calls a Home Phone which has Three connection B, C, D in his home +-------------| A---------------| Proxy |---------------D | | +------------+ / \ / \ / \ / \ B C When a calls to a home phone which has 3 connection (B, C, D) lands on proxy, then proxy forks the INVITE message to B, C, D. so every phone starts ringing. This is the first character of Home Phone. Now Let's say B picks up the phone then Proxy sends CANCEL message to C and D so that the ringing can stop. This fulfills the Second point of Home Phone. I am not able to get the call flow for the Third point in home Phone. If lets say C picks up the phone then he should also be in session with A and B. How can this be done because When a CANCEL message is received by C and D then they both reached the state where they can only expect INVITE. Can any one please tell me how the call flow for the third point in the home phone. The above points of Home phone were taken from the -----Bell Labs Journal (October-December 1998) regards Anirban From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 09:38: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 JAA13111 for ; Thu, 6 Jan 2000 09:38:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2014D52E9; Thu, 6 Jan 2000 09:28:41 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DF05B52E5; Thu, 6 Jan 2000 09:28:39 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 699FD52E1 for ; Wed, 5 Jan 2000 22:59:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jan 5 22:59:02 EST 2000 Received: from rakshaka.wipsys.soft.net ([164.164.68.8]) by dusty; Wed Jan 5 22:57:11 EST 2000 Received: (from fwtk@localhost) by rakshaka.wipsys.soft.net (8.9.1b+Sun/8.9.1) id JAA08668 for ; Thu, 6 Jan 2000 09:30:39 GMT X-Authentication-Warning: rakshaka.wipsys.soft.net: fwtk set sender to using -f Received: from unknown(192.168.172.18) by rakshaka.wipsys.soft.net via smap (V2.0) id xma008651; Thu, 6 Jan 00 09:30:28 GMT Received: from wipsys.soft.net ([192.168.178.175]) by ecmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA1893 for ; Thu, 6 Jan 2000 09:24:39 +0530 Message-ID: <3874123E.5E4F14DD@wipsys.soft.net> Date: Thu, 06 Jan 2000 09:25:43 +0530 From: "ANIRBAN ROY" X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: A case related to "home Phone" type of functionality in SIP 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 hi, I am trying to figure out how to get a home phone functionality in SIP. The home phone has the following functionality 1 When a call comes all phones in the home ring 2 When one picks up, all other line must stop ringing 3 A user can picks up from any other telephone in the home and join an existing call. this a scenario where A calls a Home Phone which has Three connection B, C, D in his home +-------------| A---------------| Proxy |---------------D | | +------------+ / \ / \ / \ / \ B C When a calls to a home phone which has 3 connection (B, C, D) lands on proxy, then proxy forks the INVITE message to B, C, D. so every phone starts ringing. This is the first character of Home Phone. Now Let's say B picks up the phone then Proxy sends CANCEL message to C and D so that the ringing can stop. This fulfills the Second point of Home Phone. I am not able to get the call flow for the Third point in home Phone. If lets say C picks up the phone then he should also be in session with A and B. How can this be done because When a CANCEL message is received by C and D then they both reached the state where they can only expect INVITE. Can any one please tell me how the call flow for the third point in the home phone. The above points of Home phone were taken from the -----Bell Labs Journal (October-December 1998) regards Anirban From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 09:59: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 JAA13698 for ; Thu, 6 Jan 2000 09:59:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7792E52E1; Thu, 6 Jan 2000 09:57:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E75D152E8; Thu, 6 Jan 2000 09:57:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2CB2952E1 for ; Thu, 6 Jan 2000 09:57:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 09:55:58 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 09:54:10 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwvj27970; Thu, 6 Jan 2000 14:55:55 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id JAA06200; Thu, 6 Jan 2000 09:55:53 -0500 (EST) Message-ID: <3874AEBC.6F547BA2@dynamicsoft.com> Date: Thu, 06 Jan 2000 10:03:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ANIRBAN ROY Cc: sip@lists.research.bell-labs.com Subject: Re: not able to understand the call flow for Home Phone implementation References: <387434D6.F22592C0@wipsys.soft.net> 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 You are right in that a SIP UA, as currently specified, won't be able to get home line type of service. It can be done in the way described in this paper, but it requires changes to the behavior of the UA, although no changes to the protocol itself, depending on how its done. It also requires the caller to be "cooperative" - they will receive multiple 200 OK as each extension picks up, and they need to initiate a multi-party conference to do it. Basically, if you use multicast instead of forking, you don't need protocol extensions, just some new behaviors in the UA. If you want to rely on forking rather than multicast, you need somewhat more complex extensions. When using multicast, the UA basically snoops on the multicast group for BYEs and other 200 OKs. This allows it to build a complete picture of what other extensions have picked up, hung up, or been hung up on. Based on this, it can, in a distributed fashion, figure out the state of the call. If there are calls active, a user picking up the phone would cause the phone to send a 200 OK for the call. For forking, snooping of BYEs and other messages is not feasible, so some extensions are needed. However, doing this means you home line extensions could actually be anywhere in the world. Pretty cool. There are other ways to do it which hide from the caller the fact that multiple extensions have picked up. This is more like how the current home phone service works. Are many people interested in this? If there are many folks who would like to see some work on SIP extensions required for home line service, it might be something worthwhile to consider. -Jonathan R. ANIRBAN ROY wrote: > > hi, > I am trying to figure out how to get a home phone functionality in SIP. > The home phone has the following functionality > 1 When a call comes all phones in the home ring > 2 When one picks up, all other line must stop ringing > 3 A user can picks up from any other telephone in the home and join > an existing call. > > A scenario is there where A calls a Home > Phone which has Three connection B, C, D in his home > > When a calls to a home phone which has 3 connection (B, C, D) lands on > proxy, then proxy forks the INVITE message to B, C, D. so every phone > starts ringing. This is the first character of Home Phone. Now Let's say > > B picks up the phone then Proxy sends CANCEL message to C and D so that > the ringing can stop. This fulfills the Second point of Home Phone. > > I am not able to get the call flow for the Third point in home Phone. If > > lets say C picks up the phone (when both A and C in conversation)then he > should also be in session with A > and B. How can this be done because When a CANCEL message is received by > > C and D then they both reached the state where they can only expect > INVITE. > > Can any one please tell me how the call flow for the third point in the > home phone. > > The above points of Home phone were taken from the -----Bell Labs > Journal (October-December 1998) > > regards > Anirban -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 10:25:57 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 KAA14353 for ; Thu, 6 Jan 2000 10:25:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D235F52E8; Thu, 6 Jan 2000 10:23:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4DADC52EA; Thu, 6 Jan 2000 10:23:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1D56852E8 for ; Thu, 6 Jan 2000 10:23:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 10:21:45 EST 2000 Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Thu Jan 6 10:19:56 EST 2000 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 KAA07245; Thu, 6 Jan 2000 10:21:40 -0500 (EST) 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 KAA19822; Thu, 6 Jan 2000 10:21:42 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 10:19:12 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF0685FC@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: not able to understand the call flow for Home Phone implement ation Date: Thu, 6 Jan 2000 10:21:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > Are many people interested in this? If there are many folks who would > like to see some work on SIP extensions required for home > line service, > it might be something worthwhile to consider. > Count me in. It has applications beyond home. Brian From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 10:48:11 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 KAA14756 for ; Thu, 6 Jan 2000 10:48:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E33C552EA; Thu, 6 Jan 2000 10:45:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5EFF252EB; Thu, 6 Jan 2000 10:45:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 20B3D52EA for ; Thu, 6 Jan 2000 10:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 10:43:06 EST 2000 Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Thu Jan 6 10:41:17 EST 2000 Received: from rtbell-isdn4 (dhcp-dp2-158-221.cisco.com [171.71.158.221]) by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA09027; Thu, 6 Jan 2000 09:42:45 -0600 (CST) Message-Id: <4.2.0.58.20000106083934.00b1c100@orinoco.cisco.com> X-Sender: rtbell@orinoco.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jan 2000 08:42:38 -0700 To: "Adam B. Roach" , jdrosen@dynamicsoft.com (Jonathan Rosenberg) From: Bob Bell Subject: Re: Prioritization limitation question Cc: Adam.Roach@ericsson.com (Adam B. Roach), brosen@fore.com (Rosen Brian), sip@lists.research.bell-labs.com In-Reply-To: <200001052350.RAA20068@b04a24.exu.ericsson.se> References: <3873CF03.AEE128B9@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Gentlemen - There is another aspect of MLPP which is being ignored here. That is that I don't want to talk to you, I just need the bandwidth your communications is consuming over a WAN link of limited bandwidth. So, I (or a proxy which has a better network view that I do) needs to tell you that you must terminate the call. Thus, there is no opportunity for me to present an INVITE to you and for you to return a Busy indication. Bob At 04:50 PM 1/5/00, Adam B. Roach wrote: >Jonathan Rosenberg writes: > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > >I'd rather use the more generic Supported/Require mechanism (a draft on > >this is pending within the next few days). So, > > > >C->S INVITE > > > >S->C 421 Feature Available > >Require: com.cisco.mlpp > > > >C->S INVITE > >Supported: com.cisco.mlpp > >MLPP: 2;version=1 > > > >S->C 200 OK > >It sounds like you're adding yet another round trip: >the first to agree on the feature, the second to try >an invite (which gets a "busy" response), and the third >to invoke the feature (am I misreading something here?) > >Keep in mind that MLPP is relevant only when the far side >returns an indication like "busy." Only *after* the calling >party is notified that the far side is busy does he make a >decision that he wants to break in on the call. > >Also, in PSTN interoperation scenarios, the gateway won't >know that you can break in on the called party until the busy >indication arrives (since we're just pumping the call back >into the network and don't necessarily know the capability >of the end office to which the subscriber is physically >connected) -- so negotiation of the feature cannot occur before >an attempt is made to reach the called party. > >If we're going to go out of our way to borrow a service from >ISUP, we'd be exceedingly foolish not to make them able to >interoperate. > >-- >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 > Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 10:51:59 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 KAA14857 for ; Thu, 6 Jan 2000 10:51:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E8C8A52EC; Thu, 6 Jan 2000 10:47:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6974852EB; Thu, 6 Jan 2000 10:47:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3D7D152EB for ; Thu, 6 Jan 2000 10:47:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 10:45:46 EST 2000 Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Thu Jan 6 10:43:58 EST 2000 Received: from rtbell-isdn4 (dhcp-dp2-158-221.cisco.com [171.71.158.221]) by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA09118; Thu, 6 Jan 2000 09:45:35 -0600 (CST) Message-Id: <4.2.0.58.20000106084455.00b55590@orinoco.cisco.com> X-Sender: rtbell@orinoco.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jan 2000 08:45:29 -0700 To: "Rosen, Brian" , "'Jonathan Rosenberg'" From: Bob Bell Subject: RE: not able to understand the call flow for Home Phone implement ation Cc: "'sip@lists.research.bell-labs.com'" In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685FC@whq-msgusr-02.fore. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I also would have a personal interest in this activity. So count me in also. Bob Bell At 08:21 AM 1/6/00, Rosen, Brian wrote: > > > Are many people interested in this? If there are many folks who would > > like to see some work on SIP extensions required for home > > line service, > > it might be something worthwhile to consider. > > > >Count me in. It has applications beyond home. > >Brian > Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 11:14:00 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 LAA15252 for ; Thu, 6 Jan 2000 11:13:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BEAEB52E4; Thu, 6 Jan 2000 11:11:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 35E6352ED; Thu, 6 Jan 2000 11:11:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CF47B52E4 for ; Thu, 6 Jan 2000 11:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 11:10:16 EST 2000 Received: from mgw-x2.nokia.com ([131.228.20.22]) by dusty; Thu Jan 6 11:08:28 EST 2000 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 SAA29840 for ; Thu, 6 Jan 2000 18:10:14 +0200 (EET) From: petri.saarela@nokia.com Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA18461 for ; Thu, 6 Jan 2000 18:10:13 +0200 (EET) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Thu, 6 Jan 2000 18:10:13 +0200 Message-ID: <2DB2AC537FE6D2119E630008C77327130153C1B3@bueis01nok> To: sip@lists.research.bell-labs.com Subject: SIP literature Date: Thu, 6 Jan 2000 18:10:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi all! Can anyone name a good book concerning SIP? Petri Saarela From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 12:02:08 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 MAA16520 for ; Thu, 6 Jan 2000 12:02:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C317452EB; Thu, 6 Jan 2000 11:59:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 33C5C52EE; Thu, 6 Jan 2000 11:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F192852EB for ; Thu, 6 Jan 2000 11:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 11:57:39 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 11:55:51 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwvr04349; Thu, 6 Jan 2000 16:57:37 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id LAA06356; Thu, 6 Jan 2000 11:57:37 -0500 (EST) Message-ID: <3874CB44.7F450229@dynamicsoft.com> Date: Thu, 06 Jan 2000 12:05:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: petri.saarela@nokia.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP literature References: <2DB2AC537FE6D2119E630008C77327130153C1B3@bueis01nok> 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 There are no books (yet ;) ) that I know of. However, there is a wealth of papers, tutorials, and slides at the SIP homepage: http://www.cs.columbia.edu/~hgs/sip/papers.html -Jonathan R. petri.saarela@nokia.com wrote: > > Hi all! > > Can anyone name a good book concerning SIP? > > Petri Saarela -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 12:08:17 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 MAA16699 for ; Thu, 6 Jan 2000 12:08:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 117A152EE; Thu, 6 Jan 2000 12:05:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7883852EF; Thu, 6 Jan 2000 12:05:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C1C7B52EE for ; Thu, 6 Jan 2000 12:05:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 12:03:49 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 12:02:00 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwvs21625; Thu, 6 Jan 2000 17:03:46 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id MAA06362; Thu, 6 Jan 2000 12:03:46 -0500 (EST) Message-ID: <3874CCB5.7E99A5CD@dynamicsoft.com> Date: Thu, 06 Jan 2000 12:11:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Bell Cc: "Adam B. Roach" , Rosen Brian , sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question References: <3873CF03.AEE128B9@dynamicsoft.com> <4.2.0.58.20000106083934.00b1c100@orinoco.cisco.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 This is a much different service. As the SIP path and media path are different (and, in fact, may flow through completely different service providers), there is really no way for this to be handled at the SIP layer. A proxy can't know to tear down someone elses call if bandwidth were available. Even the UA probably can't know that his call is consuming bandwidth that is preventing some other call from being made. Rather, if the *service* we need is that some generals call gets enough bandwidth, overriding some private, this is best handled by some kind of diffserv or rsvp operation. -Jonathan R. Bob Bell wrote: > > Gentlemen - > > There is another aspect of MLPP which is being ignored here. That is that I > don't want to talk to you, I just need the bandwidth your communications is > consuming over a WAN link of limited bandwidth. So, I (or a proxy which has > a better network view that I do) needs to tell you that you must terminate > the call. Thus, there is no opportunity for me to present an INVITE to you > and for you to return a Busy indication. > > Bob > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > >Jonathan Rosenberg writes: > > > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > > >I'd rather use the more generic Supported/Require mechanism (a draft on > > >this is pending within the next few days). So, > > > > > >C->S INVITE > > > > > >S->C 421 Feature Available > > >Require: com.cisco.mlpp > > > > > >C->S INVITE > > >Supported: com.cisco.mlpp > > >MLPP: 2;version=1 > > > > > >S->C 200 OK > > > >It sounds like you're adding yet another round trip: > >the first to agree on the feature, the second to try > >an invite (which gets a "busy" response), and the third > >to invoke the feature (am I misreading something here?) > > > >Keep in mind that MLPP is relevant only when the far side > >returns an indication like "busy." Only *after* the calling > >party is notified that the far side is busy does he make a > >decision that he wants to break in on the call. > > > >Also, in PSTN interoperation scenarios, the gateway won't > >know that you can break in on the called party until the busy > >indication arrives (since we're just pumping the call back > >into the network and don't necessarily know the capability > >of the end office to which the subscriber is physically > >connected) -- so negotiation of the feature cannot occur before > >an attempt is made to reach the called party. > > > >If we're going to go out of our way to borrow a service from > >ISUP, we'd be exceedingly foolish not to make them able to > >interoperate. > > > >-- > >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 > > > > Bob Bell > Cisco Systems Inc. > 801-294-3034(v) > 801-294-3023(f) -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 12:15:47 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 MAA16952 for ; Thu, 6 Jan 2000 12:15:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0920352EF; Thu, 6 Jan 2000 12:13:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7D62B52F0; Thu, 6 Jan 2000 12:13:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 17F2052EF for ; Thu, 6 Jan 2000 12:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 12:11:27 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 12:09:39 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwvs13471; Thu, 6 Jan 2000 17:11:23 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id MAA06370; Thu, 6 Jan 2000 12:11:21 -0500 (EST) Message-ID: <3874CE7C.DA84D2FF@dynamicsoft.com> Date: Thu, 06 Jan 2000 12:18:52 -0500 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: Rosen Brian , sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question References: <200001052350.RAA20068@b04a24.exu.ericsson.se> 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 "Adam B. Roach" wrote: > > >C->S INVITE > > > >S->C 421 Feature Available > >Require: com.cisco.mlpp > > > >C->S INVITE > >Supported: com.cisco.mlpp > >MLPP: 2;version=1 > > > >S->C 200 OK > > It sounds like you're adding yet another round trip: > the first to agree on the feature, the second to try > an invite (which gets a "busy" response), and the third > to invoke the feature (am I misreading something here?) I wasn't suggesting that. I was suggesting that if the far side is busy, and has this CCBS thing, it returns a 421 feature available with this Require header. Anyway, based on Bob's mail, it may not matter. -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 13:21:49 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 NAA18874 for ; Thu, 6 Jan 2000 13:21:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C896152ED; Thu, 6 Jan 2000 13:19:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4160C52F1; Thu, 6 Jan 2000 13:19:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6C5D452ED for ; Thu, 6 Jan 2000 13:19:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 13:18:06 EST 2000 Received: from ids2.idsonline.com ([205.177.236.32]) by dusty; Thu Jan 6 13:16:18 EST 2000 Received: from 21rst-century.com (laurel-md-216.idsonline.com [209.8.42.216]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id NAA10143; Thu, 6 Jan 2000 13:19:09 -0500 Message-ID: <3874DCDE.19588319@21rst-century.com> Date: Thu, 06 Jan 2000 13:20:21 -0500 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies LLC X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: petri.saarela@nokia.com, sip@lists.research.bell-labs.com Subject: Re: SIP literature References: <2DB2AC537FE6D2119E630008C77327130153C1B3@bueis01nok> <3874CB44.7F450229@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello SIP-er's; IP Telephony, by Hersent, Gurle & Petit, has a Chapter (# 2) on SIP, which seems fairly good (although I haven't read that far yet)! It is out, as I have one in front of me, purchased last week from Borders for $49.95. Published by Addison-Wesley, 2000. Regards Marshall Eubanks T.M. Eubanks CTO Multicast Technologies, LLC P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com Jonathan Rosenberg wrote: > There are no books (yet ;) ) that I know of. However, there is a wealth > of papers, tutorials, and slides at the SIP homepage: > > http://www.cs.columbia.edu/~hgs/sip/papers.html > > -Jonathan R. > > petri.saarela@nokia.com wrote: > > > > Hi all! > > > > Can anyone name a good book concerning SIP? > > > > Petri Saarela > > -- > 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 14:18:06 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 OAA20215 for ; Thu, 6 Jan 2000 14:18:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 536F452F0; Thu, 6 Jan 2000 14:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ACD8752F2; Thu, 6 Jan 2000 14:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E457952F0 for ; Thu, 6 Jan 2000 14:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 14:14:18 EST 2000 Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Thu Jan 6 14:12:27 EST 2000 Received: from rtbell-isdn4 (dhcp-dp2-158-221.cisco.com [171.71.158.221]) by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA15255; Thu, 6 Jan 2000 13:13:51 -0600 (CST) Message-Id: <4.2.0.58.20000106121019.00ae37d0@orinoco.cisco.com> X-Sender: rtbell@orinoco.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jan 2000 12:13:41 -0700 To: Jonathan Rosenberg From: Bob Bell Subject: Re: Prioritization limitation question Cc: "Adam B. Roach" , Rosen Brian , sip@lists.research.bell-labs.com In-Reply-To: <3874CCB5.7E99A5CD@dynamicsoft.com> References: <3873CF03.AEE128B9@dynamicsoft.com> <4.2.0.58.20000106083934.00b1c100@orinoco.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Jonathan - I understand that this is a different aspect of the problem. It does bear on SIP in that if a lower priority call is "preempted", there is supposed to be a signal given to the end stations indicating that they have been or are being preempted. That signal would need to be SIP. How and where it is originated is a totally different issue and one I don't currently know how to solve. There would need to be some form of feedback from RSVP or DIFFSERV or ???? to allow for that interaction. Bob Bell At 10:11 AM 1/6/00, Jonathan Rosenberg wrote: >This is a much different service. As the SIP path and media path are >different (and, in fact, may flow through completely different service >providers), there is really no way for this to be handled at the SIP >layer. A proxy can't know to tear down someone elses call if bandwidth >were available. Even the UA probably can't know that his call is >consuming bandwidth that is preventing some other call from being made. > >Rather, if the *service* we need is that some generals call gets enough >bandwidth, overriding some private, this is best handled by some kind of >diffserv or rsvp operation. > > >-Jonathan R. > >Bob Bell wrote: > > > > Gentlemen - > > > > There is another aspect of MLPP which is being ignored here. That is that I > > don't want to talk to you, I just need the bandwidth your communications is > > consuming over a WAN link of limited bandwidth. So, I (or a proxy which has > > a better network view that I do) needs to tell you that you must terminate > > the call. Thus, there is no opportunity for me to present an INVITE to you > > and for you to return a Busy indication. > > > > Bob > > > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > > > >Jonathan Rosenberg writes: > > > > > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > > > >I'd rather use the more generic Supported/Require mechanism (a draft on > > > >this is pending within the next few days). So, > > > > > > > >C->S INVITE > > > > > > > >S->C 421 Feature Available > > > >Require: com.cisco.mlpp > > > > > > > >C->S INVITE > > > >Supported: com.cisco.mlpp > > > >MLPP: 2;version=1 > > > > > > > >S->C 200 OK > > > > > >It sounds like you're adding yet another round trip: > > >the first to agree on the feature, the second to try > > >an invite (which gets a "busy" response), and the third > > >to invoke the feature (am I misreading something here?) > > > > > >Keep in mind that MLPP is relevant only when the far side > > >returns an indication like "busy." Only *after* the calling > > >party is notified that the far side is busy does he make a > > >decision that he wants to break in on the call. > > > > > >Also, in PSTN interoperation scenarios, the gateway won't > > >know that you can break in on the called party until the busy > > >indication arrives (since we're just pumping the call back > > >into the network and don't necessarily know the capability > > >of the end office to which the subscriber is physically > > >connected) -- so negotiation of the feature cannot occur before > > >an attempt is made to reach the called party. > > > > > >If we're going to go out of our way to borrow a service from > > >ISUP, we'd be exceedingly foolish not to make them able to > > >interoperate. > > > > > >-- > > >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 > > > > > > > Bob Bell > > Cisco Systems Inc. > > 801-294-3034(v) > > 801-294-3023(f) > >-- >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 Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 14:22:06 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 OAA20377 for ; Thu, 6 Jan 2000 14:22:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DB70152F2; Thu, 6 Jan 2000 14:18:02 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 12B9252F5; Thu, 6 Jan 2000 14:18:00 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 83AA352F2 for ; Thu, 6 Jan 2000 14:17:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 14:15:41 EST 2000 Received: from alpha.mcit.com ([199.249.19.243]) by dusty; Thu Jan 6 14:13:51 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416) id <0FNX00301HBTBA@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 19:11:53 +0000 (GMT) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FNX0011PHBTTX@firewall.mcit.com>; Thu, 06 Jan 2000 19:11:53 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA14456; Thu, 06 Jan 2000 19:12:03 +0000 (GMT) Received: from C25766A ([166.37.184.158]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000106191201.YNSA16210@C25766A>; Thu, 06 Jan 2000 19:12:02 +0000 Date: Thu, 06 Jan 2000 13:11:49 -0600 From: Henry Sinnreich Subject: RE: not able to understand the call flow for Home Phone implementation In-reply-to: <4FBEA8857476D311A03300204840E1CF0685FC@whq-msgusr-02.fore.com> To: "Rosen, Brian" , "'Jonathan Rosenberg'" Cc: sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >It has applications beyond home. Agree. Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Rosen, Brian Sent: Thursday, January 06, 2000 9:22 AM To: 'Jonathan Rosenberg' Cc: 'sip@lists.research.bell-labs.com' Subject: RE: not able to understand the call flow for Home Phone implement ation > Are many people interested in this? If there are many folks who would > like to see some work on SIP extensions required for home > line service, > it might be something worthwhile to consider. > Count me in. It has applications beyond home. Brian From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 14:25:22 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 OAA20459 for ; Thu, 6 Jan 2000 14:25:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8571752F6; Thu, 6 Jan 2000 14:18:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6BD2552F4; Thu, 6 Jan 2000 14:18:12 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 42EE752F4 for ; Thu, 6 Jan 2000 14:17:11 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 14:16:20 EST 2000 Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Thu Jan 6 14:14:32 EST 2000 Received: from rtbell-isdn4 (dhcp-dp2-158-221.cisco.com [171.71.158.221]) by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA15325; Thu, 6 Jan 2000 13:15:42 -0600 (CST) Message-Id: <4.2.0.58.20000106121419.00ae8620@orinoco.cisco.com> X-Sender: rtbell@orinoco.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jan 2000 12:15:35 -0700 To: Jonathan Rosenberg , "Adam B. Roach" From: Bob Bell Subject: Re: Prioritization limitation question Cc: Rosen Brian , sip@lists.research.bell-labs.com In-Reply-To: <3874CE7C.DA84D2FF@dynamicsoft.com> References: <200001052350.RAA20068@b04a24.exu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Jonathan - This form, where I need to preempt a call that you have currently active so that I can talk to you is also a valid case. Don't abandon this part just because the other part also exists. Bob At 10:18 AM 1/6/00, Jonathan Rosenberg wrote: >"Adam B. Roach" wrote: > > > > >C->S INVITE > > > > > >S->C 421 Feature Available > > >Require: com.cisco.mlpp > > > > > >C->S INVITE > > >Supported: com.cisco.mlpp > > >MLPP: 2;version=1 > > > > > >S->C 200 OK > > > > It sounds like you're adding yet another round trip: > > the first to agree on the feature, the second to try > > an invite (which gets a "busy" response), and the third > > to invoke the feature (am I misreading something here?) > >I wasn't suggesting that. I was suggesting that if the far side is busy, >and has this CCBS thing, it returns a 421 feature available with this >Require header. > >Anyway, based on Bob's mail, it may not matter. > >-Jonathan R. > >-- >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 > Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 14:28:37 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 OAA20514 for ; Thu, 6 Jan 2000 14:28:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8188852F5; Thu, 6 Jan 2000 14:19:57 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E020452F4; Thu, 6 Jan 2000 14:19:55 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 88ED452F7 for ; Thu, 6 Jan 2000 14:19:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 14:18:55 EST 2000 Received: from bastion1.mail.sprint.com ([208.4.28.129]) by dusty; Thu Jan 6 14:17:07 EST 2000 Received: from sii01.mail.sprint.com by bastion1.mail.sprint.com with ESMTP for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 13:18:53 -0600 Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Thu, 6 Jan 2000 13:18:43 -0600 Received: from saopmp01.corp.sprint.com (saopmp01m [10.162.0.24]) by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id NAA02338; Thu, 6 Jan 2000 13:18:42 -0600 (CST) From: michael dwyer Received: from localhost (root@localhost) by saopmp01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA19568; Thu, 6 Jan 2000 11:18:41 -0800 (PST) X-OpenMail-Hops: 1 Date: Thu, 6 Jan 2000 11:18:41 -0800 Message-Id: Subject: RE: not able to understand the call flow for Home Phone implementation To: jdrosen@dynamicsoft.com Cc: sip@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="openmail-part-0fe51ed0-00000001" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --openmail-part-0fe51ed0-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" Content-Transfer-Encoding: 7bit Yes I'm definitely interested. Again beyond the home applications Mike -----Original Message----- From: brosen [mailto:brosen@fore.com] Sent: Thursday, January 06, 2000 7:22 AM To: jdrosen Cc: brosen; sip Subject: RE: not able to understand the call flow for Home Phone implementation > Are many people interested in this? If there are many folks who would > like to see some work on SIP extensions required for home > line service, > it might be something worthwhile to consider. > Count me in. It has applications beyond home. Brian --openmail-part-0fe51ed0-00000001-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 16:16:26 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 QAA22483 for ; Thu, 6 Jan 2000 16:16:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3AC0052F1; Thu, 6 Jan 2000 16:13:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9AD3552F3; Thu, 6 Jan 2000 16:13:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7DBB952F1 for ; Thu, 6 Jan 2000 16:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 16:11:15 EST 2000 Received: from beta.mcit.com ([199.249.19.244]) by dusty; Thu Jan 6 16:09:25 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38417) id <0FNX00E01MUB53@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 21:11:00 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #38417) with ESMTP id <0FNX00GBNMUBWY@firewall.mcit.com>; Thu, 06 Jan 2000 21:10:59 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id VAA17823; Thu, 06 Jan 2000 21:09:17 +0000 (GMT) Received: from C25766A ([166.37.184.158]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000106211107.ZOOB16210@C25766A>; Thu, 06 Jan 2000 21:11:07 +0000 Date: Thu, 06 Jan 2000 15:10:52 -0600 From: Henry Sinnreich Subject: RE: Prioritization limitation question In-reply-to: <4.2.0.58.20000106121019.00ae37d0@orinoco.cisco.com> To: Bob Bell , Jonathan Rosenberg Cc: "Adam B. Roach" , Rosen Brian , sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Bob, I will give it a try. A QoS enabled SIP client, like a SIP phone would actually have an RSVP client as well. If bandwidth is preempted during a QoS assured call, it is up to the client to react and advise the user with a notice "Lost QoS for this call" and give the user the choice to continue the call with best effort service or to hang up. Since QoS assured calls will probably command some premium rates, the knowledgeable user may not be completely unhappy not to be charged for QoS minutes any more. It will also allow for a more graceful termination of the call by the user himself/herself instead of being just cut off in the middle of a conversation. Or do I understand the problem right? Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Bob Bell Sent: Thursday, January 06, 2000 1:14 PM To: Jonathan Rosenberg Cc: Adam B. Roach; Rosen Brian; sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question Jonathan - I understand that this is a different aspect of the problem. It does bear on SIP in that if a lower priority call is "preempted", there is supposed to be a signal given to the end stations indicating that they have been or are being preempted. That signal would need to be SIP. How and where it is originated is a totally different issue and one I don't currently know how to solve. There would need to be some form of feedback from RSVP or DIFFSERV or ???? to allow for that interaction. Bob Bell At 10:11 AM 1/6/00, Jonathan Rosenberg wrote: >This is a much different service. As the SIP path and media path are >different (and, in fact, may flow through completely different service >providers), there is really no way for this to be handled at the SIP >layer. A proxy can't know to tear down someone elses call if bandwidth >were available. Even the UA probably can't know that his call is >consuming bandwidth that is preventing some other call from being made. > >Rather, if the *service* we need is that some generals call gets enough >bandwidth, overriding some private, this is best handled by some kind of >diffserv or rsvp operation. > > >-Jonathan R. > >Bob Bell wrote: > > > > Gentlemen - > > > > There is another aspect of MLPP which is being ignored here. That is that I > > don't want to talk to you, I just need the bandwidth your communications is > > consuming over a WAN link of limited bandwidth. So, I (or a proxy which has > > a better network view that I do) needs to tell you that you must terminate > > the call. Thus, there is no opportunity for me to present an INVITE to you > > and for you to return a Busy indication. > > > > Bob > > > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > > > >Jonathan Rosenberg writes: > > > > > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > > > >I'd rather use the more generic Supported/Require mechanism (a draft on > > > >this is pending within the next few days). So, > > > > > > > >C->S INVITE > > > > > > > >S->C 421 Feature Available > > > >Require: com.cisco.mlpp > > > > > > > >C->S INVITE > > > >Supported: com.cisco.mlpp > > > >MLPP: 2;version=1 > > > > > > > >S->C 200 OK > > > > > >It sounds like you're adding yet another round trip: > > >the first to agree on the feature, the second to try > > >an invite (which gets a "busy" response), and the third > > >to invoke the feature (am I misreading something here?) > > > > > >Keep in mind that MLPP is relevant only when the far side > > >returns an indication like "busy." Only *after* the calling > > >party is notified that the far side is busy does he make a > > >decision that he wants to break in on the call. > > > > > >Also, in PSTN interoperation scenarios, the gateway won't > > >know that you can break in on the called party until the busy > > >indication arrives (since we're just pumping the call back > > >into the network and don't necessarily know the capability > > >of the end office to which the subscriber is physically > > >connected) -- so negotiation of the feature cannot occur before > > >an attempt is made to reach the called party. > > > > > >If we're going to go out of our way to borrow a service from > > >ISUP, we'd be exceedingly foolish not to make them able to > > >interoperate. > > > > > >-- > > >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 > > > > > > > Bob Bell > > Cisco Systems Inc. > > 801-294-3034(v) > > 801-294-3023(f) > >-- >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 Bob Bell Cisco Systems Inc. 801-294-3034(v) 801-294-3023(f) From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 16:26:07 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 QAA22586 for ; Thu, 6 Jan 2000 16:26:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7E8E852F3; Thu, 6 Jan 2000 16:23:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E03F652F4; Thu, 6 Jan 2000 16:23:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 331BF52F3 for ; Thu, 6 Jan 2000 16:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 16:22:54 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 16:21:06 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwwj20191; Thu, 6 Jan 2000 21:22:51 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id QAA09401; Thu, 6 Jan 2000 16:22:49 -0500 (EST) Message-ID: <3875096A.163E5DE6@dynamicsoft.com> Date: Thu, 06 Jan 2000 16:30:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Bell Cc: "Adam B. Roach" , Rosen Brian , sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question References: <3873CF03.AEE128B9@dynamicsoft.com> <4.2.0.58.20000106083934.00b1c100@orinoco.cisco.com> <4.2.0.58.20000106121019.00ae37d0@orinoco.cisco.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 The first problem is that there is no way I know of in RSVP for one reservation to preempt another, and for notification of preemption to be delivered (there has been some work on MPLS extensions to RSVP which allow replacement, but I don't know if thats useful for this application). Even if it did, I'm not really sure it matters. This isn't a circuit network; pre-emption does not imply a one to one replacement of one circuit with another. One could add priorities to an rsvp reservation so it always succeeds; all this means is that the loss rate of existing connections is increased if there really wasn't enough bandwidth for the new one. You can rely on human response to that to hang up if it gets really bad. In most cases, I suspect a WAN connection that supports any kind of data traffic at all will have sufficient resources so that these high priority reservations won't impact one drop existing calls. Furthermore, adaptive mechanisms that use FEC or redundanct codecs will allow performance to be probably not bad for loss rates that are quite high. -Jonathan R. Bob Bell wrote: > > Jonathan - > > I understand that this is a different aspect of the problem. It does bear > on SIP in that if a lower priority call is "preempted", there is supposed > to be a signal given to the end stations indicating that they have been or > are being preempted. That signal would need to be SIP. How and where it is > originated is a totally different issue and one I don't currently know how > to solve. There would need to be some form of feedback from RSVP or > DIFFSERV or ???? to allow for that interaction. > > Bob Bell > > At 10:11 AM 1/6/00, Jonathan Rosenberg wrote: > >This is a much different service. As the SIP path and media path are > >different (and, in fact, may flow through completely different service > >providers), there is really no way for this to be handled at the SIP > >layer. A proxy can't know to tear down someone elses call if bandwidth > >were available. Even the UA probably can't know that his call is > >consuming bandwidth that is preventing some other call from being made. > > > >Rather, if the *service* we need is that some generals call gets enough > >bandwidth, overriding some private, this is best handled by some kind of > >diffserv or rsvp operation. > > > > > >-Jonathan R. > > > >Bob Bell wrote: > > > > > > Gentlemen - > > > > > > There is another aspect of MLPP which is being ignored here. That is that I > > > don't want to talk to you, I just need the bandwidth your communications is > > > consuming over a WAN link of limited bandwidth. So, I (or a proxy which has > > > a better network view that I do) needs to tell you that you must terminate > > > the call. Thus, there is no opportunity for me to present an INVITE to you > > > and for you to return a Busy indication. > > > > > > Bob > > > > > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > > > > > >Jonathan Rosenberg writes: > > > > > > > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > > > > >I'd rather use the more generic Supported/Require mechanism (a draft on > > > > >this is pending within the next few days). So, > > > > > > > > > >C->S INVITE > > > > > > > > > >S->C 421 Feature Available > > > > >Require: com.cisco.mlpp > > > > > > > > > >C->S INVITE > > > > >Supported: com.cisco.mlpp > > > > >MLPP: 2;version=1 > > > > > > > > > >S->C 200 OK > > > > > > > >It sounds like you're adding yet another round trip: > > > >the first to agree on the feature, the second to try > > > >an invite (which gets a "busy" response), and the third > > > >to invoke the feature (am I misreading something here?) > > > > > > > >Keep in mind that MLPP is relevant only when the far side > > > >returns an indication like "busy." Only *after* the calling > > > >party is notified that the far side is busy does he make a > > > >decision that he wants to break in on the call. > > > > > > > >Also, in PSTN interoperation scenarios, the gateway won't > > > >know that you can break in on the called party until the busy > > > >indication arrives (since we're just pumping the call back > > > >into the network and don't necessarily know the capability > > > >of the end office to which the subscriber is physically > > > >connected) -- so negotiation of the feature cannot occur before > > > >an attempt is made to reach the called party. > > > > > > > >If we're going to go out of our way to borrow a service from > > > >ISUP, we'd be exceedingly foolish not to make them able to > > > >interoperate. > > > > > > > >-- > > > >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 > > > > > > > > > > Bob Bell > > > Cisco Systems Inc. > > > 801-294-3034(v) > > > 801-294-3023(f) > > > >-- > >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 > > Bob Bell > Cisco Systems Inc. > 801-294-3034(v) > 801-294-3023(f) -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 16:37:56 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 QAA22838 for ; Thu, 6 Jan 2000 16:37:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8582552F7; Thu, 6 Jan 2000 16:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E7A9B52F4; Thu, 6 Jan 2000 16:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0C05652F7 for ; Thu, 6 Jan 2000 16:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 16:34:34 EST 2000 Received: from newdev.harvard.edu ([140.247.60.212]) by dusty; Thu Jan 6 16:32:46 EST 2000 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA01696; Thu, 6 Jan 2000 16:33:55 -0500 (EST) Date: Thu, 6 Jan 2000 16:33:55 -0500 (EST) From: Scott Bradner Message-Id: <200001062133.QAA01696@newdev.harvard.edu> To: jdrosen@dynamicsoft.com, rtbell@cisco.com Subject: Re: Prioritization limitation question Cc: Adam.Roach@ericsson.com, brosen@fore.com, sip@lists.research.bell-labs.com Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > The first problem is that there is no way I know of in RSVP for one > reservation to preempt another, and for notification of preemption to be > delivered at least the 1st part is in COPS Scott From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 17:18:00 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 RAA23340 for ; Thu, 6 Jan 2000 17:17:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3162652E4; Thu, 6 Jan 2000 17:15:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9E3D252E5; Thu, 6 Jan 2000 17:15:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A8BCB52E4 for ; Thu, 6 Jan 2000 17:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 17:13:41 EST 2000 Received: from beta.mcit.com ([199.249.19.244]) by dusty; Thu Jan 6 17:11:52 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38417) id <0FNX00N01PCWAZ@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 22:05:20 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #38417) with ESMTP id <0FNX00JLOPCVJO@firewall.mcit.com>; Thu, 06 Jan 2000 22:05:20 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id WAA26796; Thu, 06 Jan 2000 22:03:32 +0000 (GMT) Received: from C25766A ([166.37.184.158]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000106220522.ERG16210@C25766A>; Thu, 06 Jan 2000 22:05:22 +0000 Date: Thu, 06 Jan 2000 16:05:04 -0600 From: Henry Sinnreich Subject: RE: Prioritization limitation question In-reply-to: <3875096A.163E5DE6@dynamicsoft.com> To: Bob Bell , Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com, Rosen Brian , "Adam B. Roach" 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: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit An access network, such as an ISP or intranet may want to manage their premium rate QoS pool from a policy server talking COPS to the edge router (that enforces the policy) connecting to the IP backbone. If the policy server is smart enough to understand priorities, it can de-install the QoS policy for some unfortunate lower level callers and install precious QoS for the higher priority application, SIP telephony or anything else. Maybe a corporate video announcement from the president, or an emergency. The initial draft for such a model is http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o sp-00.txt though we are planning on an improved version soon. Interested to know if this model for QoS management from a policy server is broken or OK, so your comments are appreciated. If the model holds, than we have an answer to Bob's problem. Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Thursday, January 06, 2000 3:30 PM To: Bob Bell Cc: Adam B. Roach; Rosen Brian; sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question The first problem is that there is no way I know of in RSVP for one reservation to preempt another, and for notification of preemption to be delivered (there has been some work on MPLS extensions to RSVP which allow replacement, but I don't know if thats useful for this application). Even if it did, I'm not really sure it matters. This isn't a circuit network; pre-emption does not imply a one to one replacement of one circuit with another. One could add priorities to an rsvp reservation so it always succeeds; all this means is that the loss rate of existing connections is increased if there really wasn't enough bandwidth for the new one. You can rely on human response to that to hang up if it gets really bad. In most cases, I suspect a WAN connection that supports any kind of data traffic at all will have sufficient resources so that these high priority reservations won't impact one drop existing calls. Furthermore, adaptive mechanisms that use FEC or redundanct codecs will allow performance to be probably not bad for loss rates that are quite high. -Jonathan R. Bob Bell wrote: > > Jonathan - > > I understand that this is a different aspect of the problem. It does bear > on SIP in that if a lower priority call is "preempted", there is supposed > to be a signal given to the end stations indicating that they have been or > are being preempted. That signal would need to be SIP. How and where it is > originated is a totally different issue and one I don't currently know how > to solve. There would need to be some form of feedback from RSVP or > DIFFSERV or ???? to allow for that interaction. > > Bob Bell > > At 10:11 AM 1/6/00, Jonathan Rosenberg wrote: > >This is a much different service. As the SIP path and media path are > >different (and, in fact, may flow through completely different service > >providers), there is really no way for this to be handled at the SIP > >layer. A proxy can't know to tear down someone elses call if bandwidth > >were available. Even the UA probably can't know that his call is > >consuming bandwidth that is preventing some other call from being made. > > > >Rather, if the *service* we need is that some generals call gets enough > >bandwidth, overriding some private, this is best handled by some kind of > >diffserv or rsvp operation. > > > > > >-Jonathan R. > > > >Bob Bell wrote: > > > > > > Gentlemen - > > > > > > There is another aspect of MLPP which is being ignored here. That is that I > > > don't want to talk to you, I just need the bandwidth your communications is > > > consuming over a WAN link of limited bandwidth. So, I (or a proxy which has > > > a better network view that I do) needs to tell you that you must terminate > > > the call. Thus, there is no opportunity for me to present an INVITE to you > > > and for you to return a Busy indication. > > > > > > Bob > > > > > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > > > > > >Jonathan Rosenberg writes: > > > > > > > > >Rather than using this MLPP-Version thing to indicate support for CCBS, > > > > >I'd rather use the more generic Supported/Require mechanism (a draft on > > > > >this is pending within the next few days). So, > > > > > > > > > >C->S INVITE > > > > > > > > > >S->C 421 Feature Available > > > > >Require: com.cisco.mlpp > > > > > > > > > >C->S INVITE > > > > >Supported: com.cisco.mlpp > > > > >MLPP: 2;version=1 > > > > > > > > > >S->C 200 OK > > > > > > > >It sounds like you're adding yet another round trip: > > > >the first to agree on the feature, the second to try > > > >an invite (which gets a "busy" response), and the third > > > >to invoke the feature (am I misreading something here?) > > > > > > > >Keep in mind that MLPP is relevant only when the far side > > > >returns an indication like "busy." Only *after* the calling > > > >party is notified that the far side is busy does he make a > > > >decision that he wants to break in on the call. > > > > > > > >Also, in PSTN interoperation scenarios, the gateway won't > > > >know that you can break in on the called party until the busy > > > >indication arrives (since we're just pumping the call back > > > >into the network and don't necessarily know the capability > > > >of the end office to which the subscriber is physically > > > >connected) -- so negotiation of the feature cannot occur before > > > >an attempt is made to reach the called party. > > > > > > > >If we're going to go out of our way to borrow a service from > > > >ISUP, we'd be exceedingly foolish not to make them able to > > > >interoperate. > > > > > > > >-- > > > >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 > > > > > > > > > > Bob Bell > > > Cisco Systems Inc. > > > 801-294-3034(v) > > > 801-294-3023(f) > > > >-- > >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 > > Bob Bell > Cisco Systems Inc. > 801-294-3034(v) > 801-294-3023(f) -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 17:21:52 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 RAA23392 for ; Thu, 6 Jan 2000 17:21:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8F98852E5; Thu, 6 Jan 2000 17:19:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D4D5652E8; Thu, 6 Jan 2000 17:19:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 86EB152E5 for ; Thu, 6 Jan 2000 17:19:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 17:18:26 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Jan 6 17:16:37 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41714) id <0FNX00E01PVN7L@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 22:16:35 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41714) with ESMTP id <0FNX00D7KPVNFH@firewall.mcit.com>; Thu, 06 Jan 2000 22:16:35 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id WAA01226; Thu, 06 Jan 2000 22:14:53 +0000 (GMT) Received: from C25766A ([166.37.184.158]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000106221644.HCP16210@C25766A>; Thu, 06 Jan 2000 22:16:44 +0000 Date: Thu, 06 Jan 2000 16:16:29 -0600 From: Henry Sinnreich Subject: RE: not able to understand the call flow for Home Phone implementation In-reply-to: <3874AEBC.6F547BA2@dynamicsoft.com> To: Jonathan Rosenberg , ANIRBAN ROY Cc: sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, >Basically, if you use multicast instead of forking, >you don't need protocol extensions, just some new behaviors in the UA. I believe the zeroconf WG http://www.ietf.org/html.charters/zeroconf-charter.html is counting on multicast for home networks for a number of reasons. Multicast may be a valid approach. Henry -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Thursday, January 06, 2000 9:03 AM To: ANIRBAN ROY Cc: sip@lists.research.bell-labs.com Subject: Re: not able to understand the call flow for Home Phone implementation You are right in that a SIP UA, as currently specified, won't be able to get home line type of service. It can be done in the way described in this paper, but it requires changes to the behavior of the UA, although no changes to the protocol itself, depending on how its done. It also requires the caller to be "cooperative" - they will receive multiple 200 OK as each extension picks up, and they need to initiate a multi-party conference to do it. Basically, if you use multicast instead of forking, you don't need protocol extensions, just some new behaviors in the UA. If you want to rely on forking rather than multicast, you need somewhat more complex extensions. When using multicast, the UA basically snoops on the multicast group for BYEs and other 200 OKs. This allows it to build a complete picture of what other extensions have picked up, hung up, or been hung up on. Based on this, it can, in a distributed fashion, figure out the state of the call. If there are calls active, a user picking up the phone would cause the phone to send a 200 OK for the call. For forking, snooping of BYEs and other messages is not feasible, so some extensions are needed. However, doing this means you home line extensions could actually be anywhere in the world. Pretty cool. There are other ways to do it which hide from the caller the fact that multiple extensions have picked up. This is more like how the current home phone service works. Are many people interested in this? If there are many folks who would like to see some work on SIP extensions required for home line service, it might be something worthwhile to consider. -Jonathan R. ANIRBAN ROY wrote: > > hi, > I am trying to figure out how to get a home phone functionality in SIP. > The home phone has the following functionality > 1 When a call comes all phones in the home ring > 2 When one picks up, all other line must stop ringing > 3 A user can picks up from any other telephone in the home and join > an existing call. > > A scenario is there where A calls a Home > Phone which has Three connection B, C, D in his home > > When a calls to a home phone which has 3 connection (B, C, D) lands on > proxy, then proxy forks the INVITE message to B, C, D. so every phone > starts ringing. This is the first character of Home Phone. Now Let's say > > B picks up the phone then Proxy sends CANCEL message to C and D so that > the ringing can stop. This fulfills the Second point of Home Phone. > > I am not able to get the call flow for the Third point in home Phone. If > > lets say C picks up the phone (when both A and C in conversation)then he > should also be in session with A > and B. How can this be done because When a CANCEL message is received by > > C and D then they both reached the state where they can only expect > INVITE. > > Can any one please tell me how the call flow for the third point in the > home phone. > > The above points of Home phone were taken from the -----Bell Labs > Journal (October-December 1998) > > regards > Anirban -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 17:49:45 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 RAA24008 for ; Thu, 6 Jan 2000 17:49:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BBE6552E4; Thu, 6 Jan 2000 17:47:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4458C52E8; Thu, 6 Jan 2000 17:47:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9311252E4 for ; Thu, 6 Jan 2000 17:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 17:45:27 EST 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Thu Jan 6 17:43:39 EST 2000 Received: by crash with Internet Mail Service (5.5.2448.0) id ; Thu, 6 Jan 2000 17:45:25 -0500 Message-ID: From: Linden deCarmo To: "'sip@lists.research.bell-labs.com'" Subject: Gateways and registration Date: Thu, 6 Jan 2000 17:45:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The SIP specification does not require that gateways register with a SIP server. Thus, the server is never notified if the gateway goes offline. By contrast, protocols such as H.323 have a different concept for Registration and a server can detect when a gateway goes down or offline if registration expires. Is there some way to provide equivalent functionality in SIP? If not, is the concept of gateway registration under consideration for a future draft of the spec? Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 17:55:51 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 RAA24215 for ; Thu, 6 Jan 2000 17:55:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 76C0C52B6; Thu, 6 Jan 2000 17:53:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DE8BD52EF; Thu, 6 Jan 2000 17:53:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C02E352B6 for ; Thu, 6 Jan 2000 17:53:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 17:51:50 EST 2000 Received: from alpha.mcit.com ([199.249.19.243]) by dusty; Thu Jan 6 17:50:02 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416) id <0FNX00501Q4YC1@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 6 Jan 2000 22:22:10 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FNX004BEQ4YBC@firewall.mcit.com>; Thu, 06 Jan 2000 22:22:10 +0000 (GMT) Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id WAA05667; Thu, 06 Jan 2000 22:20:27 +0000 (GMT) Received: from dwillispc ([166.35.225.242]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000106222129.SJDJ31786@dwillispc>; Thu, 06 Jan 2000 16:21:29 -0600 Date: Thu, 06 Jan 2000 16:21:22 -0600 From: Dean Willis Subject: RE: A case related to "home Phone" type of functionality in SIP In-reply-to: <3874123E.5E4F14DD@wipsys.soft.net> To: ANIRBAN ROY , sip@lists.research.bell-labs.com Message-id: <000901bf5894$5cdc2a80$88f823a6@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: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit In a business environment, we call this a "single line extension". SIP approaches tend to have the property that each phone is uniquely addressed, whereas in the PSTN each circuit is uniquely addressed. The obvious solution is to combine a parallel search proxy and some UAS behavior. The sequence is: 1) Incoming call reaches parallel proxy. 2) Parallel proxy invites all UASes in extension group. 3) User answers one extension. 4) Parallel proxy cancels unanswered legs. Those phones stop ringing. 5) Answering phone send INVITE to other phones in group, with "NO RING" specified somehow, and long expire timer. Case 1: 2nd party answers at extension phone: 6) First answering phone bridges all call legs Case 2: User hangs up answering phone 6) Answering phone CANCELS open INVITES to other phones in group 7) Answering phone BYES all active call legs Case 3: 3rd party places call to extension phone 6) Extension phone rings, ignoring open INVITE from first answering phone or leaving it "attached" to a line button etc. Another approach is to use a chained INVITE, which has been propsed using INVITE with Also headers, along with a conferencing bridge: The sequence here is: 1) Incoming call reaches extension group proxy 2) Extension group proxy INVITES or extension bridge, with an Also: or whatever header for each phone in extension group 3) Extension bridge INVITES each phone in group 3) User answeres one extension 4) Extension bridge OKs call leg to user 5) Extension bridge OKs call from caller 6) Exenstion bridge CANCELS legs to other phones in group 7) Extension bridge reINVITES other phones in group with a "NO RING" option and long expire timer. . . . with similar tear-down and 2nd call scenarios And there are dozens of other variations on these themes possible. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of ANIRBAN ROY > Sent: Wednesday, January 05, 2000 9:56 PM > To: sip@lists.research.bell-labs.com > Subject: A case related to "home Phone" type of functionality in SIP > > > hi, > I am trying to figure out how to get a home phone functionality in SIP. > The home phone has the following functionality > 1 When a call comes all phones in the home ring > 2 When one picks up, all other line must stop ringing > 3 A user can picks up from any other telephone in the home and join > an existing call. > > > this a scenario where A calls a Home > Phone which has Three connection B, C, D in his home > > > > +-------------| > A---------------| > Proxy |---------------D > > | | > > +------------+ > > / \ > > / \ > > / \ > > / \ > > B C > > > When a calls to a home phone which has 3 connection (B, C, D) lands on > proxy, then proxy forks the INVITE message to B, C, D. so every phone > starts ringing. This is the first character of Home Phone. Now Let's say > B picks up the phone then Proxy sends CANCEL message to C and D so that > the ringing can stop. This fulfills the Second point of Home Phone. > > I am not able to get the call flow for the Third point in home Phone. If > lets say C picks up the phone then he should also be in session with A > and B. How can this be done because When a CANCEL message is received by > C and D then they both reached the state where they can only expect > INVITE. > > > Can any one please tell me how the call flow for the third point in the > home phone. > > The above points of Home phone were taken from the -----Bell Labs > Journal (October-December 1998) > > > > regards > Anirban > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 18:19:59 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 SAA24823 for ; Thu, 6 Jan 2000 18:19:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 636A652EF; Thu, 6 Jan 2000 18:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA77152F0; Thu, 6 Jan 2000 18:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0DAE852EF for ; Thu, 6 Jan 2000 18:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 18:13:53 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Jan 6 18:12:05 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwwq05561; Thu, 6 Jan 2000 23:13:51 GMT Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id SAA09888; Thu, 6 Jan 2000 18:13:50 -0500 (EST) Message-ID: <3875236F.677AE82D@dynamicsoft.com> Date: Thu, 06 Jan 2000 18:21:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: Gateways and registration 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 This function doesn't belong in the realm of SIP, IMHO. Rather, it is within the realm of TRIP, which supports learning of when a gateway goes offline. -Jonathan R. Linden deCarmo wrote: > > The SIP specification does not require that gateways register with a SIP > server. Thus, the server is never notified if the gateway goes offline. By > contrast, protocols such as H.323 have a different concept for Registration > and a server can detect when a gateway goes down or offline if registration > expires. > > Is there some way to provide equivalent functionality in SIP? If not, is > the concept of gateway registration under consideration for a future draft > of the spec? > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 18:48:40 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 SAA25280 for ; Thu, 6 Jan 2000 18:48:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4027452E9; Thu, 6 Jan 2000 18: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 7155252F0; Thu, 6 Jan 2000 18:45:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C200252E9 for ; Thu, 6 Jan 2000 18:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jan 6 18:43:40 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Jan 6 18:41:51 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA25880; Thu, 6 Jan 2000 17:43:36 -0600 (CST) 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 RAA29590; Thu, 6 Jan 2000 17:43:36 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA20666; Thu, 6 Jan 2000 17:43:35 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id RAA02390; Thu, 6 Jan 2000 17:43:34 -0600 (CST) Date: Thu, 6 Jan 2000 17:43:34 -0600 (CST) Message-Id: <200001062343.RAA02390@b04a45.exu.ericsson.se> To: sip@lists.research.bell-labs.com, ldeCarmo@netspeak.com Subject: Re: Gateways and registration X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > The SIP specification does not require that gateways register with a SIP > server. Thus, the server is never notified if the gateway goes offline. By > contrast, protocols such as H.323 have a different concept for Registration > and a server can detect when a gateway goes down or offline if registration > expires. > > Is there some way to provide equivalent functionality in SIP? If not, is > the concept of gateway registration under consideration for a future draft > of the spec? > Although not required by the SIP standard, there is absolutely nothing to keep you from doing this other than the fact that there are better mechanisms. TRIP might be one avenue to consider. > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 ----------------------------------------------------------------- Sean Olson mailto:sean.olson@ericsson.com Ericsson Inc. tel:(972)583-5472 fax:(972)669-0154 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 18:53:46 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 SAA25308 for ; Thu, 6 Jan 2000 18:53:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 71FBF52E8; Thu, 6 Jan 2000 18:51:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D1AD452F2; Thu, 6 Jan 2000 18:51:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1903452E8 for ; Thu, 6 Jan 2000 18:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 18:49:15 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Jan 6 18:47:27 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA26546; Thu, 6 Jan 2000 17:49:14 -0600 (CST) 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 RAA00423; Thu, 6 Jan 2000 17:49:14 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA20888; Thu, 6 Jan 2000 17:49:13 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id RAA02400; Thu, 6 Jan 2000 17:49:13 -0600 (CST) Date: Thu, 6 Jan 2000 17:49:13 -0600 (CST) Message-Id: <200001062349.RAA02400@b04a45.exu.ericsson.se> To: dean.willis@wcom.com Subject: RE: A case related to "home Phone" type of functionality in SIP Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > In a business environment, we call this a "single line extension". > > SIP approaches tend to have the property that each phone is uniquely > addressed, whereas in the PSTN each circuit is uniquely addressed. > > The obvious solution is to combine a parallel search proxy and some UAS > behavior. > > The sequence is: > 1) Incoming call reaches parallel proxy. > 2) Parallel proxy invites all UASes in extension group. > 3) User answers one extension. > 4) Parallel proxy cancels unanswered legs. Those phones stop ringing. > 5) Answering phone send INVITE to other phones in group, with "NO RING" > specified somehow, and long expire timer. > > In a business environment, this is a perfectly acceptable and reasonable solution. For a home environment, multicast/DHCP seems more reasonable because Joe consumer can go to Radio Shack, buy a 3com SIP phone, and plug it into his home IP network and it works with zero (or almost-zero) configuration. Plus, it doesn't require the home user to buy/maintain a parallel proxy. (By multicast, I mean both signalling and media). ----------------------------------------------------------------- Sean Olson mailto:sean.olson@ericsson.com Ericsson Inc. tel:(972)583-5472 fax:(972)669-0154 From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 20:48:47 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 UAA26586 for ; Thu, 6 Jan 2000 20:48:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7A81F52F6; Thu, 6 Jan 2000 20:45:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3A28252F0; Thu, 6 Jan 2000 20:45:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 73F2552F0 for ; Thu, 6 Jan 2000 20:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 20:44:12 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Jan 6 20:42:20 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41713) id <0FNX00G01ZHJI1@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 7 Jan 2000 01:44:07 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FNX00G3TZHJ8W@firewall.mcit.com>; Fri, 07 Jan 2000 01:44:07 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id BAA28296; Fri, 07 Jan 2000 01:42:25 +0000 (GMT) Received: from dwillispc8 ([166.35.227.33]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000107014406.VMGF15369@dwillispc8>; Fri, 07 Jan 2000 01:44:06 +0000 Date: Thu, 06 Jan 2000 19:43:04 -0600 From: Dean Willis Subject: RE: A case related to "home Phone" type of functionality in SIP In-reply-to: <200001062349.RAA02400@b04a45.exu.ericsson.se> To: Sean Olson Cc: sip@lists.research.bell-labs.com Message-id: <000601bf58b0$8a618b00$21e323a6@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: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Are you saying that the first phone would multicast the media streams to the others on the local LAN, or that the INVITES and media would be sent multicast across the ISP network? If the former, it might work. COuld be pretty cool. If the latter, no, it's not going to happen that way. 1) No ISP that I know of will provide a multicast feed, especially for a lowly dialup user. 2) Every SIP phone in the country is going to listen to a universal multicast group, then make application discard decisions on the INVITES that don't apply to it . . . Or, we could statically allocate a multicast address for each home network . . .not. The INVITE will come in UNICAST. 3) Personally, I've never managed to get multicast routing working right over the bizarre equipment that has accumulated at my house. 4) In our own internal network, we often saw join times that took seven or eight minutes to propaget back to the source of a multicast. That's some serious post-dial delay. I'm not sure we even try to route multicast anymore. 5) The firewall issues that occur with cross-domain multicast are mind boggling. Anything coming into my house is by-definition cross-domain. Hey, I love multicast. I spent more than two years building really cool businesses (Real Broadcast Netork, skyMCI, etc.) around it, and I'm here to tell you it just isn't going to happen across an Internet backbone for the average user any time soon. -- Dean > -----Original Message----- > From: Sean Olson [mailto:eussean@exu.ericsson.se] > Sent: Thursday, January 06, 2000 5:49 PM > To: dean.willis@wcom.com > Cc: sip@lists.research.bell-labs.com > Subject: RE: A case related to "home Phone" type of functionality in SIP > > > > > > In a business environment, we call this a "single line extension". > > > > SIP approaches tend to have the property that each phone is uniquely > > addressed, whereas in the PSTN each circuit is uniquely addressed. > > > > The obvious solution is to combine a parallel search proxy and some UAS > > behavior. > > > > The sequence is: > > 1) Incoming call reaches parallel proxy. > > 2) Parallel proxy invites all UASes in extension group. > > 3) User answers one extension. > > 4) Parallel proxy cancels unanswered legs. Those phones stop ringing. > > 5) Answering phone send INVITE to other phones in group, with "NO RING" > > specified somehow, and long expire timer. > > > > > > In a business environment, this is a perfectly acceptable and reasonable > solution. For a home environment, multicast/DHCP seems more reasonable > because Joe consumer can go to Radio Shack, buy a 3com SIP phone, and > plug it into his home IP network and it works with zero (or > almost-zero) configuration. Plus, it doesn't require the home user > to buy/maintain a parallel proxy. > > (By multicast, I mean both signalling and media). > > ----------------------------------------------------------------- > Sean Olson mailto:sean.olson@ericsson.com > Ericsson Inc. tel:(972)583-5472 > fax:(972)669-0154 > From owner-sip-outgoing@lists.research.bell-labs.com Thu Jan 6 22:37:54 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 WAA29083 for ; Thu, 6 Jan 2000 22:37:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6D85852B6; Thu, 6 Jan 2000 22:35:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E471952F0; Thu, 6 Jan 2000 22:35:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1B87C52B6 for ; Thu, 6 Jan 2000 22:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jan 6 22:33:45 EST 2000 Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Thu Jan 6 22:31:54 EST 2000 Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id WAA10232; Thu, 6 Jan 2000 22:31:34 -0500 Message-ID: <38755EE8.32B53309@pingtel.com> Date: Thu, 06 Jan 2000 22:35:04 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: ANIRBAN ROY , sip@lists.research.bell-labs.com Subject: Re: not able to understand the call flow for Home Phone implementation References: <387434D6.F22592C0@wipsys.soft.net> <3874AEBC.6F547BA2@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 This is not far from, if at all different than, what some call "multiple station appearances". This is a feature for which I would like to see a a standard solution. We proposed this to the TIA as a recommended feature for SIP IP phones. Jonathan Rosenberg wrote: > Are many people interested in this? If there are many folks who would > like to see some work on SIP extensions required for home line service, > it might be something worthwhile to consider. From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 01:00:01 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 BAA00383 for ; Fri, 7 Jan 2000 01:00:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AB9B252F4; Fri, 7 Jan 2000 00:57:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2471B52F5; Fri, 7 Jan 2000 00:57:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4B13C52F4 for ; Fri, 7 Jan 2000 00:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 00:55:57 EST 2000 Received: from ahltorp.nada.kth.se ([130.237.225.236]) by dusty; Fri Jan 7 00:54:05 EST 2000 Received: (from ahltorp@localhost) by ahltorp.nada.kth.se (8.8.8+Sun/8.8.7) id GAA11527; Fri, 7 Jan 2000 06:55:29 +0100 (MET) To: "ANIRBAN ROY" Cc: sip@lists.research.bell-labs.com Subject: Re: A case related to "home Phone" type of functionality in SIP References: <3874123E.5E4F14DD@wipsys.soft.net> From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 07 Jan 2000 06:55:29 +0100 In-Reply-To: "ANIRBAN ROY"'s message of "Thu, 06 Jan 2000 09:25:43 +0530" Message-ID: Lines: 16 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) Emacs/20.4 MIME-Version: 1.0 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > The home phone has the following functionality > 1 When a call comes all phones in the home ring > 2 When one picks up, all other line must stop ringing > 3 A user can picks up from any other telephone in the home and join > an existing call. The third point is not always a feature of a home phone system. For example, in Sweden, the default is a priority system, where the phones are connected in serial, and only one phone at a time can be in use. This is supposed to make it harder for people to listen in to other people's calls. I would rather want a dial tone in my ear when I lift the phone in point three, for convenience and privacy. /Magnus From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 05:06:02 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 FAA13610 for ; Fri, 7 Jan 2000 05:06:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1904C52F4; Fri, 7 Jan 2000 05:03:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7872352F5; Fri, 7 Jan 2000 05:03:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D532552F4 for ; Fri, 7 Jan 2000 05:03:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 05:01:50 EST 2000 Received: from rakshaka.wipsys.soft.net ([164.164.68.8]) by dusty; Fri Jan 7 04:59:57 EST 2000 Received: (from fwtk@localhost) by rakshaka.wipsys.soft.net (8.9.1b+Sun/8.9.1) id PAA29045 for ; Fri, 7 Jan 2000 15:33:50 GMT X-Authentication-Warning: rakshaka.wipsys.soft.net: fwtk set sender to using -f Received: from unknown(192.168.172.18) by rakshaka.wipsys.soft.net via smap (V2.0) id xma029033; Fri, 7 Jan 00 15:33:30 GMT Received: from wipsys.soft.net ([192.168.178.175]) by ecmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA476F; Fri, 7 Jan 2000 15:27:43 +0530 Message-ID: <3875B8AA.B7814A40@wipsys.soft.net> Date: Fri, 07 Jan 2000 15:28:02 +0530 From: "ANIRBAN ROY" X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Sean Olson , sip@lists.research.bell-labs.com Subject: Re: A case related to "home Phone" type of functionality in SIP References: <000601bf58b0$8a618b00$21e323a6@mcit.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 hi , lets say in a house there are 3 phones B, C, D. now User "A" calls to this house Please tell me one question When a call is going on between two user A and B and the third person "C" picks up the phone from the same house what happens then????. # does a 200 Response goes back to the caller. Or the 200 Response just append the Multicast Address with address "C". # RTP data goes directly from caller to callee. When there are more than one user is in conversation how Proxy makes it sure that the RTP data will be send to particular multicast address. As because Proxy only work in the signalling layer. Please reply Anirban Dean Willis wrote: > Are you saying that the first phone would multicast the media streams to the > others on the local LAN, or that the INVITES and media would be sent > multicast across the ISP network? > > If the former, it might work. COuld be pretty cool. > > If the latter, no, it's not going to happen that way. > > 1) No ISP that I know of will provide a multicast feed, especially for a > lowly dialup user. > > 2) Every SIP phone in the country is going to listen to a universal > multicast group, then make application discard decisions on the INVITES that > don't apply to it . . . Or, we could statically allocate a multicast > address for each home network . . .not. The INVITE will come in UNICAST. > > 3) Personally, I've never managed to get multicast routing working right > over the bizarre equipment that has accumulated at my house. > > 4) In our own internal network, we often saw join times that took seven or > eight minutes to propaget back to the source of a multicast. That's some > serious post-dial delay. I'm not sure we even try to route multicast > anymore. > > 5) The firewall issues that occur with cross-domain multicast are mind > boggling. Anything coming into my house is by-definition cross-domain. > > Hey, I love multicast. I spent more than two years building really cool > businesses (Real Broadcast Netork, skyMCI, etc.) around it, and I'm here to > tell you it just isn't going to happen across an Internet backbone for the > average user any time soon. > > -- > Dean > > > -----Original Message----- > > From: Sean Olson [mailto:eussean@exu.ericsson.se] > > Sent: Thursday, January 06, 2000 5:49 PM > > To: dean.willis@wcom.com > > Cc: sip@lists.research.bell-labs.com > > Subject: RE: A case related to "home Phone" type of functionality in SIP > > > > > > > > > > In a business environment, we call this a "single line extension". > > > > > > SIP approaches tend to have the property that each phone is uniquely > > > addressed, whereas in the PSTN each circuit is uniquely addressed. > > > > > > The obvious solution is to combine a parallel search proxy and some UAS > > > behavior. > > > > > > The sequence is: > > > 1) Incoming call reaches parallel proxy. > > > 2) Parallel proxy invites all UASes in extension group. > > > 3) User answers one extension. > > > 4) Parallel proxy cancels unanswered legs. Those phones stop ringing. > > > 5) Answering phone send INVITE to other phones in group, with "NO RING" > > > specified somehow, and long expire timer. > > > > > > > > > > In a business environment, this is a perfectly acceptable and reasonable > > solution. For a home environment, multicast/DHCP seems more reasonable > > because Joe consumer can go to Radio Shack, buy a 3com SIP phone, and > > plug it into his home IP network and it works with zero (or > > almost-zero) configuration. Plus, it doesn't require the home user > > to buy/maintain a parallel proxy. > > > > (By multicast, I mean both signalling and media). > > > > ----------------------------------------------------------------- > > Sean Olson mailto:sean.olson@ericsson.com > > Ericsson Inc. tel:(972)583-5472 > > fax:(972)669-0154 > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 07:17:55 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 HAA14919 for ; Fri, 7 Jan 2000 07:17:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A886352F5; Fri, 7 Jan 2000 07:15:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0C2F352F8; Fri, 7 Jan 2000 07:15:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DA26352F5 for ; Fri, 7 Jan 2000 07:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 07:13:09 EST 2000 Received: from ssaraf.hss.hns.com ([139.85.243.59]) by dusty; Fri Jan 7 07:11:05 EST 2000 Received: from localhost (archow@localhost) by ssaraf.hss.hns.com (8.8.7/8.8.7) with ESMTP id RAA02191 for ; Fri, 7 Jan 2000 17:41:54 +0530 X-Authentication-Warning: ssaraf.hss.hns.com: archow owned process doing -bs Date: Fri, 7 Jan 2000 17:41:54 +0530 (IST) From: To: sip@lists.research.bell-labs.com Subject: General question on SIP used b/w MGCs In-Reply-To: <6525685E.00762D3E.00@sampark.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I recently went thru all the drafts related to PSTN interworking in hgs' site. Now the impression I might have incorrectly formed seems to be that all SIP is doing is providing a wrapper for any payload (ISUP, etc) that needs to be transmitted b/w MGCs. I had a look at both the INFO and the MIME Types - my current understanding is that if an MGC wants to transmit a signal to another MGC, it just creates a SIP Message (INVITE, INFO etc) and just puts the complete signal to be transmitted in the boddy. Now the receiving MGC extracts the body and interprets the signal in what ever way it was meant to be interpreted. Now if SIP is only acting as a wrapper, why is it that people seem to mention that SIP is the preferred interaction scheme b/w MGC - MGC ? Could some one point me to papers (besides the pstn drafts I mentioned) helping me out with this ? Actually the statements abovr must be quite naive, as I dont know much about the MGC side :-) Anyway, I would like to know if besides being just a wrapper which is only tunelling signals to and fro, is there any other advantage of SIP b/w two MGCs ? Thx Regds Arjun Arjun Roychowdhury @ Hughes Software Systems On Thu, 6 Jan 2000, Jonathan Rosenberg wrote: > > > > > The first problem is that there is no way I know of in RSVP for one > reservation to preempt another, and for notification of preemption to be > delivered (there has been some work on MPLS extensions to RSVP which > allow replacement, but I don't know if thats useful for this > application). > > Even if it did, I'm not really sure it matters. This isn't a circuit > network; pre-emption does not imply a one to one replacement of one > circuit with another. One could add priorities to an rsvp reservation so > it always succeeds; all this means is that the loss rate of existing > connections is increased if there really wasn't enough bandwidth for the > new one. You can rely on human response to that to hang up if it gets > really bad. In most cases, I suspect a WAN connection that supports any > kind of data traffic at all will have sufficient resources so that these > high priority reservations won't impact one drop existing calls. > Furthermore, adaptive mechanisms that use FEC or redundanct codecs will > allow performance to be probably not bad for loss rates that are quite > high. > > -Jonathan R. > > > > Bob Bell wrote: > > > > Jonathan - > > > > I understand that this is a different aspect of the problem. It does bear > > on SIP in that if a lower priority call is "preempted", there is supposed > > to be a signal given to the end stations indicating that they have been > or > > are being preempted. That signal would need to be SIP. How and where it > is > > originated is a totally different issue and one I don't currently know > how > > to solve. There would need to be some form of feedback from RSVP or > > DIFFSERV or ???? to allow for that interaction. > > > > Bob Bell > > > > At 10:11 AM 1/6/00, Jonathan Rosenberg wrote: > > >This is a much different service. As the SIP path and media path are > > >different (and, in fact, may flow through completely different service > > >providers), there is really no way for this to be handled at the SIP > > >layer. A proxy can't know to tear down someone elses call if bandwidth > > >were available. Even the UA probably can't know that his call is > > >consuming bandwidth that is preventing some other call from being made. > > > > > >Rather, if the *service* we need is that some generals call gets enough > > >bandwidth, overriding some private, this is best handled by some kind of > > >diffserv or rsvp operation. > > > > > > > > >-Jonathan R. > > > > > >Bob Bell wrote: > > > > > > > > Gentlemen - > > > > > > > > There is another aspect of MLPP which is being ignored here. That is > that I > > > > don't want to talk to you, I just need the bandwidth your > communications is > > > > consuming over a WAN link of limited bandwidth. So, I (or a proxy > which has > > > > a better network view that I do) needs to tell you that you must > terminate > > > > the call. Thus, there is no opportunity for me to present an INVITE > to you > > > > and for you to return a Busy indication. > > > > > > > > Bob > > > > > > > > At 04:50 PM 1/5/00, Adam B. Roach wrote: > > > > > > > > >Jonathan Rosenberg writes: > > > > > > > > > > >Rather than using this MLPP-Version thing to indicate support for > CCBS, > > > > > >I'd rather use the more generic Supported/Require mechanism (a > draft on > > > > > >this is pending within the next few days). So, > > > > > > > > > > > >C->S INVITE > > > > > > > > > > > >S->C 421 Feature Available > > > > > >Require: com.cisco.mlpp > > > > > > > > > > > >C->S INVITE > > > > > >Supported: com.cisco.mlpp > > > > > >MLPP: 2;version=1 > > > > > > > > > > > >S->C 200 OK > > > > > > > > > >It sounds like you're adding yet another round trip: > > > > >the first to agree on the feature, the second to try > > > > >an invite (which gets a "busy" response), and the third > > > > >to invoke the feature (am I misreading something here?) > > > > > > > > > >Keep in mind that MLPP is relevant only when the far side > > > > >returns an indication like "busy." Only *after* the calling > > > > >party is notified that the far side is busy does he make a > > > > >decision that he wants to break in on the call. > > > > > > > > > >Also, in PSTN interoperation scenarios, the gateway won't > > > > >know that you can break in on the called party until the busy > > > > >indication arrives (since we're just pumping the call back > > > > >into the network and don't necessarily know the capability > > > > >of the end office to which the subscriber is physically > > > > >connected) -- so negotiation of the feature cannot occur before > > > > >an attempt is made to reach the called party. > > > > > > > > > >If we're going to go out of our way to borrow a service from > > > > >ISUP, we'd be exceedingly foolish not to make them able to > > > > >interoperate. > > > > > > > > > >-- > > > > >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 > > > > > > > > > > > > > Bob Bell > > > > Cisco Systems Inc. > > > > 801-294-3034(v) > > > > 801-294-3023(f) > > > > > >-- > > >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 > > > > Bob Bell > > Cisco Systems Inc. > > 801-294-3034(v) > > 801-294-3023(f) > > -- > 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 > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 08:49:43 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 IAA17482 for ; Fri, 7 Jan 2000 08:49:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A07B752F7; Fri, 7 Jan 2000 08:47:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1EAC952F9; Fri, 7 Jan 2000 08:47:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AF7D852F7 for ; Fri, 7 Jan 2000 08:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 08:46:42 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 08:44:51 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwyx01060; Fri, 7 Jan 2000 13:46:41 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id IAA10197; Fri, 7 Jan 2000 08:46:39 -0500 (EST) Message-ID: <3875F007.491A2197@dynamicsoft.com> Date: Fri, 07 Jan 2000 08:54:15 -0500 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: sip@lists.research.bell-labs.com Subject: Re: General question on SIP used b/w MGCs 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 archow@hss.hns.com wrote: > > Hi, > Now if SIP is only acting as a wrapper, why is it that people seem to > mention that SIP is the preferred interaction scheme b/w MGC - MGC ? Its not just a transfer function in this application. The call control is driven from SIP; the encapsulated data is extra info that can be used at an ISUP gateway if needed. The result of this is that you get SIPs powerful proxy, forking, search, routing, multi-provider, multi-hop and scaling features, and at the same time, you get ISUP transparency if you want it. Should an INVITE with ISUP payloads hit a non-ISUP gateway (or even a PC phone) the data can be ignored and the call is set up. -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 09:09:42 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 JAA17957 for ; Fri, 7 Jan 2000 09:09:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3F36152F0; Fri, 7 Jan 2000 09:07:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9AE4B52F8; Fri, 7 Jan 2000 09:07:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EC10252F0 for ; Fri, 7 Jan 2000 09:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 09:07:00 EST 2000 Received: from ssaraf.hss.hns.com ([139.85.243.59]) by dusty; Fri Jan 7 09:05:06 EST 2000 Received: from localhost (archow@localhost) by ssaraf.hss.hns.com (8.8.7/8.8.7) with ESMTP id TAA02666; Fri, 7 Jan 2000 19:33:26 +0530 X-Authentication-Warning: ssaraf.hss.hns.com: archow owned process doing -bs Date: Fri, 7 Jan 2000 19:33:26 +0530 (IST) From: To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: General question on SIP used b/w MGCs In-Reply-To: <6525685F.004C8B30.00@sampark.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi Jonathan, so you mean that the real use of using SIP is if I want to merge proxy server features into an MGC is not so useful if I have a config. like another full fledged SIP Proxy server already in the network which already provides these services you mentioned, and my gateway does not therefore need these features ? Regds Arjun On Fri, 7 Jan 2000, Jonathan Rosenberg wrote: > > > > > > > archow@hss.hns.com wrote: > > > > Hi, > > Now if SIP is only acting as a wrapper, why is it that people seem to > > mention that SIP is the preferred interaction scheme b/w MGC - MGC ? > > Its not just a transfer function in this application. The call control > is driven from SIP; the encapsulated data is extra info that can be used > at an ISUP gateway if needed. > > The result of this is that you get SIPs powerful proxy, forking, search, > routing, multi-provider, multi-hop and scaling features, and at the > same time, you get ISUP transparency if you want it. Should an INVITE > with ISUP payloads hit a non-ISUP gateway (or even a PC phone) the data > can be ignored and the call is set up. > > -Jonathan R. > > -- > 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 > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 09:21:53 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 JAA18315 for ; Fri, 7 Jan 2000 09:21:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9677452F8; Fri, 7 Jan 2000 09:19:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 17CC352FA; Fri, 7 Jan 2000 09:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D7C6C52F8 for ; Fri, 7 Jan 2000 09:19:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 09:18:42 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 09:16:50 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwyz05132; Fri, 7 Jan 2000 14:18:39 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id JAA13443; Fri, 7 Jan 2000 09:18:36 -0500 (EST) Message-ID: <3875F783.6258D034@dynamicsoft.com> Date: Fri, 07 Jan 2000 09:26:11 -0500 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: sip@lists.research.bell-labs.com Subject: Re: General question on SIP used b/w MGCs 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 Sorry, I can't completley parse this sentence. I think you are asking if the benefit of using SIP is that you can merge proxy servers into an MGC? If this is the question, the answer is no, thats not at all (in fact, the OPPOSITE) of what I am saying. I'm saying, if the MGC uses SIP, you get to reuse your existing proxy servers, since they already provide routing, scaling, inter-provider access, multi-hop, etc., but you get end to end ISUP transparency as well. -Jonathan R. archow@hss.hns.com wrote: > > Hi Jonathan, > so you mean that the real use of using SIP is if I want to merge proxy > server features into an MGC is not so useful if I have a config. like > another full fledged SIP Proxy server already in the network which already > provides these services you mentioned, and my gateway does not therefore > need these features ? > > Regds > Arjun > > On Fri, 7 Jan 2000, Jonathan Rosenberg wrote: > > > > > > > > > > > > > > > archow@hss.hns.com wrote: > > > > > > Hi, > > > Now if SIP is only acting as a wrapper, why is it that people seem to > > > mention that SIP is the preferred interaction scheme b/w MGC - MGC ? > > > > Its not just a transfer function in this application. The call control > > is driven from SIP; the encapsulated data is extra info that can be used > > at an ISUP gateway if needed. > > > > The result of this is that you get SIPs powerful proxy, forking, search, > > routing, multi-provider, multi-hop and scaling features, and at the > > same time, you get ISUP transparency if you want it. Should an INVITE > > with ISUP payloads hit a non-ISUP gateway (or even a PC phone) the data > > can be ignored and the call is set up. > > > > -Jonathan R. > > > > -- > > 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 > > > > -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 09:34:14 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 JAA18728 for ; Fri, 7 Jan 2000 09:34:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EE71B52FA; Fri, 7 Jan 2000 09:31:52 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6A6B552FC; Fri, 7 Jan 2000 09:31:51 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id E0A5252FA for ; Fri, 7 Jan 2000 09:31:36 -0500 (EST) 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 JAA25475; Fri, 7 Jan 2000 09:31:33 -0500 (EST) Message-ID: <3875F8C5.C699FA44@cs.columbia.edu> Date: Fri, 07 Jan 2000 09:31:33 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.research.bell-labs.com, ldeCarmo@netspeak.com Subject: Re: Gateways and registration References: <200001062343.RAA02390@b04a45.exu.ericsson.se> 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 > > Although not required by the SIP standard, there is absolutely nothing to > keep you from doing this other than the fact that there are better > mechanisms. TRIP might be one avenue to consider. > The slight difficulty is that SIP registers users, so a gateway "representing" phone numbers would have to register a lot of individual users. This is another reason TRIP is preferable, since it has mechanisms to aggregate reachability information. It is not clear to me that creating a wildcard user, with all the possible permutations, would be wise. Obviously, if you know your proxy server, nothing prevents you from registering 415*@gateway or whatevever format you choose. Henning From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 09:51:42 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 JAA19173 for ; Fri, 7 Jan 2000 09:51:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C83E752F9; Fri, 7 Jan 2000 09:49:18 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4990A52FD; Fri, 7 Jan 2000 09:49:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 810A652F9 for ; Fri, 7 Jan 2000 09:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 09:48:24 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 09:46:33 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwzb03034; Fri, 7 Jan 2000 14:48:21 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id JAA17295; Fri, 7 Jan 2000 09:48:19 -0500 (EST) Message-ID: <3875FE7B.AFEEE35@dynamicsoft.com> Date: Fri, 07 Jan 2000 09:55:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Sean Olson , sip@lists.research.bell-labs.com, ldeCarmo@netspeak.com Subject: Re: Gateways and registration References: <200001062343.RAA02390@b04a45.exu.ericsson.se> <3875F8C5.C699FA44@cs.columbia.edu> 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 The additional difficult with SIP REGISTER isn't just the wildcarding problem, but that the semantics are wrong. If multiple gateways register a single number (aka, multiple Contacts with the same To field), the result is that the proxy will *fork* a call to these, in all likelihood, which is not at all what you want. Choosing of a gateway for terminating calls depends a lot on policy information, and requires additional information also not provided in a REGISTER message. TRIP does all this for you, and also works for getting routing information from other domains (thats its main job, in fact). A TRIP implementation on a gateway is actually very simple, since you don't need any of the policy, import, aggregation processing from TRIP, just the exporting operation. In fact, I would argue that a gateway implementation of TRIP is simpler than implementing some kind of REGISTER extension. -Jonathan R. Henning Schulzrinne wrote: > > > > > Although not required by the SIP standard, there is absolutely nothing to > > keep you from doing this other than the fact that there are better > > mechanisms. TRIP might be one avenue to consider. > > > > The slight difficulty is that SIP registers users, so a gateway > "representing" phone numbers would have to register a lot of individual > users. This is another reason TRIP is preferable, since it has > mechanisms to aggregate reachability information. It is not clear to me > that creating a wildcard user, with all the possible permutations, would > be wise. Obviously, if you know your proxy server, nothing prevents you > from registering > > 415*@gateway > > or whatevever format you choose. > > Henning -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 10:14:02 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 KAA19696 for ; Fri, 7 Jan 2000 10:14:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5EA3352AB; Fri, 7 Jan 2000 10:11:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D665852B6; Fri, 7 Jan 2000 10:11:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0749752AB for ; Fri, 7 Jan 2000 10:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 10:10:19 EST 2000 Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Fri Jan 7 10:08:28 EST 2000 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 7 Jan 2000 09:09:46 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 09:09:37 -0600 Message-ID: From: "Tom-PT Taylor" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: not able to understand the call flow for Home Phone implement ation Date: Fri, 7 Jan 2000 09:09:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5921.35C39F0E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF5921.35C39F0E Content-Type: text/plain I'm also interested. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Thursday, January 06, 2000 10:22 AM > To: 'Jonathan Rosenberg' > Cc: 'sip@lists.research.bell-labs.com' > Subject: RE: not able to understand the call flow for Home Phone > implement ation > > > > Are many people interested in this? If there are many folks who would > > like to see some work on SIP extensions required for home > > line service, > > it might be something worthwhile to consider. > > > > Count me in. It has applications beyond home. > > Brian > ------_=_NextPart_001_01BF5921.35C39F0E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: not able to understand the call flow for Home Phone = implement ation

I'm also = interested.

-----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Thursday, January 06, 2000 10:22 AM
To:     'Jonathan Rosenberg'
Cc:     'sip@lists.research.bell-labs.com'
Subject:       = RE: not able to understand the call = flow for Home Phone implement ation

> Are many people interested in = this? If there are many folks who would
> like to see some work on SIP = extensions required for home
> line service,
> it might be something worthwhile = to consider.
>

Count me in. It has applications = beyond home.

Brian

------_=_NextPart_001_01BF5921.35C39F0E-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 10:29: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 KAA20251 for ; Fri, 7 Jan 2000 10:29:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3742152B6; Fri, 7 Jan 2000 10:27:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8C92452BB; Fri, 7 Jan 2000 10:27:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1169252B6 for ; Fri, 7 Jan 2000 10:27:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 10:25:50 EST 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Fri Jan 7 10:23:53 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Fri, 7 Jan 2000 15:25:23 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 15:25:21 -0000 Message-ID: <33E324D95F44D311AA3E00204840075B5501C0@zhard00e.europe.nortel.com> From: "Mark Gibson" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: General question on SIP used b/w MGCs Date: Fri, 7 Jan 2000 15:25:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5923.67B5803E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF5923.67B5803E Content-Type: text/plain I'm saying, if the MGC uses SIP, you get to reuse your existing proxy servers, since they already provide routing, I had understood you to say in the past that a SIP server, and therefore a SIP proxy, used a signalling path that is independent of the media path. I am therefore eager to learn how a proxy provides routing as, as you're doubtless already aware, I have a real interest in this problem. Or is it SIP message routing that you're referring to here? scaling, inter-provider access, multi-hop, etc., but you get end to end ISUP transparency as well. -Jonathan R. I'd appreciate a clarification. Mark ------_=_NextPart_001_01BF5923.67B5803E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: General question on SIP used b/w MGCs

I'm saying, if the MGC uses
SIP, you get to reuse your existing = proxy servers, since they already
provide routing,

I had understood you to say in the = past that a SIP server, and therefore a SIP proxy, used a signalling = path that is independent of the = media path. I am therefore eager to learn how a proxy provides routing = as, as you're doubtless already aware, I have a real interest in this = problem. Or is it SIP = message routing that you're referring to here?

scaling, inter-provider access, = multi-hop, etc., but
you get end to end ISUP transparency = as well.

-Jonathan R.

I'd appreciate a = clarification.

Mark

------_=_NextPart_001_01BF5923.67B5803E-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 10:41:46 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 KAA20559 for ; Fri, 7 Jan 2000 10:41:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5D28D52BB; Fri, 7 Jan 2000 10:39:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C7AE152C4; Fri, 7 Jan 2000 10:39:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C9C3252BB for ; Fri, 7 Jan 2000 10:39:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 10:39:01 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 10:37:10 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwze17126; Fri, 7 Jan 2000 15:38:55 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id KAA17543; Fri, 7 Jan 2000 10:38:53 -0500 (EST) Message-ID: <38760A55.7A80C1FD@dynamicsoft.com> Date: Fri, 07 Jan 2000 10:46:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Gibson Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: General question on SIP used b/w MGCs References: <33E324D95F44D311AA3E00204840075B5501C0@zhard00e.europe.nortel.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 > Mark Gibson wrote: > > I'm saying, if the MGC uses > SIP, you get to reuse your existing proxy servers, since they > already > provide routing, > > I had understood you to say in the past that a SIP server, and > therefore a SIP proxy, used a signalling path that is independent > of the media path. I am therefore eager to learn how a proxy > provides routing as, as you're doubtless already aware, I have a > real interest in this problem. Or is it SIP message routing that > you're referring to here? Yes, it is SIP message routing - issues like telephone number routing are the things the proxy worries about. IP packet routing is already taken care of for us ;) -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 10:58:33 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 KAA20843 for ; Fri, 7 Jan 2000 10:58:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 91E9D52D5; Fri, 7 Jan 2000 10:56:06 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0B29D52DB; Fri, 7 Jan 2000 10:56:05 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id 6440A52D5 for ; Fri, 7 Jan 2000 10:55:50 -0500 (EST) 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 KAA29328; Fri, 7 Jan 2000 10:55:49 -0500 (EST) Message-ID: <38760C85.E94F60E8@cs.columbia.edu> Date: Fri, 07 Jan 2000 10:55:49 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "James M. Polk" Cc: sip@lists.research.bell-labs.com, rtbell@cisco.com Subject: Re: Prioritization limitation question References: <4.1.20000104175635.00bcc6e0@diablo.cisco.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 While the conclusion of this discussion appears to be that a more elaborate mechanism is required to serve this purpose, I wonder if it would be helpful to allow extensions to priority-value in the SIP spec, with the obvious caveat that an application may simply ignore new values, although a reasonable application may decide to render the token as-is, without interpretation. If there are local conventions that encompass the existing priorities, this would seem preferable to forcing people to use X-Priority: local-label and the normal Priority otherwise. I18N, among other reasons, argues against allowing this. James M. Polk wrote: > > Anyone/everyone > > Reading the ANSI document T1.619-1992 a colleague pointed out to me, I > came across its MLPP Prioritization requirements as being the > following: > > 1) 0 Flash Override (Highest) > 2) 1 Flash > 3) 2 Immediate > 4) 3 Priority > 5) 4 Routine (Lowest) > > But looking at SIP grammar/syntax, it only stipulates 4 levels of > priority as the following: > > priority-value = "emergency" | "urgent" | "normal" | "non-urgent" > > Question: Has there been any discussion (which I haven't found yet) on > matching these two specifications? And for clarification, I strongly > prefer SIP moving up to having 5 levels instead of ANSI moving down to > 4 levels in order to meet current US Government/Military Regulations I > really don't want to ask them to change. > > Comments/clarifications are welcome, thank you. > > _______________________________________________________ > A sobering reflection upon this century's greatest accomplishments and > discoveries: > "There is no keystroke that rewrites racism... nor is there any > software that takes care of Mother Earth" > > James M. Polk > Sr. Product Manager, Multiservice Architecture and Standards > Enterprise Voice Business Unit > Cisco Systems > Dallas, Texas > w) 972.813.5208 > f) 972.813.5199 > www.cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 11:06:42 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 LAA21035 for ; Fri, 7 Jan 2000 11:06:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 67AE852DB; Fri, 7 Jan 2000 11:04:16 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CCFA452DC; Fri, 7 Jan 2000 11:04:15 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id 094EB52DB for ; Fri, 7 Jan 2000 11:04:00 -0500 (EST) 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 LAA29670; Fri, 7 Jan 2000 11:03:58 -0500 (EST) Message-ID: <38760E6E.FC138F8A@cs.columbia.edu> Date: Fri, 07 Jan 2000 11:03:58 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Scott Bradner Cc: jdrosen@dynamicsoft.com, rtbell@cisco.com, Adam.Roach@ericsson.com, brosen@fore.com, sip@lists.research.bell-labs.com Subject: Re: Prioritization limitation question References: <200001062133.QAA01696@newdev.harvard.edu> 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 It should also be noted that the issue of session-level preemption for a pure IP environment may be less of an issue than in the PSTN, since a multiple call presences, with full information about who's calling, priority, etc., are easily handled. Whether, from a user-interface point of view, it would be nice to have localized versions of call priority, so that a military officer, say, would see call priorities in familiar renditions, is a separate issue (see my earlier email). The question is whether this should be done explicitly, as in ANSI-Priority: Flash-Override or as extensions to the Priority header. The former is probably cleaner, as it is unlikely that the two ranking systems are to be mixed within the same environment. From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 12:49:57 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 MAA24023 for ; Fri, 7 Jan 2000 12:49:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D653E52C4; Fri, 7 Jan 2000 12:47:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3C26F52D5; Fri, 7 Jan 2000 12:47:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DF59D52C4 for ; Fri, 7 Jan 2000 12:47:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jan 7 12:45:05 EST 2000 Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Fri Jan 7 12:43:13 EST 2000 Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id JAA25904; Fri, 7 Jan 2000 09:44:48 -0800 (PST) From: "David Oran" To: "Jonathan Rosenberg" , "ANIRBAN ROY" Cc: Subject: RE: not able to understand the call flow for Home Phone implementation Date: Fri, 7 Jan 2000 12:44:48 -0500 Keywords: IETF Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3874AEBC.6F547BA2@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Of course, another way to think about this is that there is only one UA, and the different instruments in the house are not in fact separate SIP UAs, since there's only one phone number and one "call" at a time on all of them. In this case, you could use MGCP or Megaco to have the user agent control the various instruments and use multicast or an RTP mixer to distribute the audio properly. Whether this approach is at all desirable hinges on a number of factors. Here's some test cases: a)If two of the home phones are currently talking to someone and one of the two hangs up, can it now make an outgoing call? If the answer is yes, then this isn't really the same as multiple instruments sharing a "line". b)If I pick up a phone while somebody else is talking on another, do I get a choice as to whether I join the current call or not? c)If the far end hangs up, do the home phones stay in communication indefinitely, or do they eventually get howler tone indicating you forgot to hang up the line? d)If one of the phones is currently off hook dialing out, are incoming calls blocked to all the other phones? So, do you REALLY want to exactly emulate the shared-line semantics of current POTS phones? Dave. > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Thursday, January 06, 2000 10:03 AM > To: ANIRBAN ROY > Cc: sip@lists.research.bell-labs.com > Subject: Re: not able to understand the call flow for Home Phone > implementation > > > You are right in that a SIP UA, as currently specified, won't be able to > get home line type of service. It can be done in the way described in > this paper, but it requires changes to the behavior of the UA, although > no changes to the protocol itself, depending on how its done. It also > requires the caller to be "cooperative" - they will receive multiple 200 > OK as each extension picks up, and they need to initiate a multi-party > conference to do it. Basically, if you use multicast instead of forking, > you don't need protocol extensions, just some new behaviors in the UA. > If you want to rely on forking rather than multicast, you need somewhat > more complex extensions. > > When using multicast, the UA basically snoops on the multicast group for > BYEs and other 200 OKs. This allows it to build a complete picture of > what other extensions have picked up, hung up, or been hung up on. Based > on this, it can, in a distributed fashion, figure out the state of the > call. If there are calls active, a user picking up the phone would cause > the phone to send a 200 OK for the call. > > For forking, snooping of BYEs and other messages is not feasible, so > some extensions are needed. However, doing this means you home line > extensions could actually be anywhere in the world. Pretty cool. > > There are other ways to do it which hide from the caller the fact that > multiple extensions have picked up. This is more like how the current > home phone service works. > > Are many people interested in this? If there are many folks who would > like to see some work on SIP extensions required for home line service, > it might be something worthwhile to consider. > > -Jonathan R. > > ANIRBAN ROY wrote: > > > > hi, > > I am trying to figure out how to get a home phone functionality in SIP. > > The home phone has the following functionality > > 1 When a call comes all phones in the home ring > > 2 When one picks up, all other line must stop ringing > > 3 A user can picks up from any other telephone in the home and join > > an existing call. > > > > A scenario is there where A calls a Home > > Phone which has Three connection B, C, D in his home > > > > When a calls to a home phone which has 3 connection (B, C, D) lands on > > proxy, then proxy forks the INVITE message to B, C, D. so every phone > > starts ringing. This is the first character of Home Phone. Now Let's say > > > > B picks up the phone then Proxy sends CANCEL message to C and D so that > > the ringing can stop. This fulfills the Second point of Home Phone. > > > > I am not able to get the call flow for the Third point in home Phone. If > > > > lets say C picks up the phone (when both A and C in conversation)then he > > should also be in session with A > > and B. How can this be done because When a CANCEL message is received by > > > > C and D then they both reached the state where they can only expect > > INVITE. > > > > Can any one please tell me how the call flow for the third point in the > > home phone. > > > > The above points of Home phone were taken from the -----Bell Labs > > Journal (October-December 1998) > > > > regards > > Anirban > > -- > 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 > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 13:03:47 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 NAA24344 for ; Fri, 7 Jan 2000 13:03:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 562C652DB; Fri, 7 Jan 2000 13:01:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CB7B752DC; Fri, 7 Jan 2000 13:01:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7709752DB for ; Fri, 7 Jan 2000 13:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 13:00:34 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 12:58:42 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwzo05517; Fri, 7 Jan 2000 18:00:32 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id NAA17713; Fri, 7 Jan 2000 13:00:28 -0500 (EST) Message-ID: <38762B82.45B7314@dynamicsoft.com> Date: Fri, 07 Jan 2000 13:08:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Oran Cc: ANIRBAN ROY , sip@lists.research.bell-labs.com Subject: Re: not able to understand the call flow for Home Phone implementation 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 David Oran wrote: > > Whether this approach is at all desirable hinges on a number of factors. > Here's some test cases: > a)If two of the home phones are currently talking to someone and one of the > two hangs up, can it now make an outgoing call? If the answer is yes, then > this isn't really the same as multiple instruments sharing a "line". > b)If I pick up a phone while somebody else is talking on another, do I get a > choice as to whether I join the current call or not? > c)If the far end hangs up, do the home phones stay in communication > indefinitely, or do they eventually get howler tone indicating you forgot to > hang up the line? > d)If one of the phones is currently off hook dialing out, are incoming calls > blocked to all the other phones? > > So, do you REALLY want to exactly emulate the shared-line semantics of > current POTS phones? I'm not at all sure we want to emulate the current semantics. For one, I kind of like the capability of knowing when (and who) picks up on several extensions; this would argue for these devices being SIP UAs and sending a 200 OK as each picks up. If we take on this work (which there does seem sufficient interest to do), the first task is to figure out which scenarios are supported. It may turn out that the spec is some general extensions and then a description of how some number of different cases might be supported. -Jonathan R. -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 13:11:51 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 NAA24451 for ; Fri, 7 Jan 2000 13:11:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 83E9752DC; Fri, 7 Jan 2000 13:09:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EE30B52DD; Fri, 7 Jan 2000 13:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2F51952DC for ; Fri, 7 Jan 2000 13:09:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jan 7 13:07:48 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Jan 7 13:05:56 EST 2000 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhwzo23928; Fri, 7 Jan 2000 18:07:43 GMT Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id NAA17721; Fri, 7 Jan 2000 13:07:40 -0500 (EST) Message-ID: <38762D33.6B932AE8@dynamicsoft.com> Date: Fri, 07 Jan 2000 13:15:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ANIRBAN ROY Cc: Dean Willis , Sean Olson , sip@lists.research.bell-labs.com Subject: Re: A case related to "home Phone" type of functionality in SIP References: <000601bf58b0$8a618b00$21e323a6@mcit.com> <3875B8AA.B7814A40@wipsys.soft.net> 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 I'd rather not delve too much farther into the technical details of how until we have understood what we want to accomplish. There have been lots of ideas already in the last few days on how to do this, and they all are solutions to slightly different problems. So, given there appears to be interest in working on this, let me ask the next question - who is willing to volunteer to work on a design team to develop some documents for this? First step is requirements. If there are sufficient people who are willing to actually do the work (phone conferences, mail discussions and possibly a face to face), I will discuss the possibility of adding this as a work item with my co-chairs and the ADs. -Jonathan R. ANIRBAN ROY wrote: > > hi , > > lets say in a house there are 3 phones B, C, D. now User "A" calls to this house > > Please tell me one question > > When a call is going on between two user A and B and the third person "C" picks > up the phone from the same house what happens then????. > > # does a 200 Response goes back to the caller. Or the 200 Response just > append the Multicast Address with address "C". > > # RTP data goes directly from caller to callee. When there are more than one > user is in conversation how Proxy makes it sure that the RTP data will be send > to particular multicast address. As because Proxy only work in the signalling > layer. > > Please reply > > Anirban > > Dean Willis wrote: > > > Are you saying that the first phone would multicast the media streams to the > > others on the local LAN, or that the INVITES and media would be sent > > multicast across the ISP network? > > > > If the former, it might work. COuld be pretty cool. > > > > If the latter, no, it's not going to happen that way. > > > > 1) No ISP that I know of will provide a multicast feed, especially for a > > lowly dialup user. > > > > 2) Every SIP phone in the country is going to listen to a universal > > multicast group, then make application discard decisions on the INVITES that > > don't apply to it . . . Or, we could statically allocate a multicast > > address for each home network . . .not. The INVITE will come in UNICAST. > > > > 3) Personally, I've never managed to get multicast routing working right > > over the bizarre equipment that has accumulated at my house. > > > > 4) In our own internal network, we often saw join times that took seven or > > eight minutes to propaget back to the source of a multicast. That's some > > serious post-dial delay. I'm not sure we even try to route multicast > > anymore. > > > > 5) The firewall issues that occur with cross-domain multicast are mind > > boggling. Anything coming into my house is by-definition cross-domain. > > > > Hey, I love multicast. I spent more than two years building really cool > > businesses (Real Broadcast Netork, skyMCI, etc.) around it, and I'm here to > > tell you it just isn't going to happen across an Internet backbone for the > > average user any time soon. > > > > -- > > Dean > > > > > -----Original Message----- > > > From: Sean Olson [mailto:eussean@exu.ericsson.se] > > > Sent: Thursday, January 06, 2000 5:49 PM > > > To: dean.willis@wcom.com > > > Cc: sip@lists.research.bell-labs.com > > > Subject: RE: A case related to "home Phone" type of functionality in SIP > > > > > > > > > > > > > > In a business environment, we call this a "single line extension". > > > > > > > > SIP approaches tend to have the property that each phone is uniquely > > > > addressed, whereas in the PSTN each circuit is uniquely addressed. > > > > > > > > The obvious solution is to combine a parallel search proxy and some UAS > > > > behavior. > > > > > > > > The sequence is: > > > > 1) Incoming call reaches parallel proxy. > > > > 2) Parallel proxy invites all UASes in extension group. > > > > 3) User answers one extension. > > > > 4) Parallel proxy cancels unanswered legs. Those phones stop ringing. > > > > 5) Answering phone send INVITE to other phones in group, with "NO RING" > > > > specified somehow, and long expire timer. > > > > > > > > > > > > > > In a business environment, this is a perfectly acceptable and reasonable > > > solution. For a home environment, multicast/DHCP seems more reasonable > > > because Joe consumer can go to Radio Shack, buy a 3com SIP phone, and > > > plug it into his home IP network and it works with zero (or > > > almost-zero) configuration. Plus, it doesn't require the home user > > > to buy/maintain a parallel proxy. > > > > > > (By multicast, I mean both signalling and media). > > > > > > ----------------------------------------------------------------- > > > Sean Olson mailto:sean.olson@ericsson.com > > > Ericsson Inc. tel:(972)583-5472 > > > fax:(972)669-0154 > > > -- 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 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 13:16:21 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 NAA24529 for ; Fri, 7 Jan 2000 13:16:17 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 70FFC52DD; Fri, 7 Jan 2000 13:13:30 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA6BF52DE; Fri, 7 Jan 2000 13:13:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5327152DD for ; Fri, 7 Jan 2000 13:13:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jan 7 13:11:51 EST 2000 Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Fri Jan 7 13:09:59 EST 2000 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 NAA14997; Fri, 7 Jan 2000 13:11:45 -0500 (EST) 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 NAA06902; Fri, 7 Jan 2000 13:11:49 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 13:09:17 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF06860D@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , ANIRBAN ROY Cc: Dean Willis , Sean Olson , sip@lists.research.bell-labs.com Subject: RE: A case related to "home Phone" type of functionality in SIP Date: Fri, 7 Jan 2000 13:11:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I'll work on it. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 07, 2000 1:15 PM > To: ANIRBAN ROY > Cc: Dean Willis; Sean Olson; sip@lists.research.bell-labs.com > Subject: Re: A case related to "home Phone" type of > functionality in SIP > > > I'd rather not delve too much farther into the technical > details of how > until we have understood what we want to accomplish. There have been > lots of ideas already in the last few days on how to do this, and they > all are solutions to slightly different problems. > > So, given there appears to be interest in working on this, let me ask > the next question - who is willing to volunteer to work on a > design team > to develop some documents for this? First step is > requirements. If there > are sufficient people who are willing to actually do the work (phone > conferences, mail discussions and possibly a face to face), I will > discuss the possibility of adding this as a work item with my > co-chairs > and the ADs. > > -Jonathan R. > > ANIRBAN ROY wrote: > > > > hi , > > > > lets say in a house there are 3 phones B, C, D. now User > "A" calls to this house > > > > Please tell me one question > > > > When a call is going on between two user A and B and the > third person "C" picks > > up the phone from the same house what happens then????. > > > > # does a 200 Response goes back to the caller. Or the > 200 Response just > > append the Multicast Address with address "C". > > > > # RTP data goes directly from caller to callee. When > there are more than one > > user is in conversation how Proxy makes it sure that the > RTP data will be send > > to particular multicast address. As because Proxy only work > in the signalling > > layer. > > > > Please reply > > > > Anirban > > > > Dean Willis wrote: > > > > > Are you saying that the first phone would multicast the > media streams to the > > > others on the local LAN, or that the INVITES and media > would be sent > > > multicast across the ISP network? > > > > > > If the former, it might work. COuld be pretty cool. > > > > > > If the latter, no, it's not going to happen that way. > > > > > > 1) No ISP that I know of will provide a multicast feed, > especially for a > > > lowly dialup user. > > > > > > 2) Every SIP phone in the country is going to listen to a > universal > > > multicast group, then make application discard decisions > on the INVITES that > > > don't apply to it . . . Or, we could statically allocate > a multicast > > > address for each home network . . .not. The INVITE will > come in UNICAST. > > > > > > 3) Personally, I've never managed to get multicast > routing working right > > > over the bizarre equipment that has accumulated at my house. > > > > > > 4) In our own internal network, we often saw join times > that took seven or > > > eight minutes to propaget back to the source of a > multicast. That's some > > > serious post-dial delay. I'm not sure we even try to > route multicast > > > anymore. > > > > > > 5) The firewall issues that occur with cross-domain > multicast are mind > > > boggling. Anything coming into my house is by-definition > cross-domain. > > > > > > Hey, I love multicast. I spent more than two years > building really cool > > > businesses (Real Broadcast Netork, skyMCI, etc.) around > it, and I'm here to > > > tell you it just isn't going to happen across an Internet > backbone for the > > > average user any time soon. > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: Sean Olson [mailto:eussean@exu.ericsson.se] > > > > Sent: Thursday, January 06, 2000 5:49 PM > > > > To: dean.willis@wcom.com > > > > Cc: sip@lists.research.bell-labs.com > > > > Subject: RE: A case related to "home Phone" type of > functionality in SIP > > > > > > > > > > > > > > > > > > In a business environment, we call this a "single > line extension". > > > > > > > > > > SIP approaches tend to have the property that each > phone is uniquely > > > > > addressed, whereas in the PSTN each circuit is > uniquely addressed. > > > > > > > > > > The obvious solution is to combine a parallel search > proxy and some UAS > > > > > behavior. > > > > > > > > > > The sequence is: > > > > > 1) Incoming call reaches parallel proxy. > > > > > 2) Parallel proxy invites all UASes in extension group. > > > > > 3) User answers one extension. > > > > > 4) Parallel proxy cancels unanswered legs. Those > phones stop ringing. > > > > > 5) Answering phone send INVITE to other phones in > group, with "NO RING" > > > > > specified somehow, and long expire timer. > > > > > > > > > > > > > > > > > > In a business environment, this is a perfectly > acceptable and reasonable > > > > solution. For a home environment, multicast/DHCP seems > more reasonable > > > > because Joe consumer can go to Radio Shack, buy a 3com > SIP phone, and > > > > plug it into his home IP network and it works with zero (or > > > > almost-zero) configuration. Plus, it doesn't require > the home user > > > > to buy/maintain a parallel proxy. > > > > > > > > (By multicast, I mean both signalling and media). > > > > > > > > > ----------------------------------------------------------------- > > > > Sean Olson mailto:sean.olson@ericsson.com > > > > Ericsson Inc. tel:(972)583-5472 > > > > fax:(972)669-0154 > > > > > > -- > 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 > From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 13:37:45 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 NAA24890 for ; Fri, 7 Jan 2000 13:37:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3676852DE; Fri, 7 Jan 2000 13:35:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A888052BB; Fri, 7 Jan 2000 13:35:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A821852DE for ; Fri, 7 Jan 2000 13:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 13:33:46 EST 2000 Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Fri Jan 7 13:31:54 EST 2000 Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id KAA29572; Fri, 7 Jan 2000 10:33:03 -0800 (PST) From: "David Oran" To: "Jonathan Rosenberg" Cc: "ANIRBAN ROY" , Subject: RE: not able to understand the call flow for Home Phone implementation Date: Fri, 7 Jan 2000 13:33:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38762B82.45B7314@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 07, 2000 1:08 PM > To: David Oran > Cc: ANIRBAN ROY; sip@lists.research.bell-labs.com > Subject: Re: not able to understand the call flow for Home Phone > implementation > [snip] > I'm not at all sure we want to emulate the current semantics. Bingo. My view exactly. That's why I started listing the mind-benders. From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 13:51:45 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 NAA25039 for ; Fri, 7 Jan 2000 13:51:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6174752D5; Fri, 7 Jan 2000 13:49:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CFA7152DF; Fri, 7 Jan 2000 13:49:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 613AF52D5 for ; Fri, 7 Jan 2000 13:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 13:48:52 EST 2000 Received: from tnint06.telogy.com ([209.116.120.7]) by dusty; Fri Jan 7 13:47:01 EST 2000 Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 13:48:39 -0500 Message-ID: <61891BA043DED21180920090273F173803476A@TNINT06> From: Wing Man Kwok To: "'sip@lists.research.bell-labs.com'" Subject: Current status of DCS Date: Fri, 7 Jan 2000 13:48:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi all, I would like to ask what is the current status of DCS? I heard from one of my colleagues that the 2 stage call setup as proposed in the earlier DCS draft is being modified to a one stage call setup. Is this true? Any pointer to an updated version of DCS draft or related documents is greatly appreciated. Thanks. Wing Man Kwok From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 14:35:43 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 OAA25743 for ; Fri, 7 Jan 2000 14:35:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 80D2B52AB; Fri, 7 Jan 2000 14:33:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F376852DF; Fri, 7 Jan 2000 14:33:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1FB3452AB for ; Fri, 7 Jan 2000 14:33:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jan 7 14:33:02 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Fri Jan 7 14:31:11 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA08030; Fri, 7 Jan 2000 13:32:59 -0600 (CST) 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 NAA25090; Fri, 7 Jan 2000 13:32:59 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA05991; Fri, 7 Jan 2000 13:32:58 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA06512; Fri, 7 Jan 2000 13:32:57 -0600 (CST) Date: Fri, 7 Jan 2000 13:32:57 -0600 (CST) Message-Id: <200001071932.NAA06512@b04a45.exu.ericsson.se> To: schulzrinne@cs.columbia.edu Subject: Re: Gateways and registration Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > > > Although not required by the SIP standard, there is absolutely nothing to > > keep you from doing this other than the fact that there are better > > mechanisms. TRIP might be one avenue to consider. > > > > The slight difficulty is that SIP registers users, so a gateway > "representing" phone numbers would have to register a lot of individual > users. This is another reason TRIP is preferable, since it has > mechanisms to aggregate reachability information. It is not clear to me > that creating a wildcard user, with all the possible permutations, would > be wise. Obviously, if you know your proxy server, nothing prevents you > from registering > > 415*@gateway > > or whatevever format you choose. > > Henning > True, it would require some interesting syntax but I believe the semantics he had in mind are different. The problem he is trying to solve is not registering a gateway that is capable of answering for a set of users, but more simply, registering the fact that a given gateway is up and in service. The set of users that a given gateway can support would then have to be either statically configured or negotiated through some different protocol such as TRIP. sean From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 14:43:04 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 OAA25914 for ; Fri, 7 Jan 2000 14:43:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BF5EB52B6; Fri, 7 Jan 2000 14:40:48 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 387EE52DF; Fri, 7 Jan 2000 14:40:48 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id 1411252B6 for ; Fri, 7 Jan 2000 14:40:34 -0500 (EST) 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 OAA08212; Fri, 7 Jan 2000 14:40:35 -0500 (EST) Message-ID: <38764133.E1CE91C1@cs.columbia.edu> Date: Fri, 07 Jan 2000 14:40:35 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.research.bell-labs.com Subject: Re: Gateways and registration References: <200001071932.NAA06512@b04a45.exu.ericsson.se> 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 > > True, it would require some interesting syntax but I believe the semantics > he had in mind are different. The problem he is trying to solve is not > registering a gateway that is capable of answering for a set of users, but > more simply, registering the fact that a given gateway is up and in service. > The set of users that a given gateway can support would then have to be > either statically configured or negotiated through some different protocol > such as TRIP. However, registration of a gateway only shows that the gateway was available, say, an hour ago, unless the gateway is kind enough to "sign out" before it crashes. If you already know that you want to send a call to the gateway and you only have one, you might as well try and find out quickly whether it's up or not. If there's a choice of gateways, you presumably need something like TRIP to determine the correct one, in the absence of information which "users" (phone #) each gateway handles. > > sean From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 14:45:54 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 OAA25943 for ; Fri, 7 Jan 2000 14:45:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D5CF852DF; Fri, 7 Jan 2000 14:43: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 43CFD52E0; Fri, 7 Jan 2000 14:43:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8265052DF for ; Fri, 7 Jan 2000 14:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 14:42:12 EST 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Fri Jan 7 14:40:20 EST 2000 Received: by crash with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 14:42:09 -0500 Message-ID: From: Linden deCarmo To: "'Sean Olson'" , schulzrinne@cs.columbia.edu Cc: sip@lists.research.bell-labs.com Subject: RE: Gateways and registration Date: Fri, 7 Jan 2000 14:42:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk >True, it would require some interesting syntax but I believe the semantics >he had in mind are different. The problem he is trying to solve is not >registering a gateway that is capable of answering for a set of users, but >more simply, registering the fact that a given gateway is up and in service. >The set of users that a given gateway can support would then have to be >either statically configured or negotiated through some different protocol >such as TRIP. This is EXACTLY what I'm trying to solve Sean. I'd prefer to do it in SIP rather than a companion protocol, because we're trying to interface with 3rd party gateways that may/may not talk TRIP. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 From owner-sip-outgoing@lists.research.bell-labs.com Fri Jan 7 14:53:38 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 OAA26068 for ; Fri, 7 Jan 2000 14:53:38 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E079552BB; Fri, 7 Jan 2000 14:51:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5438C52E1; Fri, 7 Jan 2000 14:51:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D31A52BB for ; Fri, 7 Jan 2000 14:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jan 7 14:50:29 EST 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Fri Jan 7 14:48:38 EST 2000 Received: by crash with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 14:50:27 -0500 Message-ID: From: Linden deCarmo To: "'Henning Schulzrinne'"