Message not delivered to recipients below. Press F1 for help with VNM error codes. VNM3036: Samuel Chiu@Support@DAHK-HKG VNM3036 -- RETRY PERIOD EXPIRED If a user sends a message with an undeliverable address, Mail keeps trying to deliver the message for a time period specified by the message expiration time. If the message cannot be delivered within that period, the sender receives a notice of undeliverable mail with this error code. Check the address on the message, and make any necessary corrections. If the address appears to be correct, verify that the connections to the recipient's mail service are working properly and that the recipient's group still exists. ---------------------- Original Message Follows ---------------------- ascend-users-digest Friday, 23 May 1997 Volume 96 : Number 633 In this issue: Re: (ASCEND) 56k and CT1 Re: (ASCEND) Cannot get 5.0A to work Re: (ASCEND) Newbie Radius Question. (ASCEND) K56flex NOT reporting user's receive speed in RADIUS Re: (ASCEND) Analog Multilink PPP and RAS Digital Padding at the Switch, was RE: (ASCEND) 56k and CT1 Re[2]: (ASCEND) Cannot get 5.0A to work Re: (ASCEND) Analog Multilink PPP and RAS (ASCEND) thank you, Ascend Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS Re: (ASCEND) Analog Multilink PPP Re: (ASCEND) Analog Multilink PPP Re: (ASCEND) PPP over Clear Channel T-1 into Max 4000? Re: (ASCEND) AMPPP>Why same modem? (ASCEND) 5.0Ap9 only for MAX2000/BRI Re: (ASCEND) 5.0Ap9 only for MAX2000/BRI (ASCEND) CT1 Not Answering Call Re: (ASCEND) CT1 Not Answering Call Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS ---------------------------------------------------------------------- From: Dale Botkin <dbotkin@probe.net> Date: Fri, 23 May 1997 15:33:49 -0500 (CDT) Subject: Re: (ASCEND) 56k and CT1 On Fri, 23 May 1997, Darkshot wrote: > Watch this space. We have K56FLEX modems going in on Trunkside > CT1's next week- our K56FLEXen on PRI are already working fine. > Even with the marginal phone lines out here in the boonies. Lucky SOB! 8-) OK, Ascend, to what address do I need to send the hookers to get my 56K upgrade cards shipped? And to whose attention? Dale - -------------------------------------------------------------- Dale Botkin, President | Voice: (402) 593-9800 Probe Technology Internet Services | FAX: (402) 593-8748 Omaha, NE | Email: dbotkin@probe.net ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Kevin Smith <kevin@ascend.com> Date: Fri, 23 May 1997 13:32:15 -0700 Subject: Re: (ASCEND) Cannot get 5.0A to work At 11:51 AM 5/23/97 +0200, Pierre-Yves Kerembellec wrote: >Le [Fri, 23 May 97 10:14:09 EET], Sakari Aaltonen ecrivait : > >> I have been connecting succesfully to a Max200+ - software >> version 4.6C - using ISDN and callback. >> >> Now there is a new software version, 5.0A, that replaces >> 4.6C. Well, neither p1, p3, p4, p5, nor p7 work. >> <snip> > >Hi ! > >I already have an open ticket with Ascend support regarding this >particular issue : this is a problem in Ascend software. > >My ticket # is 106492 ... >This problem is reported as TR 2140 Just FYI, TR#2140 *seems* to be fixed in 5.0Ap8 -despite not being in the release notes. I'll try to get more details on who tested it, but may be worth a try... Kevin Smith Updated Service and Support Ascend Communications Resources are now at: <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Kevin Smith <kevin@ascend.com> Date: Fri, 23 May 1997 13:33:42 -0700 Subject: Re: (ASCEND) Newbie Radius Question. At 08:39 AM 5/23/97 +0100, Adrian J Bool wrote: >On Fri 23 May, Kevin Smith wrote: >> At 05:58 PM 5/21/97 -0400, Craig Salmond wrote: >> >Is it possible to have radius read the /etc/passwd (or /etc/shadow) file >> >instead of the /etc/raddb/users file? Or alternatley a way to create the >> >users file from the /etc/passwd file. >> >> Well if you just put the DEFAULT entry in the users file, it will go to >> the UNIX password file via the "login" daemon (that's right isn't it?). > >... and "UNIX" as the password for that entry ? Yes. I was *assuming* the same entry that is in all of the example user files... Kevin Smith Updated Service and Support Ascend Communications Resources are now at: <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Todd Vierling <tv@pobox.com> Date: Fri, 23 May 1997 16:48:56 -0400 (EDT) Subject: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT* report the connect rate the user sees (the K56flex rate) in RADIUS accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most common transmit rate for K56flex) or 33600. Now, I'd consider this a TR, but Ascend techs are telling me to raise it as a feature enhancement. Show of hands: Who considers this a TR? Who considers this a FE? ===== == Todd Vierling (Personal tv@pobox.com; Business tv@iag.net) Foo-bar-baz! == == System administrator/technician, Internet Access Group, Orlando Florida == == Dialups in Orange, Volusia, Lake, Osceola counties - <A HREF="http://www.iag.net">http://www.iag.net</A> == ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: David Lesher <wb8foz@nrk.com> Date: Fri, 23 May 1997 17:08:01 -0400 (EDT) Subject: Re: (ASCEND) Analog Multilink PPP and RAS You just gained another reason to support analog MP. The Maryland Hearing examiner has ruled in favor of Bell Awful; by rejecting testimony to the contrary, and adopting the PUC staff proposal. - -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433 ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Dave Van Allen <dave@fast.net> Date: Fri, 23 May 1997 18:16:33 -0400 Subject: Digital Padding at the Switch, was RE: (ASCEND) 56k and CT1 Just FYI - On channelized T1's (not PRI), the digital-padding Kevin refereed to is usually configurable at the Switch. While I don't have specifics for Lucent/AT&T switches, on NorTel the following info may be handy. When ordering lines (trunk side) from DMS provisioned services, specify to the provider that you wish to have your trunks data-filled with NIL PAD GROUP. This tells the DSP on the DMS switch to *not* alter the gain or frequency response of the incoming DS0 channels. Most Telco's still apply standard "pads" to data circuits incorrectly, mainly because of not understanding the issues. (they use voice designed pads as a default in many cases) On a DMS switch, there are about 50 pad groups, the one you usually want is "NPDGP" (NIL PAD GROUP) In some cases, this change alone is worth 2 speed increases higher in connect rates, and far less "phantom" discos for end users. You mileage will vary and there are a few reasons why this is NOT absolute advise for all instances, but it is a pointer for those who are experiencing troubles. Best regards, Dave Van Allen - You Tools Corporation/FASTNET(tm) dave@fast.net (610)289-1100 <A HREF="http://www.fast.net">http://www.fast.net</A> FASTNET - PA/NJ/DE Business Internet Solutions >-----Original Message----- >From: Kevin Smith [SMTP:kevin@ascend.com] >Sent: Thursday, May 22, 1997 9:21 PM >To: Matt Holdrege >Cc: ascend-users@bungi.com >Subject: Re: (ASCEND) 56k and CT1 > >At 05:58 PM 5/22/97 -0700, Matt Holdrege wrote: >>At 08:15 PM 5/22/97 -0400, Matthew S. Dwyer wrote: >>> >>>Hello, >>> >>>We are planning to order a number of Series56 modems for evaluation >>>on our CT1 circuits. Given that we have seen lower performance on CT1 >>>compared to PRI with 28.8k, what sort of performance should we >>>expect with 56k? Can these modems adjust for the bandwidth limitations >>>per channel on CT1? (200-3800hz) >> >>With channelized T1, you must have the telco provision trunk-side rather >>than line-side to get the higher speeds. It's theoretically possible to get >>56K on a trunk-side T1, but in practice that may be iffy. > >According to USR/Rockwell: > >As far as T1 lines are concerned, both Rockwell and USR claim to have >been able to avoid signal loss in T1 lines by detecting what they call >"digital-padding" in T1 switch. This digital pad can cause the modem signal >to drop as much as 6db. Once they detect this digital pad during the first >stage of negotiation, they boost their transmit level by 6db. They also have >algorithm to compensate for robbed-bit signaling. > >Kevin Smith Updated Service and Support >Ascend Communications Resources are now at: > <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> >++ Ascend Users Mailing List ++ >To unsubscribe: send unsubscribe to ascend-users-request@bungi.com >To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> >or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Pierre-Yves Kerembellec <Pierre-Yves.Kerembellec@vtcom.fr> Date: Sat, 24 May 1997 00:25:55 +0200 Subject: Re[2]: (ASCEND) Cannot get 5.0A to work Le [Fri, 23 May 1997 13:32:15 -0700], Kevin Smith ecrivait : > >Hi ! > > > >I already have an open ticket with Ascend support regarding this > >particular issue : this is a problem in Ascend software. > >My ticket # is 106492 ... > >This problem is reported as TR 2140 > Just FYI, TR#2140 *seems* to be fixed in 5.0Ap8 -despite not being in the > release notes. I'll try to get more details on who tested it, but > may be worth a try... Unfortunatly, I tested p8 and not succeed in 'callbacking' my Cisco And MAX4000 software was _NOT_ released in p9 ... still waiting for p10 ... :-) Regards, Pierre-Yves =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50 VTCOM Fax # +33 1 46 12 67 00 40, rue Gabriel Crie E-mail pyk@vtcom.fr 92245 Malakoff Cedex, France Systemes et Reseaux =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: cclemmer@baynetworks.com (Charlie Clemmer) Date: Fri, 23 May 1997 18:17:12 -0500 Subject: Re: (ASCEND) Analog Multilink PPP and RAS At 11:59 AM 5/23/97 -0700, Kevin Smith wrote... >>We support combinations with different link types, either async or sync. > >Interesting....just Bay/Bay, or have you done this with other Vendors? > >p.s. do you guys have a user-mailing-list too ? See John Carlson's notes on the same subject. I don't believe it to be just Bay/Bay. We don't have a mailing list, at least that I'm aware of, but there is an internet newsgroup, comp.dcom.sys.wellfleet. Charlie Clemmer Bay Networks ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Josh Bailey <josh@actrix.gen.nz> Date: Sat, 24 May 1997 11:31:45 +1200 (NZST) Subject: (ASCEND) thank you, Ascend Hey all, In the past you've seen some pretty vocal messages from me. In response, our distributer got an Ascend engineer over here to examine our issues first-hand. We were able to demonstrate our performance problems to him - the only change he suggested we make to our configuration was to tweak a PPP parameter by one second to help an occasional PAP problem. He commented that our installation was very well set up and managed (we have more than 50 M4000E's spread nationally and maintained via some in-house developed software using Ascend's Machine Interface Format). Thank you Ascend for acknowledging our very genuine issues and getting on to them to sort them out, and thanks to Asnet NZ for responding to our needs so efficiently. One comparitively small gripe - it's a shame we had to push so hard to get some of these issues acknowledged - and we've lost customers tired of hearing that magic initialisation strings will fix everything. Ascend, you're making the right support moves now, but next time PLEASE may we have some assistance a little faster. - -- Josh Bailey (<A HREF="mailto:joshb@xtra.co.nz">mailto:joshb@xtra.co.nz</A>) Internet Network Specialist Voice (DDI): +64-9-355-5923 Telecom Internet Services Voice (Mob): +64-25-514-899 Extension: 93423 Fax: +64-9-355-5924 PO Box 92028, Auckland, NZ Pager: +64-26-114-448 ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: James Fischer <jfischer@supercollider.com> Date: Fri, 23 May 1997 19:45:11 +0000 Subject: Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS Todd Vierling claimed: >I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT* >report the connect rate the user sees (the K56flex rate) in RADIUS >accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most >common transmit rate for K56flex) or 33600. Now, I'd consider this a TR, >but Ascend techs are telling me to raise it as a feature enhancement. > >Show of hands: Who considers this a TR? Who considers this a FE? If (and only if) the description above is accurate, it is a Hands Down Winner!! TR all the way!! :-) Given the level of (understandable) confusion that WILL exist in the mind of the users, I expect that there will be many calls to our 800-number support staff asking: "OK, I have a 56K modem, you say that you support 56K, so why can't I get a 56K connection?" Now, since these calls cost us money AND are damaging to customer good-will, we need to be able to: A) Be proactive (just like we could before 56K) and run scans through the radius data to find users who are not connecting at "decent speeds", so that we can suggest that they contact their telco about line quality BEFORE they call us to complain. B) Get accurate info from the Maxen on this issue, just as we could before 56K. Therefore, THIS IS A BUG, since the "upgrade" to 56K should not "break" a fairly basic feature that has been available from Ascend on all prior products. It should be obvious even to the casual observer that "connection speed" is going to once again be a hot issue, just as it was when 28.8kbps was first rolled out. It matters not what the throughput is, and you can talk until you are blue in the face about "overall performance", the bottom line is that the user/customer will expect to connect "at 56K". If an ISP was to charge "extra" for 56Kbps service, and the user claimed that he was unable to connect at anything above 33.6K, how would the matter be addressed, debugged, and resolved without such features? It looks like 56K is going to be "a pain" until this bug is fixed (if the report above is accurate), since Maxen simply will not know/tell what is going on. Consciousness: that annoying time between naps james fischer jfischer@supercollider.com ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: cclemmer@baynetworks.com (Charlie Clemmer) Date: Fri, 23 May 1997 18:55:44 -0500 Subject: Re: (ASCEND) Analog Multilink PPP Matt, As Jeff pointed out, this thread is going to far off topic. The important aspect this that async MP is support now in the "i" branch and will be released in production code sometime soon. I'll be glad to move this thread offline if that's more appropriate. Charlie Clemmer At 11:47 AM 5/23/97 -0700, Matt Holdrege wrote... >If you read my email below, it says that we may not have checked the ED on >analog calls. That can be called a bug if you are a purist, or just an >unsupported feature of MP. But as I said below, we do support it in 5.0Aix. > >Code doesn't just fall out of the sky. Someone has to write the lines of >code necessary to check incoming calls for ED and an MP header. Since >Ascend code is so feature rich, we do all sorts of checking on inbound >calls. We do far more than standards indicate and far more than other >vendors support. This is because we are driven by our customers network >design ideas. Our customers in the past have never asked us to support >analog MP. Now they are asking for it and now we have added the code to >check for MP and ED on types other than just ISDN data calls. > > >At 01:35 PM 5/23/97 -0500, Charlie Clemmer wrote: >> >>Matt, >> >>What you describe is what I understood MP to be. The question that comes up >>because of this then, is why would Livingston and maybe Ascend not support >>MP over all types of links? >> >>I keep seeing mixed responses as to whether the Ascend box does support MP >>over any kind of link, while I saw a response from a Livingston guy who >>indicated that their box only supports MP on ISDN calls. >> >>Knowing that MP should not be related to the physical call type, why would >>this limitation exist? >> >>Can we get a definitive answer from Ascend as to whether or not the Ascend >>boxes share this limitation? Again, I would expect that it is supported, >>for the reasons you mentioned. >> >>Charlie Clemmer >> >>At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote: >>>Folks, MP operates at a layer above the physical connection or media. You >>>can combine any types of calls in any increment. I've seen NT call the Max >>>with one analog call bundled with one ISDN call. Or two analog calls >>>together. I've seen the Max call a Bay router with 23 channels of MP. >>> >>>All MP does is take (in one case) the endpoint discriminator and compare it >>>with any other call it has, be it analog or MP or whatever. If there is a >>>match, it bundles the two calls together. I haven't tested it on the Max >>>5.0ap branch, but by the reports here I might assume that the Max code >>>didn't check ED on analog calls. But the reports say that it does in the i >>>branch. >> >> >Matt Holdrege - <A HREF="http://www.ascend.com">http://www.ascend.com</A> - matt@ascend.com >++ Ascend Users Mailing List ++ >To unsubscribe: send unsubscribe to ascend-users-request@bungi.com >To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> >or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> > ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: cclemmer@baynetworks.com (Charlie Clemmer) Date: Fri, 23 May 1997 19:06:33 -0500 Subject: Re: (ASCEND) Analog Multilink PPP Jeff, I have no problem splitting this into two threads. In fact, I'll be happy to take this conversation offline if that's more appropriate. I'm not sure how many people are following the dialer conversation vs. the other. I still don't necessarily understand the comment regarding the inability to use different vendors modems for an analog MP connection. The MP process is the process that worries about sequencing and fragmentation/reassembly, correct? So if one link in the bundle is slower for whatever reason, shouldn't the MP process deal with this? If I'm missing something here, please correct me. Charlie Clemmer At 12:34 PM 5/23/97 -0700, Jeff_Powell@ascend.com wrote... > >This thread has wandered, so I hope we can split it in two. > >When I said "I'm not aware of any other....blah blah, etc. etc." I was >referring to PC based dialers [the title of the thread is "Analog Multilink >PPP and RAS" after all. So let's divide this into two discussions: > >1. Asynch MPP [Specifically Windows based PC's dialing into an access >router/server with more than one modem] >2. All other MP/MPP types [UNIX machines, ISDN TA's/routers, router to >router, etc. etc. etc.] > >Sound fair? > >Now, as to #1. Microsoft release multiline RAS in NT 4.0 [there's a patch >for Win 95 as well, part of the ISDN connectivity kit]. Choosing "multiple >lines" in the "modem properties" dialog in RAS [dial up networking] allows >you to use two modems to dial into a RAS server. > >The AMPP specs don't care about what kind of modems, serial ports, etc. >etc. that you have, but let's think it through for a minute. The hardest >job an MP server has is to synch up the incoming calls. This is easy in >the digital world, but in the analog world, it gets quite tricky. Ascend >has had support for Analog MP in the MAX for awhile, but the only clients >that could do it were UNIX machines and some remote access servers. When >Microsoft came out with its offering, it didn't work with the Max. >Basically there was too much slop on the client side of things and the Max >couldn't compensate [a Pentium box running NT4.0 is still not a REAL >workstation...]. Since this was a new offering from Microsoft, the >reworking of MP code in the Max to make it more aggressive [and lenient at >the same time...] in synching up the calls was put in an "i" release so it >could get beat up in the real world before going prime-time. > >As to the client side, the closer in functionality the serial ports and the >modems are, the better it works. The phone lines are not as important. >I've tested this with one "normal" POTS line and one going through a POTS >jack on a P25. On the line going through the P25, I would get 33.6k and on >the POTS line I would get 31.2k and the lines synched up just fine. The >key was that I used a third party 115k serial board [as Com2 and 3] and two >Courier V.Everything modems [same firmware, etc.]. Any attempts to get a >session with two different modems or different serial ports failed. > >Reports from the field have been positive so far, both in the support for >Multiline RAS and that other aspects of MP didn't break, so we'll probably >see this in 5.1xxxx. > >Anyway, I hope that clears that up... > > > > > >cclemmer@baynetworks.com on 05/23/97 11:35:46 AM > >To: matt@ascend.com >cc: Ascend-users@bungi.com (bcc: Jeff Powell/Ascend/US) >Subject: Re: (ASCEND) Analog Multilink PPP and RAS > > > > > >Matt, >What you describe is what I understood MP to be. The question that comes up >because of this then, is why would Livingston and maybe Ascend not support >MP over all types of links? >I keep seeing mixed responses as to whether the Ascend box does support MP >over any kind of link, while I saw a response from a Livingston guy who >indicated that their box only supports MP on ISDN calls. >Knowing that MP should not be related to the physical call type, why would >this limitation exist? >Can we get a definitive answer from Ascend as to whether or not the Ascend >boxes share this limitation? Again, I would expect that it is supported, >for the reasons you mentioned. >Charlie Clemmer >At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote: >>Folks, MP operates at a layer above the physical connection or media. You >>can combine any types of calls in any increment. I've seen NT call the Max >>with one analog call bundled with one ISDN call. Or two analog calls >>together. I've seen the Max call a Bay router with 23 channels of MP. >> >>All MP does is take (in one case) the endpoint discriminator and compare >it >>with any other call it has, be it analog or MP or whatever. If there is a >>match, it bundles the two calls together. I haven't tested it on the Max >>5.0ap branch, but by the reports here I might assume that the Max code >>didn't check ED on analog calls. But the reports say that it does in the i >>branch. >++ Ascend Users Mailing List ++ >To unsubscribe: send unsubscribe to ascend-users-request@bungi.com >To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> >or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> > > > > > > > ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: German Martinez <German.Martinez@globalone.net> Date: Fri, 23 May 1997 19:21:15 -0500 Subject: Re: (ASCEND) PPP over Clear Channel T-1 into Max 4000? Ascend wrote: > Can this be done? Yes, you can do it. You can run ppp over a clear channel. When we connect here in Colombia cust going to Global IP backbone, if the cust has Cisco Router we use HDLC (cisco) and when the cust has another router Regards > ++ Ascend Users Mailing List ++ > To unsubscribe: send unsubscribe to ascend-users-request@bungi.com > To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> > or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> - ------------------------------------------------------------------- \_/ @ @ ,-------------vvvV--<o o>--Vvvvv---------------------. | V^V | | German A. Martinez Ramirez | | Network Engineer | | German.Martinez@globalone.net | | Phone +571-621-0177 | | Fax +571-618-0712 | | Mobile +573-232-3728 | | | | "Out of order there is a chaos and | | out of chaos there is an order" | `----------------------------------------------------' ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Jeff_Powell@ascend.com Date: Fri, 23 May 1997 17:32:22 -0700 Subject: Re: (ASCEND) AMPPP>Why same modem? Ah, nothing like a change of subject! As to "why the same modem" I think it is a peculiarity of NT. If the two channels don't bond in a reasonably synchronous way, it doesn't work. Since different modems will take different amounts of time to synch, it may or may not work unless the modems are very, very similar. You're right, it has nothing to do with AMPPP per se, I see it as an NT issue. cclemmer @ BayNetworks.COM on 05/23/97 05:06:33 PM To: Jeff Powell/Ascend/US cc: Ascend-Users @ Bungi.Com Subject: Re: (ASCEND) Analog Multilink PPP Jeff, I have no problem splitting this into two threads. In fact, I'll be happy to take this conversation offline if that's more appropriate. I'm not sure how many people are following the dialer conversation vs. the other. I still don't necessarily understand the comment regarding the inability to use different vendors modems for an analog MP connection. The MP process is the process that worries about sequencing and fragmentation/reassembly, correct? So if one link in the bundle is slower for whatever reason, shouldn't the MP process deal with this? If I'm missing something here, please correct me. Charlie Clemmer At 12:34 PM 5/23/97 -0700, Jeff_Powell@ascend.com wrote... > >This thread has wandered, so I hope we can split it in two. > >When I said "I'm not aware of any other....blah blah, etc. etc." I was >referring to PC based dialers [the title of the thread is "Analog Multilink >PPP and RAS" after all. So let's divide this into two discussions: > >1. Asynch MPP [Specifically Windows based PC's dialing into an access >router/server with more than one modem] >2. All other MP/MPP types [UNIX machines, ISDN TA's/routers, router to >router, etc. etc. etc.] > >Sound fair? > >Now, as to #1. Microsoft release multiline RAS in NT 4.0 [there's a patch >for Win 95 as well, part of the ISDN connectivity kit]. Choosing "multiple >lines" in the "modem properties" dialog in RAS [dial up networking] allows >you to use two modems to dial into a RAS server. > >The AMPP specs don't care about what kind of modems, serial ports, etc. >etc. that you have, but let's think it through for a minute. The hardest >job an MP server has is to synch up the incoming calls. This is easy in >the digital world, but in the analog world, it gets quite tricky. Ascend >has had support for Analog MP in the MAX for awhile, but the only clients >that could do it were UNIX machines and some remote access servers. When >Microsoft came out with its offering, it didn't work with the Max. >Basically there was too much slop on the client side of things and the Max >couldn't compensate [a Pentium box running NT4.0 is still not a REAL >workstation...]. Since this was a new offering from Microsoft, the >reworking of MP code in the Max to make it more aggressive [and lenient at >the same time...] in synching up the calls was put in an "i" release so it >could get beat up in the real world before going prime-time. > >As to the client side, the closer in functionality the serial ports and the >modems are, the better it works. The phone lines are not as important. >I've tested this with one "normal" POTS line and one going through a POTS >jack on a P25. On the line going through the P25, I would get 33.6k and on >the POTS line I would get 31.2k and the lines synched up just fine. The >key was that I used a third party 115k serial board [as Com2 and 3] and two >Courier V.Everything modems [same firmware, etc.]. Any attempts to get a >session with two different modems or different serial ports failed. > >Reports from the field have been positive so far, both in the support for >Multiline RAS and that other aspects of MP didn't break, so we'll probably >see this in 5.1xxxx. > >Anyway, I hope that clears that up... > > > > > >cclemmer@baynetworks.com on 05/23/97 11:35:46 AM > >To: matt@ascend.com >cc: Ascend-users@bungi.com (bcc: Jeff Powell/Ascend/US) >Subject: Re: (ASCEND) Analog Multilink PPP and RAS > > > > > >Matt, >What you describe is what I understood MP to be. The question that comes up >because of this then, is why would Livingston and maybe Ascend not support >MP over all types of links? >I keep seeing mixed responses as to whether the Ascend box does support MP >over any kind of link, while I saw a response from a Livingston guy who >indicated that their box only supports MP on ISDN calls. >Knowing that MP should not be related to the physical call type, why would >this limitation exist? >Can we get a definitive answer from Ascend as to whether or not the Ascend >boxes share this limitation? Again, I would expect that it is supported, >for the reasons you mentioned. >Charlie Clemmer >At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote: >>Folks, MP operates at a layer above the physical connection or media. You >>can combine any types of calls in any increment. I've seen NT call the Max >>with one analog call bundled with one ISDN call. Or two analog calls >>together. I've seen the Max call a Bay router with 23 channels of MP. >> >>All MP does is take (in one case) the endpoint discriminator and compare >it >>with any other call it has, be it analog or MP or whatever. If there is a >>match, it bundles the two calls together. I haven't tested it on the Max >>5.0ap branch, but by the reports here I might assume that the Max code >>didn't check ED on analog calls. But the reports say that it does in the i >>branch. >++ Ascend Users Mailing List ++ >To unsubscribe: send unsubscribe to ascend-users-request@bungi.com >To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> >or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> > > > > > > > ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Kevin Smith <kevin@ascend.com> Date: Fri, 23 May 1997 18:15:54 -0700 Subject: (ASCEND) 5.0Ap9 only for MAX2000/BRI 5.0Ap9 has been given to support. This release contains the following: This release introduces the MAX 2000 T1 software load with BRI support. - --Lew Kevin Smith Updated Service and Support Ascend Communications Resources are now at: <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Kevin Smith <kevin@ascend.com> Date: Fri, 23 May 1997 18:30:29 -0700 Subject: Re: (ASCEND) 5.0Ap9 only for MAX2000/BRI At 06:15 PM 5/23/97 -0700, Kevin Smith wrote: >5.0Ap9 has been given to support. This release contains the following: > >This release introduces the MAX 2000 T1 software load with BRI support. Which all along I've been saying is not possible...I guess we decided it was worth it...BRI slot cards are now supported in the MAX2000 along with DM-12 and DM56-12 cards.... Kevin Smith Updated Service and Support Ascend Communications Resources are now at: <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Craig Salmond <salmond@unix.cde.com> Date: Fri, 23 May 1997 20:40:41 -0400 (EDT) Subject: (ASCEND) CT1 Not Answering Call When I place a call to the Max, I get a "c" in the status window, but no carrier tone. The phone company says it is a problem on my end, but I have tried each of the Rob Ctl options... I do have each Channel Slot set to 3 (which is the first modem card) and the call type as switched. TIA =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Craig Salmond salmond@mail.cde.com Craig's DATA Exchange! <A HREF="http://www.cde.com">http://www.cde.com</A> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Shipping Address (FLA) 735-CDE1 Sales Billing Address Craig's DATA Exchange! (FLA) 483-2482 Home Craig's DATA Exchange! 18826 U.S. HWY 441 (FLA) 735-9511 FAX P.O. Box 1401 Mt. Dora, FL 32757 (FLA) 735-INET DIAL-UP Mt. Dora, FL 32757 (FLA) 742-1515 Digital "Lake County's Internet Authority" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Kevin Smith <kevin@ascend.com> Date: Fri, 23 May 1997 19:12:04 -0700 Subject: Re: (ASCEND) CT1 Not Answering Call At 08:40 PM 5/23/97 -0400, Craig Salmond wrote: > When I place a call to the Max, I get a "c" in the status window, >but no carrier tone. The phone company says it is a problem on my end, but >I have tried each of the Rob Ctl options... I do have each Channel Slot >set to 3 (which is the first modem card) and the call type as switched. You don't say anything about how the T1 is provisioned....signaling setup (wink/loops-start/ground)....answer supervision... ? Kevin Smith Updated Service and Support Ascend Communications Resources are now at: <A HREF="http://www.ascend.com/service">http://www.ascend.com/service</A> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ From: Brantley Jones <bjones@cte.net> Date: Fri, 23 May 1997 22:22:45 -0500 Subject: Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS At 07:45 PM 5/23/97 +0000, you wrote: > Todd Vierling claimed: > >>I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT* >>report the connect rate the user sees (the K56flex rate) in RADIUS >>accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most >>common transmit rate for K56flex) or 33600. Now, I'd consider this a TR, >>but Ascend techs are telling me to raise it as a feature enhancement. >> >>Show of hands: Who considers this a TR? Who considers this a FE? Definitely a bug. How are we supposed to get an idea of how many of our customers are actually GETTING better than 33.6 speeds???? This should be fixed immediately. It is definitely a BUG! Brantley ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ------------------------------ End of ascend-users-digest V96 #633 *********************************** ++ Ascend Users Mailing List Digest++ To unsubscribe: "echo unsubscribe | mail ascend-users-digest-request@bungi.com" To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00598.html">Re: (ASCEND) AMPPP>Why same modem?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00597.html">(ASCEND) Problem with DOV calls on a MAX TnT</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00641.html">Re: (ASCEND) Problem with DOV calls on a MAX TnT</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00599.html">(ASCEND) P75 w/Ai10: DHCP Server DNS assignment ?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="mail2.html#00596"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd23.html#00596"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>