How to check whether calledPartyNo is complete or not

[Ihjaz]

Hey Everyone,

Am trying to implement overlap receive.
When I get a SETUP message without a sendcomplete IE(which is not compulsory to be present) how do I check whether I've received complete called Party Number or not....i.e whether I should respond with a SETUPACK or CALLPROCEEDING.

Thanks
Ihjaz

 

[ISDNman]

Overlap is not used for incoming calls - no need to as the network has the complete number and can send it en-bloque.

The only case it is needed when pesky humans are dialing out, since the digits come one at a time.

So, unless you are writing CO Switch software there is no need for this.

If you ARE writing software for a CO switch there are a couple of ways to do this.

1) Pre-translation - this is complicated, and has gotten MUCH more so with the changes to the rules for area codes and prefixes.

With this case the switch recognizes if the call is local (7 digits) or International (starts with 011, but number of digits unknown).

With local calls 7 digits are collected and the call processed.

With non-local non-international 11 digits are collected.

With International calls the second method must be used.

2) Digit collection timer. After x seconds the switch stops accepting digits. In a properly implemented switch the <#> character will force the termination of the digit collection process. Try this on an International call and you will not it goes through much faster.

I have seen LECS that do pre-translation, in fact most do. But not all of them do. IN those cases dialing <#> will speed up your calls.

 

[Ihjaz]

Hey ISDNman,

Am programming an enterprise router which will be connected to a PBX.

In case of DID(Direct Inward Dialing) where PBX will be assigned a range of numbers and considering that some prefix digits(say first 6 digits)remain same and is exclusive for this PBX then CO switch on overlap send can send a setup without waiting for all the numbers to arrive.

And the PBX also does an overlap send to router where I need to recieve the setup with 6 digits and send a SETUPACK.

Interdigit Timer doesn't seem practical since I need to send SETUPACK as soon as I receive SETUP bcoz only after this SETUPACK reaches the other end INFO messgs would come.

Thanks
Ihjaz

 

[ISDNman]

Ihjaz

Put an ISDN protocol analyzer on a PBX (LT mode) or CO and if you see overlap sending I will eat my hat.

In either case, at the *originating* side the digits will be collected as I describe above. They might even be modified by a PBX, but in either case you should see a SETUP with the called party number present and will get no additional digits.

NOTE: The number of digits may not be 10. For example, in many cases DIDs are programmed for only 3 or 4 digits. But in that case that is all you are going to get (the end user/administrator of your equipment will need to only enter 3 or 4 digits in your equipment in that case - or tell the Telco to send all 10 digits).

As far as implementing this you could either have the user/administrator enter the entire number in your equipment and then also indicate the number of digits to be used, or you can instruct the end user to simply enter the same number of digits that are being sent.

This is indeed an area where most users will mess up and because of it won't be able to receive calls, so make sure support is aware if this.

I no longer have access to most of the ISDN standards (new job) but I bet you will even find that the overlap method is only shown for the TE to LT direction (e.g towards the network). Even if this is not true, I have been intimately involved with PRI equipment that does NOT support overlap in either directions and not once in over 100 installs was this a problem.

Incidentally, with that equipment originally we had planned on using overlap sending for call *origination* and we found that not all PRI's support this. So origination had to be re-written to enbloc and we had to deal with the whole digit collection issue.

I gather your boss has told you to implement it for both send and receive. Spend your time clarifying why it is not needed rather than trying to answer a question that is both unsolvable as well as not needing to be solved!

I hope this helps.

Best of luck

 

[Ihjaz]

Thanks a lot ISDNman.

One more question...If that's the case then why do u think Cisco Routers have this overlap send/receive feature...and this feature is being used also...
You google on overlap send/receive and u can find a lot of results showing overlap configuration for cisco routers.

I've already discussed this with my manager when he had asked me to implement this feature...and the answer he gave me was its goin to be useful in case of DID as I said above.

I want to confirm this before I go to him again.

Maybe you can tell me wat purpose it serves on Cisco routers.

Thanks
Ihjaz

 

[ISDNman]

Yes, I understand.

I *THINk* that cisco (unlike a lot of ISDN equipment) can emulate a network. In other words by setting one to LT mode and one to NT mode you can connect them back to back. Very nice in a lab scenario.

I don't know Cisco well enough to know how they describe the two modes (might be master and slave, etc).

In that case the end device (NT, Network termintion) would be using Overlap send and the other device (LT, Line Termination) would be using Overlap rcv.

Do you have a pair of ciscos you can set up? I am guessing in the LT to NT direction you would still see enbloc, but I guess the only way to tell would be to test it with a protocol analyzer attached.

In any case, if you are going to support LT (Line Termination, aka CO emulation), and a lot of equipment does not, then you WOULD need to implement Overlap receive.

Since pre-translation is impossibly complex, that leaves, the digit collection timer. Should be user adjustable with a range from 2 to 10 seconds.

Check the Cisco documentation. They love to make stuff adjustable so odds are they allow this.

After each info/digit is received the timer is reset. If the timer expires with no more digits the digits collected so far are processed.

Best of luck