Alcatel Unleashed

Hi Guys!

I have been working on a site where the customer has a requirement to link two OXO's together using SIP such that the remote OXO users can utilise the trunks on the main OXO as well as call internally. I have managed to get the link running and calls between extension are working as required. Users on the remote OXO can also use the trunks services on the main OXO site by pressing 9.

Here are two problems that I am struggling to resolve: (Obviously any help/guidnace would be highly appreciated)

1) The calls on the main site ring onto an AA. Options 2, 5 and 7 are suppose to ring hunt groups on the remote OXO. How I assume this can be achieved is by making these options ring a virtual terminal setup locally to the switch that plays the AA. The VTs can then be immediately forwarded to the remote hunt groups. This is based on the fact the the AA will only allow me to enter a local extension number in the options tree and not a remote one. Test calls made on this setup produce a rather bizarre result. The call rings on the remote hunt group for half a burst of ring after which it will go back to the main menu of the AA on the main site. To eliminate any possibility of a fault on the Voip link, I've tried forwarding the call from the VT to my mobile which produces the same result. I've also tried setting up the options to ring a speed dial which again results in the same behaviour. Am i doing something wrong here, or is there a label/timer that I've forgotten to amend? Or is there a better way of achieving this?

2) We have option 9 set as free dialing (main site runs extension range 200 and remote running 300). Again, since the main system only sees its own extensions under the internal calling directory, it will only allow callers to enter extensions local to the system. If a caller entered extension 301 for example, the AA prompts "this is an invalid entry". Can remote extensions be called using free dialing?

These two issues have really made my experiance on this site a really nightmare with the customer not impressed with the system and almost ready to throw it out of the window.

Could anyone throw in ideas on whether these two points can be addressed or not and if possible then how?

Cheers guys!

Hi,

1. Very strange. Calling rights of the virtual AA extensions are configured so that AA has the right to dial through the SIP TG? Joining configured between all types of trunks? Try in ARS to play also with private and public setting of the route through SIP TG to the other OXO. How do you dila extensions of OXO 2? Speed dials or seizure + extension of site B?

2. Try to configure a speed dial for each site B extension and see how it goes. This applies for the site B hunt groups, too.

Please post the resolution of these tests here.

Regards.

Hi! Thanks for your reply.

When you say that the AA is allowed to call through the SIP TG, do you mean that I can actually put the remote extension number in the AA options tree, or do I have to assign an access code to the ARS entry and enter the remote extension with leading access code? I've tried doing this, however I get an error message "Invalid no.".

Just to outline the setup in more detail, how I'm calling remote extensions (300 range) is by telling internal numbering plan on oxo1 that 300-399 is secondary trunk group - base ARS - NMT Keep - Priv Yes. I do not actually use any access codes to dial remote extension, users just dial the extension number e.g. 310. Under ARS, the entry for this route is set to Private call. How calls get routed at oxo2 is by using the Private Numbering Plan tab (range 300-399 set to subscriber, base 300).

I've also tried setting up remote extensions as speed dials and pointing the options to the particular speed dial index. However this still causes half a burst of ringing followed by call being re-routed to the top of the main menu.

The fact that the calls does actually go through and ring makes me assume that the voip link is fine however there is maybe a feature right or timer that is rejecting/bouncing the call back to the AA. Again, pointing the AA option to a speed dial with my mobile number returns the same results pointing the problem more to the AA. As far as joins/conference allowances are concerned these are all as required (all ticks on joining, conference unrestricted, ticks on rights ext/ext transfer and such).

Can you post here the traces from OSC when that half burst happens (using speed dials)? - try to capture them on both OXO's.

Hello.
Please see the traces below.

Trace 1 - taken on Oxo1 (Main site) for the particular AA option pointing to speed dial 7002 that is set to dial 390 (hunt group extension number on Oxo2) using access 89 (I've set this acces to fall through to the ARS table to obtain oxo2's IP address).

ISDN3_00001 13/04 20:51:35 RX d_channel: 54 (S:00 T:000) payload: (43) 08 02 00 01 05 A1 04 03 90 90 A3 18 03 A9 83 81 1E 02 84 83 6C 0C 21 83 37 39 37 36 38 34 38 36 35 32 70 07 81 38 35 31 35 34 33
0x05 SETUP Ref: O,1
ie 0xA1 Sending complete
ie 0x04 Bearer capability: 90 90 A3
Coding: CCITT standardized
Information transfer capability: 3.1 kHz audio
Transfer mode: Circuit mode
Transfer rate: 64 Kbit/s
User info layer 1: G.711 A-law
ie 0x18 Channel identification: A9 83 81
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B1 channel
Coding: CCITT standardized
Channel type: B-channel units
Channel number: 0x01
ie 0x1E Progress indicator: 84 83
Coding: CCITT standardized
Location: Public network serving the remote user
Progress: Origination address is non-ISDN
ie 0x6C Calling party number: 21 83 37 39 37 36 38 34 38 36 35 32
Number type: National number
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Presentation: presentation allowed
Screening: network provided
Number: *MY CLI*
ie 0x70 Called party number: 81 38 35 31 35 34 33
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 851543
ISDN3_00002 13/04 20:51:35 TX d_channel: 54 (S:00 T:000) payload: (10) 08 02 80 01 02 18 03 A9 83 81
0x02 CALL_PROCEEDING Ref: D,1
ie 0x18 Channel identification: A9 83 81
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B1 channel
Coding: CCITT standardized
Channel type: B-channel units
Channel number: 0x01
ISDN3_00003 13/04 20:51:35 TX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 01 01
0x01 ALERTING Ref: D,1
ISDN3_00004 13/04 20:51:40 TX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 01 07
0x07 CONNECT Ref: D,1
ISDN3_00005 13/04 20:51:40 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 00 01 0F
0x0F CONNECT_ACK Ref: O,1
ISDN3_00006 13/04 20:52:09 RX d_channel: 54 (S:00 T:000) payload: (13) 08 02 00 01 45 08 02 80 90 1E 02 82 88
0x45 DISCONNECT Ref: O,1
ie 0x08 Cause: 80 90
Coding: CCITT standardized
Location: User
Class: Normal event
Value: Normal release
ie 0x1E Progress indicator: 82 88
Coding: CCITT standardized
Location: Public network serving the local user
Progress: In-band information or appropriate pattern now available
ISDN3_00007 13/04 20:52:09 TX d_channel: 54 (S:00 T:000) payload: (9) 08 02 80 01 4D 08 02 80 90
0x4D RELEASE Ref: D,1
ie 0x08 Cause: 80 90
Coding: CCITT standardized
Location: User
Class: Normal event
Value: Normal release
ISDN3_00008 13/04 20:52:09 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 00 01 5A
0x5A RELEASE_COMP Ref: O,1

Trace 2 - Taken on Oxo2 when caller enters option (on Oxo1 AA) to be forwarded to hunt group 390 (on Oxo2). There doesn't seem to be much happening on this end. These are the two lines written when the call rings for that half burst:

SAN_00003 at line 163 "conv_str.c"
on 13.04 at 21:07:24 (901647605)
info : FFFF FFFF 0000 0000 0000 0000 0000 0000
SAN_00004 at line 163 "conv_str.c"
on 13.04 at 21:07:24 (901647608)
info : FFFF FFFF 0000 0000 0000 0000 0000 0000

Trace 3 - This trace is taken on Oxo1 with an option pointing to speed dial 7002 again, however this speed dial in this case is set to call my mobile using access 9 (ISDN30 trunk the call is being received on):

ISDN3_00001 13/04 20:53:06 RX d_channel: 54 (S:00 T:000) payload: (43) 08 02 00 01 05 A1 04 03 90 90 A3 18 03 A9 83 81 1E 02 84 83 6C 0C 21 83 37 39 37 36 38 34 38 36 35 32 70 07 81 38 35 31 35 34 33
0x05 SETUP Ref: O,1
ie 0xA1 Sending complete
ie 0x04 Bearer capability: 90 90 A3
Coding: CCITT standardized
Information transfer capability: 3.1 kHz audio
Transfer mode: Circuit mode
Transfer rate: 64 Kbit/s
User info layer 1: G.711 A-law
ie 0x18 Channel identification: A9 83 81
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B1 channel
Coding: CCITT standardized
Channel type: B-channel units
Channel number: 0x01
ie 0x1E Progress indicator: 84 83
Coding: CCITT standardized
Location: Public network serving the remote user
Progress: Origination address is non-ISDN
ie 0x6C Calling party number: 21 83 37 39 37 36 38 34 38 36 35 32
Number type: National number
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Presentation: presentation allowed
Screening: network provided
Number: 7976848652
ie 0x70 Called party number: 81 38 35 31 35 34 33
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 851543
ISDN3_00002 13/04 20:53:06 TX d_channel: 54 (S:00 T:000) payload: (10) 08 02 80 01 02 18 03 A9 83 81
0x02 CALL_PROCEEDING Ref: D,1
ie 0x18 Channel identification: A9 83 81
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B1 channel
Coding: CCITT standardized
Channel type: B-channel units
Channel number: 0x01
ISDN3_00003 13/04 20:53:06 TX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 01 01
0x01 ALERTING Ref: D,1
ISDN3_00004 13/04 20:53:12 TX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 01 07
0x07 CONNECT Ref: D,1
ISDN3_00005 13/04 20:53:12 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 00 01 0F
0x0F CONNECT_ACK Ref: O,1
ISDN3_00006 13/04 20:53:22 TX d_channel: 54 (S:00 T:000) payload: (35) 08 02 00 22 05 04 03 80 90 A3 18 01 A3 1E 02 85 83 70 0C 81 30 37 39 37 36 38 34 38 36 35 32 7D 02 91 81
0x05 SETUP Ref: O,34
ie 0x04 Bearer capability: 80 90 A3
Coding: CCITT standardized
Information transfer capability: Speech
Transfer mode: Circuit mode
Transfer rate: 64 Kbit/s
User info layer 1: G.711 A-law
ie 0x18 Channel identification: A3
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Preferred
D-channel identified: No
Information channel selection: any channel
ie 0x1E Progress indicator: 85 83
Coding: CCITT standardized
Location: Private network serving the remote user
Progress: Origination address is non-ISDN
ie 0x70 Called party number: 81 30 37 39 37 36 38 34 38 36 35 32
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 07976848652
ie 0x7D High layer compatibility: 91 81
ISDN3_00007 13/04 20:53:22 RX d_channel: 54 (S:00 T:000) payload: (14) 08 02 80 22 0D 18 03 A9 83 82 1E 02 82 88
0x0D SETUP_ACK Ref: D,34
ie 0x18 Channel identification: A9 83 82
Interface identifier: Implicit
Interface type: Primary rate
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B1 channel
Coding: CCITT standardized
Channel type: B-channel units
Channel number: 0x02
ie 0x1E Progress indicator: 82 88
Coding: CCITT standardized
Location: Public network serving the local user
Progress: In-band information or appropriate pattern now available
ISDN3_00008 13/04 20:53:23 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 22 02
0x02 CALL_PROCEEDING Ref: D,34
ISDN3_00009 13/04 20:53:25 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 22 01
0x01 ALERTING Ref: D,34
ISDN3_00010 13/04 20:53:25 TX d_channel: 54 (S:00 T:000) payload: (9) 08 02 00 22 45 08 02 80 90
0x45 DISCONNECT Ref: O,34
ie 0x08 Cause: 80 90
Coding: CCITT standardized
Location: User
Class: Normal event
Value: Normal release
ISDN3_00011 13/04 20:53:25 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 80 22 4D
0x4D RELEASE Ref: D,34
ISDN3_00012 13/04 20:53:25 TX d_channel: 54 (S:00 T:000) payload: (5) 08 02 00 22 5A
0x5A RELEASE_COMP Ref: O,34
ISDN3_00013 13/04 20:53:35 RX d_channel: 54 (S:00 T:000) payload: (13) 08 02 00 01 45 08 02 80 90 1E 02 82 88
0x45 DISCONNECT Ref: O,1
ie 0x08 Cause: 80 90
Coding: CCITT standardized
Location: User
Class: Normal event
Value: Normal release
ie 0x1E Progress indicator: 82 88
Coding: CCITT standardized
Location: Public network serving the local user
Progress: In-band information or appropriate pattern now available
ISDN3_00014 13/04 20:53:35 TX d_channel: 54 (S:00 T:000) payload: (9) 08 02 80 01 4D 08 02 80 90
0x4D RELEASE Ref: D,1
ie 0x08 Cause: 80 90
Coding: CCITT standardized
Location: User
Class: Normal event
Value: Normal release
ISDN3_00015 13/04 20:53:35 RX d_channel: 54 (S:00 T:000) payload: (5) 08 02 00 01 5A
0x5A RELEASE_COMP Ref: O,1

Does this make any sense?

Hi Guys!

Just wondering if it could be an issue with activating the RTP feature under Voip Parameters. I've had an issue in the past where a customer required calls inbound on ISDN2 to be diverted via SIP and this wouldn't work due to the RTP feature enabled. The divert started working fine after this was disabled.

I have tried testing calls with both RTP activated and diactivated, however the calls present the same results under both scenarios. Could there be anything else of this sort - Echo Cancellation or Voice Active detection?

Modify the rights of the all Voice Mail Unit ports (used in AA): Subscribers/Basestations List/ choose Voice Mail Unit/ Details/ Features/ part2/ mark Join Incoming and Outgoing; Transfer to External must be already set.

Hmm... You receive disconnect from OXO2 or from public network... How is external diversion configured under feature design: joining or rerouting? (if rerouting try to play with joining).
The fact that when you divert the call to your mobile you get the same result as diverting the call to OXO2, tells me that there is more like an ISDN line config problem than a SIP TG problem.

Try to play also with noteworthy addresses for ISDN like:
IsdnStatuE - This flag allows to select the OXO behaviour on reception of STATUS message (ISDN & QSIG) reporting an incompatible protocol state. By default (value 00), the call is released. Setting the value to 01, the OXO will not release the call but attempt to recover the call.
00 Release call
01 Recover call

For the time being I have no other ideas.

Hi. Thanks for you message.

The DISCONNECT you see in the trace was captured while I hung up the call during testing and taking the traces. Sorry, I forgot to cut that bit of the trace off.

Ideally all I get while running the trace is the lines upto "0x0F CONNECT_ACK Ref: O,1
". At this point the AA rings and answers the call after which no trace is generates, irrespective of what option I choose. The next line generated on the trace is ofcourse the DISCONNECT when I hang up the call.

The only difference there is, is when I try the option that diverts to my mobile. In this case, I get more information after the divertion goes through however nothing is generated when the call bounces off back to the AA. I don't think the traces is actually generating any information when the call bounces off.

Am I running the trace under wrong filters/settings? Do I need to set something on the trace before I run it?

What about my suggestion?