From: Tom Lijnse (Tom.Lijnse@globalknowledge.nl)
Date: Thu Jun 02 2005 - 04:02:19 GMT-3
Hi all,
There's on thing I'd like to add to this discussion that may help you
troubleshoot ISDN callback.
ISDN callback is really all about the timing.
When using PPP callback everything is nicely negotiated. The client and
server both know what's going on.
When using ISDN D-channel callback the 'server' simply does rejects the
incoming call based on calling-line-id and then tries to call back. The
client does not really understand what's going on and will typically try
to dial again. You could run into issues where the callback call fails
because all channels are in use (though in my experience that mainly
happens when you try to combine this with multilink). So basically when
doing ISDN callback if you want smooth operation you may have to tune
some of the timers to ensure that the server calls back at the right
moment.
Let's give you an example. I have the following basic configuration:
On the 'client':
R4#sh run int bri 1/0
Building configuration...
Current configuration : 189 bytes
!
interface BRI1/0
ip address 172.16.45.4 255.255.255.0
encapsulation ppp
dialer map ip 172.16.45.5 name R5 65
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap
end
and on the 'server':
R5#sh run int bri 1/0
Building configuration...
Current configuration : 214 bytes
!
interface BRI1/0
ip address 172.16.45.5 255.255.255.0
encapsulation ppp
dialer map ip 172.16.45.4 name R4 66
dialer-group 1
isdn switch-type basic-net3
isdn caller 66 callback
ppp authentication chap
end
Now let's ping from the client while 'debug isdn q931' is turned on:
R4#ping 172.16.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.45.5, timeout is 2 seconds:
*Mar 17 00:49:46.064: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
0x07
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x83
Called Party Number i = 0x80, '65'
Plan:Unknown, Type:Unknown
*Mar 17 00:49:46.104: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref =
0x87
Channel ID i = 0x89
*Mar 17 00:49:46.120: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref =
0x87..
*Mar 17 00:49:50.252: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8 callref
= 0x87
Cause i = 0x8095 - Call rejected
Facility i = 0x91A11202011D020122300AA1053003020100820101
- ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
*Mar 17 00:49:50.260: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
0x07
Cause i = 0x8095 - Call rejected
*Mar 17 00:49:50.288: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
callref = 0x87.
*Mar 17 00:49:52.060: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
0x08
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x83
Called Party Number i = 0x80, '65'
Plan:Unknown, Type:Unknown
*Mar 17 00:49:52.100: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref =
0x88
Channel ID i = 0x89
*Mar 17 00:49:52.120: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref =
0x88..
Success rate is 0 percent (0/5)
R4#
*Mar 17 00:49:56.248: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8 callref
= 0x88
Cause i = 0x8095 - Call rejected
Facility i = 0x91A11202011E020122300AA1053003020100820101
- ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
*Mar 17 00:49:56.256: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
0x08
Cause i = 0x8095 - Call rejected
*Mar 17 00:49:56.284: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
callref = 0x88
*Mar 17 00:50:01.352: ISDN BR1/0 Q931: RX <- SETUP pd = 8 callref =
0x01
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Calling Party Number i = 0x0183, '65'
Plan:ISDN, Type:Unknown
Called Party Number i = 0x81, '66'
Plan:ISDN, Type:Unknown
*Mar 17 00:50:01.356: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state
to up
*Mar 17 00:50:01.360: ISDN BR1/0 Q931: TX -> CALL_PROC pd = 8 callref =
0x81
Channel ID i = 0x89
*Mar 17 00:50:01.380: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref =
0x81
*Mar 17 00:50:01.428: ISDN BR1/0 Q931: RX <- CONNECT_ACK pd = 8 callref
= 0x01
Channel ID i = 0x89
*Mar 17 00:50:02.532: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI1/0:1, changed state to up
R4#
*Mar 17 00:50:07.360: %ISDN-6-CONNECT: Interface BRI1/0:1 is now
connected to 65 R5
As you can see the call eventually connects, but it takes about 15
seconds before the callback call comes in (RX <- SETUP). It does work
though eventually. You can also see that the 'client' tried to call out
at least two times (count the occurrences of TX -> SETUP).
Now let's try to improve this. To start with I'd like to put in a bit of
a disclaimer. I have seen the behavior of the timers on ISDN change in
different IOS versions and the documentation isn't really very clear on
them, so don't assume that the values in this example will always work
for you. You may have to experiment a bit. But here we go:
There's one timer that defaults to 15 seconds, the re-enable timer. So
chances are that tuning this timer on the server side will improve the
time between the incoming call and the callback. So let's set this timer
to 1 second on the server side:
R5(config)#int bri 1/0
R5(config-if)#dialer enable-timeout 1
And try our ping from the client again:
R4#ping 172.16.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.45.5, timeout is 2 seconds:
*Mar 17 01:02:38.472: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
0x0C
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x83
Called Party Number i = 0x80, '65'
Plan:Unknown, Type:Unknown
*Mar 17 01:02:38.512: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref =
0x8C
Channel ID i = 0x89
*Mar 17 01:02:38.532: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref =
0x8C.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/32/32 ms
R4#
*Mar 17 01:02:39.760: ISDN BR1/0 Q931: RX <- SETUP pd = 8 callref =
0x0D
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x8A
Calling Party Number i = 0x0183, '65'
Plan:ISDN, Type:Unknown
Called Party Number i = 0x81, '66'
Plan:ISDN, Type:Unknown
*Mar 17 01:02:39.768: %LINK-3-UPDOWN: Interface BRI1/0:2, changed state
to up
*Mar 17 01:02:39.772: ISDN BR1/0 Q931: TX -> CALL_PROC pd = 8 callref =
0x8D
Channel ID i = 0x8A
*Mar 17 01:02:39.788: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref =
0x8D
*Mar 17 01:02:39.836: ISDN BR1/0 Q931: RX <- CONNECT_ACK pd = 8 callref
= 0x0D
Channel ID i = 0x8A
*Mar 17 01:02:40.940: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI1/0:2, changed state to up
*Mar 17 01:02:42.664: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8 callref
= 0x8C
Cause i = 0x8095 - Call rejected
Facility i = 0x91A112020126020122300AA1053003020100820101
- ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
*Mar 17 01:02:42.668: %ISDN-6-CONNECT: Interface BRI1/0:2 is now
connected to 65 R5
*Mar 17 01:02:42.672: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
0x0C
Cause i = 0x8095 - Call rejected
*Mar 17 01:02:42.700: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
callref = 0x8C
As you can see see we now only have one incoming and one outgoing call.
Actually the incoming call happens before the original reject even
reaches the client.
So concluding: When your ISDN callback does not work as expected, look
at the debug isdn q931 results and see if you can spot the problem there
and then change timers accordingly.
I hope this helps you troubleshooting ISDN d-channel callback.
Regards,
Tom Lijnse
CCIE #11031
Global Knowledge
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Lee
Sent: donderdag 2 juni 2005 5:22
To: 'john matijevic'; 'mani poopal'; 'ccie2be'; 'Chuck South'; Cisco
certification
Subject: Re: Re Re: ISDN callback/dialer load-threshold.
Andy,
I have exactly the same problem as yours.
I can't configure isdn callback neither over a dialer profile nor over a
BRI.
The routers negotiates the calback (matching caller iD), they disconect,
the callback server attempt to call back, but the call never establish.
I'm still stuck on this.
Brian.
----- Original Message -----
From: "Andy" <trung@vnsystem.net>
To: "'john matijevic'" <matijevi@bellsouth.net>; "'mani poopal'"
<mani_ccie@yahoo.com>; "'ccie2be'" <ccie2be@nyc.rr.com>; "'Chuck South'"
<cciesouth@bellsouth.net>; <ccielab@groupstudy.com>
Sent: Tuesday, May 31, 2005 12:24 AM
Subject: Re Re: ISDN callback/dialer load-threshold.
> Hi John,
> i've tried to configure dialer profile for callback on server side,
not
> with ppp cmd but "dialer caller xxx callback" instead. Unfortunately
it
> did not work.
> The debug dialer said the client side attempt to call, the server side
> disconnect and starting to callback but... that's all. The isdn bri
did
> not come up.
> So what's the problem here ?
>
> TIA,
>
> Andy.
>
> ----- Original Message -----
> From: "john matijevic" <matijevi@bellsouth.net>
> To: "'john matijevic'" <matijevi@bellsouth.net>; "'mani poopal'"
> <mani_ccie@yahoo.com>; "'ccie2be'" <ccie2be@nyc.rr.com>; "'Chuck
South'"
> <cciesouth@bellsouth.net>; <ccielab@groupstudy.com>
> Sent: Saturday, July 31, 2004 11:02 PM
> Subject: RE: Re: ISDN callback/dialer load-threshold.
>
>
>> Hello again Mani,
>> I have the output, I configured dialer profile on the client:
>> r1#deb dialer
>> Dial on demand events debugging is on
>> r1#ping 172.16.12.2
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
>> ....
>> Success rate is 0 percent (0/5)
>> r1#
>> 01:40:43: BR0 DDR: rotor dialout [priority]
>> 01:40:43: BR0 DDR: Dialing cause ip (s=172.16.12.1, d=172.16.12.2)
>> 01:40:43: BR0 DDR: Attempting to dial 5552002
>> 01:40:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
>> 01:40:43: BR0:1: interface must be fifo queue, force fifo
>> 01:40:43: %DIALER-6-BIND: Interface BR0:1 bound to profile Di0
>> 01:40:43: BR0:1 DDR: Callback negotiated - waiting for server
disconnect
>> 01:40:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
>> 01:40:43: DDR: Callback client for r2 5552002 created
>> 01:40:43: BR0 DDR: has total 0 call(s), dial_out 0, dial_in 0
>> 01:40:43: BR0:1 DDR: disconnecting call
>> 01:40:43: %DIALER-6-UNBIND: Interface BR0:1 unbound from profile Di0
>> r1#
>> 01:40:58: BR0:1: interface must be fifo queue, force fifo
>> 01:40:58: %DIALER-6-BIND: Interface BR0:1 bound to profile Di0
>> 01:40:58: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
>> r1#
>> 01:40:59: BR0:1 DDR: dialer protocol up
>> 01:40:59: BR0:1 DDR: Callback received from r2 5552002
>> 01:40:59: DDR: Freeing callback to r2 5552002
>> r1#
>> 01:41:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
>> changed sta
>> to up
>> r1#sh run int d0
>> Building configuration...
>>
>> Current configuration : 206 bytes
>> !
>> interface Dialer0
>> ip address 172.16.12.1 255.255.255.0
>> encapsulation ppp
>> dialer pool 1
>> dialer remote-name r2
>> dialer string 5552002
>> dialer-group 1
>> ppp callback request
>> ppp authentication chap
>> end
>>
>> r1#sh run int bri0
>> Building configuration...
>>
>> Current configuration : 201 bytes
>> !
>> interface BRI0
>> no ip address
>> encapsulation ppp
>> dialer pool-member 1
>> isdn switch-type basic-5ess
>> cdapi buffers regular 0
>> cdapi buffers raw 0
>> cdapi buffers large 0
>> ppp authentication chap
>> end
>>
>> r1#
>>
>> I can also configure it with server if you would like to see.
>> I hope that helps you.
>>
>> Here is a link to dialer profiles on DocCD:
>>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
>> fdial_c/fnsprt5/dcdiprof.htm#1001553
>>
>>
>> Sincerely,
>>
>> John Matijevic, CCIE #13254, MCSE, CNE, CCEA
>> Network Consultant
>> Hablo Espanol
>> 305-321-6232
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
>> john matijevic
>> Sent: Saturday, July 31, 2004 11:32 AM
>> To: 'mani poopal'; 'ccie2be'; 'Chuck South'; ccielab@groupstudy.com
>> Subject: RE: Re: ISDN callback/dialer load-threshold.
>>
>> Hello Mani,
>> I am pretty sure this can be used via Dialer profiles as well. I am
in
>> the process of testing it, again and will post my configuration when
>> finished. As far as the two dialer map statements, I only had one
dialer
>> map statement, I also had a switch that I configure that uses one bri
>> number for both channels.
>>
>>
>> Sincerely,
>>
>> John Matijevic, CCIE #13254, MCSE, CNE, CCEA
>> Network Consultant
>> Hablo Espanol
>> 305-321-6232
>> -----Original Message-----
>> From: mani poopal [mailto:mani_ccie@yahoo.com]
>> Sent: Saturday, July 31, 2004 11:05 AM
>> To: ccie2be; john matijevic; 'Chuck South'; ccielab@groupstudy.com
>> Subject: Re: Re: ISDN callback/dialer load-threshold.
>>
>> Hi John,
>>
>> Excellent reply. John now my next question, what is the equivalent
>> command for call back in non legacy DDR,ie Dialer profiles(is it ppp
>> callback accept on server/ppp callback request on client or some
other
>> commands). If members have config examples it is appreciated. In
the
>> Chucks ISDN example I saw only one dialer map ip statement, I think
it
>> shold be two statements with both dial strings(for both bri channels
of
>> destination, if not dialer will not bring the second channel)
>>
>> thanks
>>
>> Mani
>>
>>
>> B.ENG,A+,CCNA,CCNP,CCNP-VOICE, CSS1,CNA,MCSE
>> (416)431 9929
>> MANI_CCIE@YAHOO.COM
>> _____
>>
>> Do you Yahoo!?
>> Yahoo!
>>
<http://us.rd.yahoo.com/mail_us/taglines/50x/*http:/promotions.yahoo.com
>> /new_mail/static/efficiency.html> Mail - 50x more storage than other
>> providers!
>>
>>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:40 GMT-3