Hi, I'm trying to establish an ISDN call between Switzerland and New-York. The 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. 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 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 ----------------------
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 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.
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 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
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 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.
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 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
And it was positive advice, rather than my not offering anything :) What is the signalling doing at the other end ? What I'm not sure about is what the different call references are about ? The setup has a call ref of 0x01 But the Call Processing has 0x81 The far end then sends a disconnect Neil J. McRae wrote:
Surely it can't be that, as the call has been answered.
Well its worth a try :-)
-- Ian
On Thu 31 Oct 2002 (15:43 +0000), Ian MacKinnon wrote:
And it was positive advice, rather than my not offering anything :) What is the signalling doing at the other end ? What I'm not sure about is what the different call references are about ? The setup has a call ref of 0x01 But the Call Processing has 0x81 The far end then sends a disconnect
Maybe Niel's right and it's a 56K with embedded signalling vs. 64K with separate signalling. Or maybe it's the parity. Afer all, 0x81 is 7bit even :-) -- Jim Segrave jes@nl.demon.net
Peter E. Fry wrote:
Ian MacKinnon wrote:
Surely it can't be that, as the call has been answered.
Not in my experience. Have you tried it?
Peter E. Fry
Well, yes, but here in UK. Call would be rejected with incompatible destination. And it is the originating end that is dropping the call -- Ian
If the network cannot handle a 64k call then it is *supposed* to reject the call but it does not always work that way. I've seen 64k calls connect and not work where a 56k call between the two sites works fine.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of ian@teliauk.com Sent: Thursday, October 31, 2002 07:57 To: pfry@swbell.net Cc: nanog@nanog.org Subject: Re: ISDN tip wanted
Peter E. Fry wrote:
Ian MacKinnon wrote:
Surely it can't be that, as the call has been answered.
Not in my experience. Have you tried it?
Peter E. Fry
Well, yes, but here in UK. Call would be rejected with incompatible destination. And it is the originating end that is dropping the call
56k and 64k comes up in CAS kind of signalling robbed bit versus using TS16 ...not on ISDN (CCS)...so how wud that matter? unless im missing something.. ----- Original Message ----- From: Neil J. McRae <neil@DOMINO.ORG> To: Andre Chapuis <chapuis@ip-plus.net> Cc: <nanog@nanog.org> Sent: Thursday, October 31, 2002 8:45 PM Subject: Re: ISDN tip wanted 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
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.
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 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
A) You might do lots better in comp.dcom.isdn. B) Or ask a ISDN guru like Karl Hank or Fred Goldstein. -- 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
Andre' From your protocol decode: Your unrestricted 64k Bchannel call connected on B1. It would appear that your network connection was ok. I would check the configuration on each end of the link since your interface went to the up state. and after it went to up it had an invalid call refernce which indicates to me a software firmware driver /' app issue. In my expereince with several hundred ISDN BRIs and PRIs from almost every US RBOC / ILEC they will misconfigure the BRI but then you would get a call reject incompatible and would not get a "good" connect. My opinion is that the app driver is incompatible with current switch protocol and / or BRI device firmware. What is the switch type and software level? When you configure the interface in the past you could config it to go to 64k unrestricted and if that does not work it will downshift to 64k restricted. You can also configure for 56k unrestricted also. If that were the issue you would see and incompatible network or network destination message and not get an end to end connect John L. Lee ISDN -- It suites Dennis's Needs (Dennis Hayes of Hayes Micrcomputer Products) Andre Chapuis wrote:
Hi, I'm trying to establish an ISDN call between Switzerland and New-York. The 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.
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 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 ----------------------
participants (9)
-
alok -
Andre Chapuis -
David Lesher -
Ian MacKinnon -
Jim Segrave -
John L Lee -
neil＠DOMINO.ORG -
Peter E. Fry -
Stephen Fisher