Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
IP trunking and network services ??
- Thread starter mdfan
- Start date
- Thread starter
- #3
Hi,
We have installed a solution using BP128i's for trunking MD110 QSIG over IP. As far as we can se You get most (I believe all) of the MD110 proprietary QSIG/network services.
I am not sure, but I believe You will get the same services using the new IP trunk card in BC12.
Best regards
Paal E. Jeppedal
We have installed a solution using BP128i's for trunking MD110 QSIG over IP. As far as we can se You get most (I believe all) of the MD110 proprietary QSIG/network services.
I am not sure, but I believe You will get the same services using the new IP trunk card in BC12.
Best regards
Paal E. Jeppedal
I think you have used the IPU board on BP128, but which kind of board have you use on MD110?
Have anyone any info about IP trunking on MD110 BC11 and/or BC12?
To speak about network services is a must know the infrastructure... From Alex BC11 I can't understand if ELU32 can connect two MD110, eventually with network services (I think no)
Bye
GioBs
Have anyone any info about IP trunking on MD110 BC11 and/or BC12?
To speak about network services is a must know the infrastructure... From Alex BC11 I can't understand if ELU32 can connect two MD110, eventually with network services (I think no)
Bye
GioBs
Hi GioBs,
Yes, we have connected the BP128i via TLU76/1 ... In June, Ericsson will ship a mew card, ITG wich is a intergated Webswitch as a card in the MD. The card is still connected back to back with a TLU76/1 and gives full MD QSIG / networking functionality.
In BC12 there will be another new IP card that is fully integrated in the MD without the need of a TLU76 card.
The ELU32 card is a multipurpose IP / V.24 card for O&M, ICU, CIL, etc. It can be used for communication between the MD and external application like Voicemail, acounting, message diversion, telnet sessions for maintenance, etc.
Best regards
Paal E. Jeppedal
Yes, we have connected the BP128i via TLU76/1 ... In June, Ericsson will ship a mew card, ITG wich is a intergated Webswitch as a card in the MD. The card is still connected back to back with a TLU76/1 and gives full MD QSIG / networking functionality.
In BC12 there will be another new IP card that is fully integrated in the MD without the need of a TLU76 card.
The ELU32 card is a multipurpose IP / V.24 card for O&M, ICU, CIL, etc. It can be used for communication between the MD and external application like Voicemail, acounting, message diversion, telnet sessions for maintenance, etc.
Best regards
Paal E. Jeppedal
- Thread starter
- #7
Jeppedal , regarding "The ELU32 card is a multipurpose IP / V.24 card for O&M, ICU, CIL, etc. It can be used for communication between the MD and external application like Voicemail, acounting, message diversion, telnet sessions for maintenance, etc."
I think you mix the ELU32 and the NIU board here.
ELU32 is the IP extension Gateway card to connect LAN/WAN IP extensions (MS netmeeting , Ericsson IP phone etc.)towards one particular MD110.
ELU32 is NOT an IP trunking card to connect MD110:s together via IP.
Please distinguish between IP trunking and IP gateway card.
I think you mix the ELU32 and the NIU board here.
ELU32 is the IP extension Gateway card to connect LAN/WAN IP extensions (MS netmeeting , Ericsson IP phone etc.)towards one particular MD110.
ELU32 is NOT an IP trunking card to connect MD110:s together via IP.
Please distinguish between IP trunking and IP gateway card.
I have heard about solutions using Bc11 and the webswitch as well to get IP-networking for the MD110. Look at the thread
q-sig over ip thread461-463661
in the general telephony fourum.
As Paal stated, and as far as I know, IP-networking will be supported in Bc12.
q-sig over ip thread461-463661
in the general telephony fourum.
As Paal stated, and as far as I know, IP-networking will be supported in Bc12.
- Thread starter
- #10
Ericsson has made an IP trunk gateway testreport between various MD110's from BC9 , 10 and 11. There they have gone through all network services for compliance . (Using WEBSWITCH2000)
Kressmark : What do you then mean by "As Paal stated, and as far as I know, IP-networking will be supported in Bc12.
" ?
As far as I have understood , the IP networking part is supported before BC12 as well . What is new in BC12 is the new integrated trunk card (without the need of TLU76/1 ) .
Kressmark : What do you then mean by "As Paal stated, and as far as I know, IP-networking will be supported in Bc12.
" ?
As far as I have understood , the IP networking part is supported before BC12 as well . What is new in BC12 is the new integrated trunk card (without the need of TLU76/1 ) .
Thanks for the above info.
Can someone provide me the info on
ITG card?
is the configuration almost like a TLU76/1?
Does anyone had a chance to connect ITG with Cisco network?
please provide me your feedback? I am in the process of testing an ITG?
Thanks
Nanda
Can someone provide me the info on
ITG card?
is the configuration almost like a TLU76/1?
Does anyone had a chance to connect ITG with Cisco network?
please provide me your feedback? I am in the process of testing an ITG?
Thanks
Nanda
whosrdaddy
Vendor
Duvel,
in BC12 IP trunking is done via ELU32. concerning network services this is from alex :
It is possible to execute network services both in pure H.323 private networks and in mixed H.323/ISDN private networks (scenarios with H.323/ISDN gateway nodes).
The procedure to request services is based both on ASB 501 04 Specific Protocol in UUI message and Information field, and on GFP (ISO QSIG). The aim of this twofold way of requesting some services is to assure interworking with existing ISDN tie lines: UUI assures interworking with previous ASB 501 04 releases, whilst GFP assures interworking with PABXes in the mixed H.323/ISDN scenarios mentioned above.
The service information is included in H.225.0 messages by embedding Q.931 messages.
The same signalling procedures as in ISDN trunks are kept in H.323 trunks. Q.931 messages are embedded inside H.225.0 messages of the same message type, when possible.
The way some of the services (e.g., call diversion) are executed (in a proprietary way based either on UUI or on ISO QSIG) can be set in the destination configuration or, in some cases, can be chosen by means of the Application System Parameter PARNUM=223.
The following services make use of embedded UUI signalling:
Account code
Authorization code
Call Back
Call Deflection
Call Diversion
Call Extending
Call Offer
Called Party Number
Calling/Connected Line Identity
Calling/Connected Line Identity Restriction
Calling/Connected Name Identity
Customer Identity
Day/Night Service Notification
DNIS for ACD
FRL/TCM
Intrusion
Message Waiting Notification
Night Service Diversion
Priority Routing
Repeated Deflection
Rerouting
Transfer
Type of Party
Voice Mail facility
And these services are executed based on ISO QSIG standards:
Advice of Charge
Call Completion
Call Forwarding
Call Offer
Call Transfer
Calling/Connected Line Identity Restriction (only public number)
Calling/Connected Name Identity (without presentation rules)
Path replacement
Type of Party (through ISO common information)
2.10 Protocol
The IP networking facility is based on the ITU-T H.323 version 2 recommendation (H.225.0 and H.245 protocols).
Regarding the H.225.0 RAS protocol, only the location messages are supported.
No registration is supported. So, transport addresses for signalling must be set up by means of
I/O commands.
2.11 CODECs
2.11.1 Voice CODECs support
The H.323 network interfaces (ELU32 boards) are capable of using different types of audio codecs in GW calls (in non-GW calls the media is not routed through the ASB 501 04, but directly through the IP network).
The voice CODEC to be used in calls is negotiated and selected per call (H.245 phase).
In the table below there is a list of the voice CODECs supported by the ELU32 boards.
The bit rate stated for each CODEC (i.e., the bandwidth required for the packets) is a net value. That is, this value does not include the overhead caused by packet headers. So, the real bit rate of a voice stream encoded by these CODECs is higher than the bit rate indicated in the table.
CODEC BW (kbit/s) Frame length Frames/packet
G.729 Annex A 8 10 ms 3
G.729 Annex A with annex B 8 10 ms 3
G.723.1 5.6-6.3 30 ms 1
G.711 A-law 64 kbit/s 64 1 ms 30, 32
G.711 µ-law 64 kbit/s 64 1 ms 30, 32
2.11.2 Choice of CODECs
It is possible via I/O command to state preferences (and the relative priorities among them) concerning the order in which the voice CODECs must be selected in GW calls. This list of ordered preferences is useful to fit the particular voice quality requirements and the bandwidth availability in each customer installation.
In calls between two ASB 501 04 systems, only the priorities defined at the originating side are considered. In calls between ASB 501 04 and other systems, the priorities are considered depending on the H.245 master-slave negotiation.
2.11.3 CODECs restriction in transit calls
The IP networking facility allows to restrict the CODEC to be used in transit calls, where subsequent transcodings can spoil the speech signal quality. The use of the G.711 CODEC in this kind of calls can be forced on a per-system basis via I/O command.
It is possible to execute network services both in pure H.323 private networks and in mixed H.323/ISDN private networks (scenarios with H.323/ISDN gateway nodes).
The procedure to request services is based both on ASB 501 04 Specific Protocol in UUI message and Information field, and on GFP (ISO QSIG). The aim of this twofold way of requesting some services is to assure interworking with existing ISDN tie lines: UUI assures interworking with previous ASB 501 04 releases, whilst GFP assures interworking with PABXes in the mixed H.323/ISDN scenarios mentioned above.
The service information is included in H.225.0 messages by embedding Q.931 messages.
The same signalling procedures as in ISDN trunks are kept in H.323 trunks. Q.931 messages are embedded inside H.225.0 messages of the same message type, when possible.
The way some of the services (e.g., call diversion) are executed (in a proprietary way based either on UUI or on ISO QSIG) can be set in the destination configuration or, in some cases, can be chosen by means of the Application System Parameter PARNUM=223.
The following services make use of embedded UUI signalling:
Account code
Authorization code
Call Back
Call Deflection
Call Diversion
Call Extending
Call Offer
Called Party Number
Calling/Connected Line Identity
Calling/Connected Line Identity Restriction
Calling/Connected Name Identity
Customer Identity
Day/Night Service Notification
DNIS for ACD
FRL/TCM
Intrusion
Message Waiting Notification
Night Service Diversion
Priority Routing
Repeated Deflection
Rerouting
Transfer
Type of Party
Voice Mail facility
And these services are executed based on ISO QSIG standards:
Advice of Charge
Call Completion
Call Forwarding
Call Offer
Call Transfer
Calling/Connected Line Identity Restriction (only public number)
Calling/Connected Name Identity (without presentation rules)
Path replacement
Type of Party (through ISO common information)
2.10 Protocol
The IP networking facility is based on the ITU-T H.323 version 2 recommendation (H.225.0 and H.245 protocols).
Regarding the H.225.0 RAS protocol, only the location messages are supported.
No registration is supported. So, transport addresses for signalling must be set up by means of
I/O commands.
2.11 CODECs
2.11.1 Voice CODECs support
The H.323 network interfaces (ELU32 boards) are capable of using different types of audio codecs in GW calls (in non-GW calls the media is not routed through the ASB 501 04, but directly through the IP network).
The voice CODEC to be used in calls is negotiated and selected per call (H.245 phase).
In the table below there is a list of the voice CODECs supported by the ELU32 boards.
The bit rate stated for each CODEC (i.e., the bandwidth required for the packets) is a net value. That is, this value does not include the overhead caused by packet headers. So, the real bit rate of a voice stream encoded by these CODECs is higher than the bit rate indicated in the table.
CODEC BW (kbit/s) Frame length Frames/packet
G.729 Annex A 8 10 ms 3
G.729 Annex A with annex B 8 10 ms 3
G.723.1 5.6-6.3 30 ms 1
G.711 A-law 64 kbit/s 64 1 ms 30, 32
G.711 µ-law 64 kbit/s 64 1 ms 30, 32
2.11.2 Choice of CODECs
It is possible via I/O command to state preferences (and the relative priorities among them) concerning the order in which the voice CODECs must be selected in GW calls. This list of ordered preferences is useful to fit the particular voice quality requirements and the bandwidth availability in each customer installation.
In calls between two ASB 501 04 systems, only the priorities defined at the originating side are considered. In calls between ASB 501 04 and other systems, the priorities are considered depending on the H.245 master-slave negotiation.
2.11.3 CODECs restriction in transit calls
The IP networking facility allows to restrict the CODEC to be used in transit calls, where subsequent transcodings can spoil the speech signal quality. The use of the G.711 CODEC in this kind of calls can be forced on a per-system basis via I/O command.
in BC12 IP trunking is done via ELU32. concerning network services this is from alex :
It is possible to execute network services both in pure H.323 private networks and in mixed H.323/ISDN private networks (scenarios with H.323/ISDN gateway nodes).
The procedure to request services is based both on ASB 501 04 Specific Protocol in UUI message and Information field, and on GFP (ISO QSIG). The aim of this twofold way of requesting some services is to assure interworking with existing ISDN tie lines: UUI assures interworking with previous ASB 501 04 releases, whilst GFP assures interworking with PABXes in the mixed H.323/ISDN scenarios mentioned above.
The service information is included in H.225.0 messages by embedding Q.931 messages.
The same signalling procedures as in ISDN trunks are kept in H.323 trunks. Q.931 messages are embedded inside H.225.0 messages of the same message type, when possible.
The way some of the services (e.g., call diversion) are executed (in a proprietary way based either on UUI or on ISO QSIG) can be set in the destination configuration or, in some cases, can be chosen by means of the Application System Parameter PARNUM=223.
The following services make use of embedded UUI signalling:
Account code
Authorization code
Call Back
Call Deflection
Call Diversion
Call Extending
Call Offer
Called Party Number
Calling/Connected Line Identity
Calling/Connected Line Identity Restriction
Calling/Connected Name Identity
Customer Identity
Day/Night Service Notification
DNIS for ACD
FRL/TCM
Intrusion
Message Waiting Notification
Night Service Diversion
Priority Routing
Repeated Deflection
Rerouting
Transfer
Type of Party
Voice Mail facility
And these services are executed based on ISO QSIG standards:
Advice of Charge
Call Completion
Call Forwarding
Call Offer
Call Transfer
Calling/Connected Line Identity Restriction (only public number)
Calling/Connected Name Identity (without presentation rules)
Path replacement
Type of Party (through ISO common information)
2.10 Protocol
The IP networking facility is based on the ITU-T H.323 version 2 recommendation (H.225.0 and H.245 protocols).
Regarding the H.225.0 RAS protocol, only the location messages are supported.
No registration is supported. So, transport addresses for signalling must be set up by means of
I/O commands.
2.11 CODECs
2.11.1 Voice CODECs support
The H.323 network interfaces (ELU32 boards) are capable of using different types of audio codecs in GW calls (in non-GW calls the media is not routed through the ASB 501 04, but directly through the IP network).
The voice CODEC to be used in calls is negotiated and selected per call (H.245 phase).
In the table below there is a list of the voice CODECs supported by the ELU32 boards.
The bit rate stated for each CODEC (i.e., the bandwidth required for the packets) is a net value. That is, this value does not include the overhead caused by packet headers. So, the real bit rate of a voice stream encoded by these CODECs is higher than the bit rate indicated in the table.
CODEC BW (kbit/s) Frame length Frames/packet
G.729 Annex A 8 10 ms 3
G.729 Annex A with annex B 8 10 ms 3
G.723.1 5.6-6.3 30 ms 1
G.711 A-law 64 kbit/s 64 1 ms 30, 32
G.711 µ-law 64 kbit/s 64 1 ms 30, 32
2.11.2 Choice of CODECs
It is possible via I/O command to state preferences (and the relative priorities among them) concerning the order in which the voice CODECs must be selected in GW calls. This list of ordered preferences is useful to fit the particular voice quality requirements and the bandwidth availability in each customer installation.
In calls between two ASB 501 04 systems, only the priorities defined at the originating side are considered. In calls between ASB 501 04 and other systems, the priorities are considered depending on the H.245 master-slave negotiation.
2.11.3 CODECs restriction in transit calls
The IP networking facility allows to restrict the CODEC to be used in transit calls, where subsequent transcodings can spoil the speech signal quality. The use of the G.711 CODEC in this kind of calls can be forced on a per-system basis via I/O command.
It is possible to execute network services both in pure H.323 private networks and in mixed H.323/ISDN private networks (scenarios with H.323/ISDN gateway nodes).
The procedure to request services is based both on ASB 501 04 Specific Protocol in UUI message and Information field, and on GFP (ISO QSIG). The aim of this twofold way of requesting some services is to assure interworking with existing ISDN tie lines: UUI assures interworking with previous ASB 501 04 releases, whilst GFP assures interworking with PABXes in the mixed H.323/ISDN scenarios mentioned above.
The service information is included in H.225.0 messages by embedding Q.931 messages.
The same signalling procedures as in ISDN trunks are kept in H.323 trunks. Q.931 messages are embedded inside H.225.0 messages of the same message type, when possible.
The way some of the services (e.g., call diversion) are executed (in a proprietary way based either on UUI or on ISO QSIG) can be set in the destination configuration or, in some cases, can be chosen by means of the Application System Parameter PARNUM=223.
The following services make use of embedded UUI signalling:
Account code
Authorization code
Call Back
Call Deflection
Call Diversion
Call Extending
Call Offer
Called Party Number
Calling/Connected Line Identity
Calling/Connected Line Identity Restriction
Calling/Connected Name Identity
Customer Identity
Day/Night Service Notification
DNIS for ACD
FRL/TCM
Intrusion
Message Waiting Notification
Night Service Diversion
Priority Routing
Repeated Deflection
Rerouting
Transfer
Type of Party
Voice Mail facility
And these services are executed based on ISO QSIG standards:
Advice of Charge
Call Completion
Call Forwarding
Call Offer
Call Transfer
Calling/Connected Line Identity Restriction (only public number)
Calling/Connected Name Identity (without presentation rules)
Path replacement
Type of Party (through ISO common information)
2.10 Protocol
The IP networking facility is based on the ITU-T H.323 version 2 recommendation (H.225.0 and H.245 protocols).
Regarding the H.225.0 RAS protocol, only the location messages are supported.
No registration is supported. So, transport addresses for signalling must be set up by means of
I/O commands.
2.11 CODECs
2.11.1 Voice CODECs support
The H.323 network interfaces (ELU32 boards) are capable of using different types of audio codecs in GW calls (in non-GW calls the media is not routed through the ASB 501 04, but directly through the IP network).
The voice CODEC to be used in calls is negotiated and selected per call (H.245 phase).
In the table below there is a list of the voice CODECs supported by the ELU32 boards.
The bit rate stated for each CODEC (i.e., the bandwidth required for the packets) is a net value. That is, this value does not include the overhead caused by packet headers. So, the real bit rate of a voice stream encoded by these CODECs is higher than the bit rate indicated in the table.
CODEC BW (kbit/s) Frame length Frames/packet
G.729 Annex A 8 10 ms 3
G.729 Annex A with annex B 8 10 ms 3
G.723.1 5.6-6.3 30 ms 1
G.711 A-law 64 kbit/s 64 1 ms 30, 32
G.711 µ-law 64 kbit/s 64 1 ms 30, 32
2.11.2 Choice of CODECs
It is possible via I/O command to state preferences (and the relative priorities among them) concerning the order in which the voice CODECs must be selected in GW calls. This list of ordered preferences is useful to fit the particular voice quality requirements and the bandwidth availability in each customer installation.
In calls between two ASB 501 04 systems, only the priorities defined at the originating side are considered. In calls between ASB 501 04 and other systems, the priorities are considered depending on the H.245 master-slave negotiation.
2.11.3 CODECs restriction in transit calls
The IP networking facility allows to restrict the CODEC to be used in transit calls, where subsequent transcodings can spoil the speech signal quality. The use of the G.711 CODEC in this kind of calls can be forced on a per-system basis via I/O command.
- Thread starter
- #14
I am sure lots of people find this useful . ( ALEX is very expensive :-( )Hi Daddy,
Many thanks for the useful information.
Do yu know command to change the different voice codec's.
The idea is to test the voice quality with different compression techniques so that we can configure reserve required bandwidth only on the Data network.
Do you have any info QOS to be implemnted on the pbx or data network? I do not find in the Alex.
Thanks once again for the help.
Many thanks for the useful information.
Do yu know command to change the different voice codec's.
The idea is to test the voice quality with different compression techniques so that we can configure reserve required bandwidth only on the Data network.
Do you have any info QOS to be implemnted on the pbx or data network? I do not find in the Alex.
Thanks once again for the help.
- Status
Similar threads
- Locked
- Question