×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Return of a call through route E1.

Return of a call through route E1.

Return of a call through route E1.

(OP)
We have such scheme of passing of a call.
CISCO - PRI E1 ROU=5 - the MX ONE TSW - PRI E1 ROU=5 - CISCO
The call comes to CISCO on H323, is transferred to processing for example through LCR and under certain circumstances has to return on CISCO and to leave her for example on SIP or H323 further.
CISCO in this case as a working example, in her quality can act any other station.
If in ROU=5 two and more streams of E1, then everything works normally and problems don't arise.
At one stream of E1 in ROU=5 return of a call comes to an end with failure.
In ALEX it is described that in the station there is a certain block of return which processes such situation and doesn't allow to make similar a call.
Trace of such call from number 6291 coming from CISCO on ROU=5 with set 736291 is given below. DEST=73 it is appointed on ROU=5 and has to return on CISCO.
But it doesn't occur.
Interests a possibility of positive processing by the station of this situation.
Audit of the TSWSP8 station.

>>>>
Incoming Message: SETUP
Call Reference: 00 DC (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

BEARER CAPABILITY IE:
Coding Standard: CCITT standardized
Information Transfer Capability: Speech
Transfer Mode: Circuit-mode / Call independent signalling connection
Information Transfer Rate/Circuit Mode: 64 kbit/s
Layer 1 Protocol Identification: User information layer 1 protocol
Recommendation G.711 A-law

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 19

CALLING PARTY IE:
Type of Number: Unknown
Numbering Plan Identification: ISDN numbering plan
Presentation Indicator: Presentation Allowed
Spare, reserved
Screening Indicator: User provided, verified and passed
Calling Party Number: 6291

CALLED PARTY IE:
Type of Number: Unknown
Numbering Plan Identification: ISDN numbering plan
Called Number: 736290

<<<<

>>>>
Outgoing Message: SETUP ACKnowledgement
Call Reference: 00 DC (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 19

<<<<

>>>>
Outgoing Message: DISConnect
Call Reference: 00 DC (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

CAUSE IE:
Coding Standard: CCITT standard
Location: Local private network eg PBX
Cause Value: Resources unavailable
Cause Values, CCITT Standard: Switching equipment congestion


<<<<

>>>>
Incoming Message: RELease
Call Reference: 00 DC (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

<<<<

>>>>

Outgoing Message: RELease COMplete
Call Reference: 00 DC (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

<<<<

RE: Return of a call through route E1.

This is mission impossible, you cannot send the new SETUP on the same channel, if it is busy. Look at your trace....

RE: Return of a call through route E1.

(OP)
This message is given by the station. Nobody asks to occupy already involved timeslot. There are 29 more free.
What is interesting.
If to create two routes of ROU=5 and ROU=7 to divide between them stream timeslots in half, then the station having accepted a call on ROU=5 sends him on ROU=7 without any problems.
With one route and one full stream, the station refuses to do it.

RE: Return of a call through route E1.

vkrt, if I understand correctly, and it is not obvious, you are trying to route an incoming call directly back on the same route without involving a diversion or a transfer. If this is the case then the internal function of the software will block this from happening. It is called "anti tromboning" and is a deliberate action by the software designer. This prevent a user either deliberately or accidentally successive numbers to go back and forth over a route to tie up all the trunks with one call.

If the call involves a diversion or transfer mechanisms exist to optimize the call and release trunks which are not required to maintain the call.

Hope that helps.

RE: Return of a call through route E1.

(OP)
I understand that developers consciously locked the call routing situation provided by me.
The question was in opportunities standard means of TSW or way of program corrections to make available similar routing.
Repeated loopback of passing in my case will not be as on TSW there will take place the intermediate processing A and B numbers.
Repeated return on TSW connections is excluded.
Now it is necessary for implementation of this functionality it is necessary to use two E1 PRI between PBX.
And as a traffic is small, there was a wish to isbezhat excess units of TLU76 and all remaining.
By the way. In a case with IPLU and H.323 a situation absolutely identical.
Thanks.

RE: Return of a call through route E1.

You need to contact the Cisco people. We cannot do anything from the MD/TSW. Route optimization is one feature, but needs something else than Cisco (do you really think Cisco knows about this feature?). Believe me, if you are working with Cisco - forget about it...

RE: Return of a call through route E1.

(OP)
At the very beginning of the first message I did mentioning that CISCO in this case is taken for convenience of carrying out a test call. Precisely the same behavior of TSW is watched also in case of communication with other PBX for example of Alcatel-Lucent OmniPCX Enterprise or LG CS of 1000 on EDSS and H.323.
And here CISCO is on this subject deprived of prejudices and leaves processing of the conflicts of routing on conscience of a configurator. She perfectly works return of a call of PRI - PRI, SIP - SIP or H.323 - H.323. And problems do not arise.
In this case the feature of implementation of processing of routing only of TSW and versions is considered below.
If there are no ways of solving the problem, the subject will be read closed.
Thanks.

RE: Return of a call through route E1.

Call Cisco, this is not a TSW/TSW/MD110 issue

RE: Return of a call through route E1.

Simply: You cannot occupy a channel already busy. The case it not with TSW. You are trying to build a Moon rocket of a
MD?

RE: Return of a call through route E1.

(OP)
Your right not to trust me, but CISCO has nothing here.
Especially for you trace of a similar call of Alcatel-Lucent OmniPCX Enterprise - TSW - Alcatel-Lucent OmniPCX Enterprise is given below
Apparently the situation is similar above given with CISCO.


>>>>
Incoming Message: SETUP
Call Reference: 51 A5 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

BEARER CAPABILITY IE:
Coding Standard: CCITT standardized
Information Transfer Capability: Speech
Transfer Mode: Circuit-mode / Call independent signalling connection
Information Transfer Rate/Circuit Mode: 64 kbit/s
Layer 1 Protocol Identification: User information layer 1 protocol
Recommendation G.711 A-law

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 28

CALLING PARTY IE:
Type of Number: Unknown
Numbering Plan Identification: ISDN numbering plan
Calling Party Number: 7000

CALLED PARTY IE:
Type of Number: Unknown
Numbering Plan Identification: Unknown
Called Number: 747238

SENDING COMPLETE IE:

<<<<

>>>>
Outgoing Message: CALL PROCeeding
Call Reference: 51 A5 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 28

<<<<

>>>>
Outgoing Message: DISConnect
Call Reference: 51 A5 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

CAUSE IE:
Coding Standard: CCITT standard
Location: Local private network eg PBX
Cause Value: Resources unavailable
Cause Values, CCITT Standard: Switching equipment congestion

<<<<
>>>>
Incoming Message: RELease
Call Reference: 51 A5 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

CAUSE IE:
Coding Standard: CCITT standard
Location: Local private network eg PBX
Cause Value: Normal event
Cause Values, CCITT Standard: Normal clearing

<<<<
>>>>
Outgoing Message: RELease COMplete
Call Reference: 51 A5 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

<<<<

RE: Return of a call through route E1.

(OP)
Why you consider that TSW tries to occupy already occupied channel. In a stream of E1 30 timeslots and 29 of them we are free.
What prevents TSW to occupy any free timeslot and to send a call back on initial PBX to the vacant room?

RE: Return of a call through route E1.

Look,. if you have only one channel there (19), so how are you going to get the call diverted back on the same one? According to your explanation, you have only one in/out? Or something else?

RE: Return of a call through route E1.

Hi vkrt,
do you have TSW or is your MD110 on an earlier release? The "anti tromboning" mechanism built into the software became configurable in TSW. It is enabled by default but can be switched off per system with ASPAC:PARNUM=118,PARVAL=0;
The parameter is system wide not per route which is a limitation; it is called "Loop-back avoidance check selection" - Give it a try.

RE: Return of a call through route E1.

himdp,
Do you think this is going to work with only one channel? 19, as he explains? I don't know..... If yes, how?

RE: Return of a call through route E1.

fcpli, to be honest with you, I am having trouble understanding what he is trying to do; the posts read like the output from Google Translate. smile I am assuming that he has the full 30 channels available and that there is a misunderstanding about the single channel which clearly will not work. I fully accept that I could be very wrong however,(it wouldn't be the first time!) wink

RE: Return of a call through route E1.

(OP)
fcpli
In a stream with CISCO of 18 timeslots and 17 of them free.
<roedp:rou=5,tru=all;
ROUTE EQUIPMENT DATA
ROU TRU EQU IP ADDRESS SQU INDDAT CNTRL
5 001-1 001-2-20-01 H'000000000000
5 001-2 001-2-20-02 H'000000000000
5 001-3 001-2-20-03 H'000000000000
5 001-4 001-2-20-04 H'000000000000
5 001-5 001-2-20-05 H'000000000000
5 001-6 001-2-20-06 H'000000000000
5 001-7 001-2-20-07 H'000000000000
5 001-8 001-2-20-08 H'000000000000
5 001-9 001-2-20-09 H'000000000000
5 001-10 001-2-20-10 H'000000000000
5 001-11 001-2-20-11 H'000000000000
5 001-12 001-2-20-12 H'000000000000
5 001-13 001-2-20-13 H'000000000000
5 001-14 001-2-20-14 H'000000000000
5 001-15 001-2-20-15 H'000000000000
5 001-16 001-2-20-17 H'000000000000
5 001-17 001-2-20-18 H'000000000000
5 001-18 001-2-20-19 H'000000000000

RE: Return of a call through route E1.

(OP)
Dear colleagues.
I work with the equipment of this producer long ago and is not so naive that having adjusted a route, to register one timeslot and to demand from TSW of return of a challenge without having free resources.
It is natural that E1 with CISCO is registered completely. As above I already showed 18 timeslots. It is similarly registered also on CISCO.
controller E1 0/0
pri-group timeslots 1-19

With Alcatel-Lucent OmniPCX Enterprise the stream is registered in a case completely, all 30 timeslots.

Dear himdp.
You as always correctly understood a key part of the problem and showed regular, for TSW the solution of a task.
<aspap:parnum=118;
APPLICATION SYSTEM PARAMETERS
PARNUM PARVAL
118 1
END
<aspac:parnum=118,parval=0;
ASPAC:PARNUM=118,PARVAL=0;
SURE? (YES/NO)
<y;
EXECUTED
And the challenge began to return normally to a flow from which he arrived.
Unfortunately reading documentation in nonnative language not always informs correctly of sense.
Once again I thank for the solution of a task.

RE: Return of a call through route E1.

(OP)
I have absolutely forgotten to add.
Testing is held on:
VERSION: CXP1010139/4/TSW-SP08/R9A

RE: Return of a call through route E1.

(OP)
I checked in addition similar behavior on IPLU H.323 route.
Return of a call on IP a route also began to take place normally.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close