| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 804.1 | | MARVIN::CLEVELAND | | Tue Mar 18 1997 09:53 | 5 |
| Yes, there is. Set the 'inbound destination' of your dial circuit to
an address with the leading zero stripped off. That should allow two
way calling from the same dial circuit.
Tim
|
| 804.2 | incoming isdn calls rejected | STKAI1::KACK | | Fri Mar 21 1997 12:45 | 59 |
| 804.3 | | MARVIN::CLEVELAND | | Fri Mar 21 1997 13:59 | 14 |
| I'd need to see a trace of events to determine what is going on...
can you do the following:
talk 6/eve
set time uptime
nodis sub all all
disp sub isdn all
disp sub gw all
nodis eve isdn.021
nodis eve gw.043
restart the box, and then get a event trace when the inbound call comes
in and is rejected....
|
| 804.4 | trace | STKAI1::KACK | | Mon Mar 24 1997 07:51 | 15 |
| 804.5 | | MARVIN::CLEVELAND | | Mon Mar 24 1997 08:13 | 10 |
| You are receiving a call from 316-87715. Unless that is a typo, you
won't match your dial circuit, which has a inb destination of
315-xxxxx.
the ":" is a field seperator between the address and subaddress.
The second GW.080 message indicates that it did not find an 'any
inbound' dial circuit to accept the call.
There is no direct way to log to a file; although often your terminal
emulator can do it.
|
| 804.6 | you can do it using dtf | MARVIN::HART | Tony Hart, InterNetworking Prod. Eng. Group | Mon Mar 24 1997 08:38 | 20 |
| > This is what the trace shows (is it possible to get the trace to file?)
You can do it indirectly using dtf, try ...
# dtf -l 16.36.16.121:"els event gw;isdn" els_trace.dat
and you can read the file later using
# dtf -a els_trace.dat
or if you don't mind not seeing the events on the screen at the
same time you can record them directly to a text file using...
# dtf -l 16.36.16.121:"els event gw;isdn" -o els_trace.txt
There are various filters you can supply on the dtf command line to
further limit the kinds of events traced, check out the dtf
documentation.
See the DTF_KITS keyword for the location of the latest kits.
|
| 804.7 | | STKAI1::KACK | | Mon Mar 24 1997 08:41 | 10 |
| 804.8 | | MARVIN::CLEVELAND | | Wed Mar 26 1997 11:46 | 6 |
| This appears to be a bug in that the string used for incoming call
matching is not properly zero-terminated. So if a second colon gets in
the buffer, just at the end of the inbound CLID, you would see exactly
these symptoms. I am working on a fix...
Tim
|
| 804.9 | | MARVIN::CLEVELAND | | Thu Mar 27 1997 07:43 | 7 |
| I have a fix available if needed....
There are workarounds as well, I suspect. I found in my testing that
LID was not affected by this bug. So if can use LID (ie, it is an all
Routeabout network) that may work around the problem.
Another possible solution is to enable ANY_INBOUND on the dial circuit.
|
| 804.10 | Where do I find the fix? | STKAI1::KACK | | Tue Apr 01 1997 06:42 | 6 |
| 804.11 | | MARVIN::CLEVELAND | | Tue Apr 01 1997 08:14 | 7 |
|
> -< Where do I find the fix? >-
Answered via mail. For anyone else experiencing this problem, you
should probably raise an IPMT/etc to get the fix.
Tim
|
| 804.12 | fix ? | NNTPD::"paiva@mail.dec.com" | Pedro PAIVA | Tue Jun 03 1997 09:58 | 8 |
| Hi!
Is the fix included in V2.0-3?
Thanks.
Pedro
[Posted by WWW Notes gateway]
|
| 804.13 | | EDWIN::TAC | | Tue Jun 03 1997 13:41 | 6 |
|
>Is the fix included in V2.0-3?
No.
It will be in the next scheduled maintenance release (coming soon).
|