cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2419
Views
0
Helpful
7
Replies

German ISDN overlap sending - missing a digit

davidme
Level 1
Level 1

Hi,

Am deploying a Call Manager site in Germany currently. Having some 'fun' due to their non fixed dial plan!

Currently I am trying to route calls inbound to an H323 gateway. We have worked out that calls are sent via QSIG using overlap sending so sometimes we get digits being sent after the main batch of digits.

The problem is - from certain areas of Germany - we don't get the final digit! We are expecting something like 481XXXX and from certain areas we get 481X then another X then another X. We don't get the final X even after extending the T302 timeout to 8 or 10 seconds.

Any help gratefully received. Bit's of config below:

*Mar 11 22:16:52.043: %SYS-5-CONFIG_I: Configured from console by e000007 on vty0 (132.130.20.26)

*Mar 11 22:17:22.567: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x28A6

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18387

Preferred, Channel 7

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '211182619'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '4812'

Plan:ISDN, Type:Subscriber(local)

*Mar 11 22:17:22.567: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xA8A6

Channel ID i = 0xA98387

Exclusive, Channel 7

*Mar 11 22:17:23.507: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x28A6

Called Party Number i = 0xC1, '3'

Plan:ISDN, Type:Subscriber(local)

*Mar 11 22:17:24.495: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x28A6

Called Party Number i = 0xC1, '2'

Plan:ISDN, Type:Subscriber(local)

*Mar 11 22:17:24.651: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xA8A6

*Mar 11 22:17:24.655: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0xA8A6

Cause i = 0x8181 - Unallocated/unassigned number

Progress Ind i = 0x8188 - In-band info or appropriate now available

*Mar 11 22:17:33.399: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0xA8A6

Cause i = 0x8181 - Unallocated/unassigned number

Progress Ind i = 0x8188 - In-band info or appropriate now available

*Mar 11 22:17:41.983: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xA8A6

Cause i = 0x8081 - Unallocated/unassigned number

*Mar 11 22:17:42.043: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x28A6

*Mar 11 22:17:42.043: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xA8A6

interface Serial0/0/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-qsig

isdn overlap-receiving T302 5000

isdn incoming-voice voice

isdn send-alerting

isdn sending-complete

no cdp enable

dial-peer voice 1 voip

destination-pattern 481....

modem passthrough nse codec g711ulaw

voice-class codec 1

voice-class h323 1

session target ipv4:X.X.X.X

dtmf-relay h245-alphanumeric

fax-relay ecm disable

no vad

Dave

1 Accepted Solution

Accepted Solutions

Hi Dave,

If we're extending the 302 timer and you're still not getting the digit there's not much else we can change. The provider is responsible for sending the digit - if we don't get it; we don't get it.

If you change the timer to 20-30 seconds you can definitely confirm the provider isn't sending the last digit.

-nick

View solution in original post

7 Replies 7

Hi Dave,

If we're extending the 302 timer and you're still not getting the digit there's not much else we can change. The provider is responsible for sending the digit - if we don't get it; we don't get it.

If you change the timer to 20-30 seconds you can definitely confirm the provider isn't sending the last digit.

-nick

Hi, this very same issue was encountered by another German customer time ago. I do not remember to have seen a conclusion to it, but it should be easy to find the thread with a search.

Hi,

I searched before posting and ran through that thread but to no avail.

What I can't understand is why when you dial from different parts of the country - the local exchange presents different amounts of digits.

Also - the customer had a PBX that worked previously - but how?

HI Guys,

This is now resolved. Had a talk with Deutsche Telecom. Apparently - they can wait up to 20 seconds for the final digit to be collected.

Final Serial interface configuration:

interface Serial0/0/0:15

no ip address

encapsulation hdlc

no logging event link-status

isdn switch-type primary-net5

isdn overlap-receiving T302 20000

isdn incoming-voice voice

isdn service b_channel 1 state 2

isdn send-alerting

isdn sending-complete

no cdp enable

Hopefully that should help anyone else who comes across this problem.

20 seconds is a seriously long amount of time though........

Dave

Very good, unrelated:

isdn service b_channel 1 state 2

what this does ?

Good question. Perhaps if you can get involved a good guy from telco this mystery could be solved.

That other customer was me. The solution was overlap receiving. We saw that some numbers were sent in full in one setup message, but then others were short one digit. When we applied overlap receiving this immediately and permanently resolved the issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: