While its been many years since I've done ISDN, I do know it was quite common for 64k call to be rejected but a 56k make it though, as I remember from a bell tech I worked with it has to do with 'new' channels being full and dropping to an older path that can only handle 56k. But like it said its been years since I've work with ISDN. -Jim -----Original Message----- From: Ian MacKinnon [mailto:ian@teliauk.com] Sent: Thursday, October 31, 2002 10:36 AM To: nanog@nanog.org Subject: Re: ISDN tip wanted Surely it can't be that, as the call has been answered. Neil J. McRae wrote:
try making it a 56K isdn call.
Neil.
[ Charset ISO-8859-1 unsupported, converting... ]
Hi, I'm trying to establish an ISDN call between Switzerland and New-York. The
The funny thing is that i have another router in NY, another ISDN line
from Verizon, and i'm calling from the same number in CH and it works
destination is in New-York, ISDN line provided by Verizon. The called is disconnected just after being set up (see NY-router log below), and the problem seems to be that Verizon switch does not understand the callref flag (0x01 and 0x81) correctly. perfectly...
Does anyone have a hint for me ? Thanks Andr?
Oct 31 14:23:56.350 MET: ISDN BR0/0: RX <- SETUP pd = 8 callref = 0x01 Oct 31 14:23:56.350 MET: Bearer Capability i = 0x8890 Oct 31 14:23:56.350 MET: Channel ID i = 0x89 Oct 31 14:23:56.350 MET: Signal i = 0x40 - Alerting on - pattern 0
Oct 31 14:23:56.350 MET: Calling Party Number i = 0x1183, '<calling number removed>' Oct 31 14:23:56.354 MET: Called Party Number i = 0xC1, '<called number removed>' Oct 31 14:23:56.354 MET: Locking Shift to Codeset 5 Oct 31 14:23:56.354 MET: Codeset 5 IE 0x2A i = 0x808B0B, '<calling number removed>', 0x800109800114800114800114 Oct 31 14:23:56.358 MET: ISDN BR0/0: Incoming call id = 0x9E, dsl 0 Oct 31 14:23:56.358 MET: ISDN BR0/0: received HOST_INCOMING_CALL call_id 0x9E Oct 31 14:23:56.358 MET: ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE Oct 31 14:23:56.358 MET: ISDN BR0/0: Event: Received a DATA call from <calling number removed> on B1 at 64 Kb/s Oct 31 14:23:56.358 MET: ISDN BR0/0: RM returned call_type 0 resource type 0 Oct 31 14:23:56.362 MET: ISDN BR0/0: TX -> CALL_PROC pd = 8 callref = 0x81 Oct 31 14:23:56.362 MET: Channel ID i = 0x89 Oct 31 14:23:56.362 MET: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x9E, ces 1 bchan 0, call type DATA Oct 31 14:23:56.366 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up Oct 31 14:23:56.370 MET: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to <calling number removed> Oct 31 14:23:56.462 MET: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0x01 Oct 31 14:23:56.462 MET: Cause i = 0x82D1 - Invalid call reference value Oct 31 14:23:56.466 MET: ISDN BR0/0: received HOST_DISCONNECT_ACK call_id 0x9E Oct 31 14:23:56.466 MET: ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA Oct 31 14:23:56.466 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down Oct 31 14:23:56.666 MET: CC: dsl 0 No CCB Src->HOST cid 0x9E, ev 0x4 ces 1 Oct 31 14:23:56.666 MET: ISDN BR0/0: received HOST_QUERY_RESPONSE call_id 0x9E
--------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 ----------------------
-- Neil J. McRae - Alive and Kicking neil@DOMINO.ORG
-- Ian
On 10/31/02 11:17 AM, "Jim Deleskie" <jdeleski@rci.rogers.com> wrote:
While its been many years since I've done ISDN, I do know it was quite common for 64k call to be rejected but a 56k make it though, as I remember from a bell tech I worked with it has to do with 'new' channels being full and dropping to an older path that can only handle 56k.
I have seen this too. The explanations that I got involved B8ZS vs. AMI trunks... --Warren. -- With Feudalism, it's your Count that votes.
participants (2)
-
Jim Deleskie
-
Warren Kumari, CCIE #9190