Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt
Steve.Carr@icn.siemens.com Sat, 20 November 1999 00:16 UTC
Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19355 for <sip-archive@odin.ietf.org>; Fri, 19 Nov 1999 19:16:45 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix) id 1255F52EB; Fri, 19 Nov 1999 18:09: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 56D225302; Fri, 19 Nov 1999 18:09:05 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (research.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9BE0D52B6 for <sip@lists.research.bell-labs.com>; Thu, 18 Nov 1999 11:37:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Nov 18 11:37:04 EST 1999
Received: from lmmx1.fl.icn.siemens.com ([192.132.51.129]) by dusty; Thu Nov 18 11:35:50 EST 1999
Received: from li01.lm.ssc.siemens.com (li01.lm.ssc.siemens.com [135.5.43.54]) by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with SMTP id LAA14389; Thu, 18 Nov 1999 11:26:14 -0500 (EST)
Received: by li01.lm.ssc.siemens.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 8525682D.005ACE20 ; Thu, 18 Nov 1999 11:31:50 -0500
X-Lotus-FromDomain: ICN
From: Steve.Carr@icn.siemens.com
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, Adam.Roach@ericsson.com, bartw@nortelnetworks.com, Gonzalo.Camarillo@ericsson.com, sip@lists.research.bell-labs.com
Message-ID: <8525682D.005ACC48.00@li01.lm.ssc.siemens.com>
Date: Thu, 18 Nov 1999 11:27:35 -0500
Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
I think this will work. In order to help you with the ISUP, I just checked Q763. The SAM cannot contain any additional information except additional digit(s). This means that it is not neccessary to send a SAM for each digit, but one SAM can be sent with as many additional digits as are available, so "The egress gateway computes the SAMs based on differentials. So, lets say it receives the INVITE with 1555, then the INVITE with 155512. It then sends two SAMs, the first with 1, the next with 2." can be modified with "It then sends one SAM, with both digits 1 and 2." Steve Carr Unisphere Solutions, Inc. Jonathan Rosenberg <jdrosen@dynamicsoft.com> on 11/18/99 10:57:31 AM To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> cc: Adam.Roach@ericsson.com, bartw@nortelnetworks.com, Gonzalo.Camarillo@ericsson.com, sip@lists.research.bell-labs.com (bcc: Steve Carr/Internet/ICN) Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt What if, rather than encapsulating subsequent digits into INFO, they are added to the request URI in an INVITE? A local proxy for the gateway will respond with 484 to all those that don't have enough digits until it gets one that does have enough. So: Ingress GW P Egress GW INV tel:1 ------------> CSeq: 1 INV tel:12 -----------> CSeq: 2 <---------484 -------- CSeq: 1 INV tel:121 ---------> CSeq: 3 <---------484 ------- CSeq: 2 INV tel:1212 --------> ----------------------> IAM 1212----------> CSeq: 4 <--------------484---- CSeq: 3 INV tel:12125---------> ----------------------> SAM 5 -------------> CSeq: 5 INV tel:121255 -------> ----------------------> SAM 5 -------------> CSeq: 6 INV tel:1212555 ------> -----------------------> SAM 5 ------------> CSeq: 7 .......(same thing for digits 1, 2, 1) INV tel:12125551212----> ---------------------> SAM 2 --------------> CSeq: 11 <---------ACM------- <------484----------- CSeq: 5 <------484----------- CSeq: 6 ....... <------484 CSeq: 10 <---183-------------- CSeq: 11 Ok, so let me explain. Proxies do routing just on longest prefix matches for INVITE's. So, proxy P can be stateless actually, as it just forwards INVITEs that match 1212. The ingress gateway sends a re-INVITE (possibly without waiting for a response to the previous INVITE) every time a new digit is received from the PSTN. Once the proxy has enough digits to route, it won't send 484 anymore, and forwards it to the egress gateway. The egress gateway is smart, and creates an IAM from the first INVITE. Subsequent re-INVITEs cause SAMs to be sent, containing the difference in the set of digits from the previous INVITE. Once the egress gateway receives an ACM (address complete, right?), it responds with a 484 to all the INVITEs but the last, and the final INVITE with a 183. Things progress normally from there. Implications: 1. proxies don't have to know anything about INFO or ISUP. They just have to know longest prefix match routing for phone numbers. They can even be stateless. 2. egress gateways that know ISUP effectively re-generate the SAMs 3. if the egress point is not an ISUP gateway, but a PC terminal or something that happens to have a phone number as its name, it will have to know enough to reject each INVITE until it gets one with a request URI/To field that matches its own number. This, BTW, is normal behavior. A UAS rejects an INVITE if the URI is for an address thats not its own. 4. This works *even* if there is misordering of re-INVITEs. The egress gateway computes the SAMs based on differentials. So, lets say it receives the INVITE with 1555, then the INVITE with 155512. It then sends two SAMs, the first with 1, the next with 2. Lets say, then, that the INVITE with 15551 comes. Based on CSeq, the egress gateway knows its old and rejects it. 5. The ingress gateway doesn't depend on special messages or a completion character, like #, to send an INVITE. Its very possible I've completely missed something, as I'm hardly an ISUP expert. Perhaps there is additional data in SAM such that it MUST be sent across, rather than being regenerated. But, the above solution seems nice, as it doesn't break anything, works with non-ISUP terminating points, doesn't require users to dial a # at the end of the digit string, etc. Comments? -Jonathan R. Gonzalo Camarillo wrote: > > It is nicer to send complete URIs in the "to" header. If the i-gateway > sends the INVITE before receiveing all the digits, the "to" header is > not complete. It would contain just a few digits of the whole telephone > number (this assumes that with just some digits the i-gateway figures > out where to send the INVITE). > > Gonzalo > > Adam.Roach@ericsson.com wrote: > > > > >The use of a timer to force enbloc signaling is not acceptable. In the case > > >of SIP bridging, subscribers originating calls from the PSTN will not accept > > >an artificial post-dial delay (even if it is just a few seconds long). > > >Overlap signaling must be supported. It is essential that the overlap > > >process takes place within the context of a single session - using the > > >suggested INVITE/CANCEL/INVITE approach would result in multiple abortive > > >calls being delivered to the terminating agent, which would not be > > >acceptable. > > > > > >Why not send an INVITE message when the ISUP IAM is received and then send > > >subsequent INFO messages for each ISUP SAM? I understand that "pure" SIP > > >agents will expect the INVITE to contain the complete address of the called > > >party. This could be handled by including support for overlap in the > > >"Require" extensions (draft-roach-mmusic-sip-pstn-require-header-00.txt). If > > >the terminator did not support the PSTN extensions, the originator could > > >then switch to enbloc and wait for the full address to be collected. > > > > There are a variety of problems here. The first is determining how > > intervening proxies will react. If, for example, a proxy is making > > decisions about where to forward messages based on a called party URI, > > your suggestion would require it to understand ISUP (for interpretation > > of SAM message). It also requires it to have number analysis code and > > dialing plan information (potentially for the entire globe). > > > > The problem gets even stranger for redirect servers, which expect to > > be able to send an immediate response to an INVITE -- not sit around > > collecting digits. > > > > Basically, your suggestion forces overlapped dialing deep into each > > and every SIP node in the network that is expected to receive calls > > originating from the PSTN network. > > > > I agree that this is a problem that needs to be solved if we intend > > to use SIP between two PSTN phones; but we need to find a better > > solution than tunelling SAMs all over the place. > > > > We shouldn't overlook human factors: it could be that customers are > > willing to, for example, be trained to press "#" at the end of a > > phone number to skip the post-dial-delay. > > > > -- > > 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 > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 31 18 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland -- 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
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Lyndon Ong
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Ravandhu Hariram
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Henning Schulzrinne
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Henning Schulzrinne
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Steve.Carr
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Daniel G. Petrie
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Overlap signaling to INVITE (Was RE: Comments… Michael A. Ramalho
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Overlap signaling to INVITE (Was RE: Comments… Henning Schulzrinne
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Schroeder, Tim
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Daniel G. Petrie
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Daniel G. Petrie
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Henning Schulzrinne
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Adam B. Roach
- Re: Overlap signaling to INVITE (Was RE: Comments… Jonathan Rosenberg
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… mikko.alutoin
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Daniel G. Petrie
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Dean Willis
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Anil Yelundur
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Henning Schulzrinne
- Please push the pound key ( was RE: Comments on d… Henry Sinnreich
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Matt Cannon
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Comments on draft-camarillo-mmusic-sip-isup-bcp-0… Bart Wensley
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Overlap signaling to INVITE (Was RE: Comments… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Adam B. Roach
- Overlap signaling to INVITE (Was RE: Comments on … Dean Willis
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… Tom-PT Taylor
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Adam B. Roach
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Chip Sharp
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- RE: Comments on draft-camarillo-mmusic-sip-isup-b… mikko.alutoin
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Adam B. Roach
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Overlap signaling to INVITE (Was RE: Comments… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Pete Cordell
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Jonathan Rosenberg
- Re: Overlap signaling to INVITE (Was RE: Comments… Henning Schulzrinne
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Gonzalo Camarillo
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Adam B. Roach
- Re: Comments on draft-camarillo-mmusic-sip-isup-b… Thomas Marshall Eubanks