Conference irocz::common_brouters

    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

hi,

Well, we thought that we had solved the problem by defining separate
incoming destinations without leading zeros but the problem persists.
    
I would very much appreciate help how to set up a decrouter 90 EI to accept
incoming isdn calls. 
    
Here is  part of the configuration:

t 6

list isdn

ada-isdn  031586392
ada-isdn2 031586393
IN-NYCOMED 84467080  (leading zero has been stripped off)
NYCOMED   084467080

net 2

local net addr name   ada-isdn
local net             031586392
local net sub =
max frame size        2048
out call addr timeout  15
retries                2
switch                ETSI
DNO                   031586392
DN1                   031586393
TEI                   automatic
PS1 detect enabled


net 3

base net 2
destination name NYCOMED
inbound dest     IN-NYCOMED
outbound calls   allowed
inbound calls    allowed
idle timer       10
selftest delay timer  150
send line id          yes


I ran a ISDN event trace for an incoming call and the calling number was
84467080 (i.e. IN-NYCOMED) and still the call (a ping) was not accepted.

There is no problems to set up outgoing calls - the customer can ping to
destination NYCOMED.

What needs to be changed here?

thanks,

h�kan

    

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

    Hi,
    
    This is what the trace shows (is it possible to get the trace to file?)
    
    GW083  lid is none
    GW087  ISDN inb addr "31687715" sbaddr () nt 2 ISDN/0
    GW080 no usbl match dial addr "31687715::"
    GW080 no usbl match dial addr ":"
    
    What does the "::" stand for? 
    
    By the way, it did work on the first try but not on the second and
    following tries.
    
    /h�kan

    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.

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

    hi,
    
    called number is 315-xxxxx, calling number is 316 -xxxx and we have set
    an inbound destination = 316 -xxxxx in order to filter incoming calls
    to the correct PPP address.
    
    The first time when it worked ok, the GW 079 message was " match dial
    addr 316-xxxx:" to  .. PPP , i.e. only one :
    
    /h�kan

    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

    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. 

    Thanks Tim,
    
    Where can I copy the fix from?
    In the meantime I'll enable ANY_INBOUND on one of the circuits.
    
    /h�kan

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

Hi!

Is the fix included in V2.0-3?

Thanks.

Pedro
[Posted by WWW Notes gateway]

    
>Is the fix included in V2.0-3?
    
    No.
    
    It will be in the next scheduled maintenance release (coming soon).