One major function on the LAN side is “direct payload” (DMC ->
Direct Media Connect) between the call parties. This function can be
activated/deactivated for all SIP endpoints.
Given the fact that direct payload transmission between SIP subscribers
and other IP devices and gateways is desirable (due to better voice quality),
despite the fact that SIP subscribers do not support the H.323-based
DMC procedure, HG 3500 includes a “DMC proxy”. This feature is also
included in the common gateway board. In other words, as far as DMC signaling
is concerned, the gateway functions on behalf of the SIP subscriber and
converts the DMC signaling into SIP signaling.
For HFA subscribers the DMC connection is shown in the following diagram.
Figure 428. DMC in connection with HFA subscriber
This figure shows the situation for an HFA subscriber calling a TDM
subscriber in another node via an H323 IP trunk. The master connection
for both signaling and payload is maintained via the HG 3500 (in this
case configured as a HFA gateway) and both HG 3500 (IP trunking) gateways.
The Slave connections are the DMC connections and these are between IP
endpoints, on the one side the HFA subscriber and on the other side the
HG 3500 IP trunking board.
The transport addresses (IP addresses/ports) for payload transmission
are transmitted as part of the DMC signaling. The DMC proxy does not
transmit the actual transport address in this case, but instead transmits
the address of the addressed SIP subscriber in order to facilitate a
direct RTP stream for the SIP subscriber.
Given the fact that H.323 and SIP both use RTP for voice transmission,
connection between
- H323,
- SIP and HFA subscribers,
- IPDA: OpenScape 4000 host system and IPDA Access Points,
- Common Gateways (IP /SIP trunking) and HG 1500 gateways
is possible.
To set up a standards-compliant payload channel for the SIP subscriber,
the SIP re-invite and, preferably (provided the subscribers support it),
the SIP update procedures are used (the latter also requires SIP-PRACK
support). These procedures make it possible to switch a payload connection
over to another destination. Unlike previous DMC endpoints, the “master”
payload connection to OpenScape 4000 is not maintained in this case -
i.e. the DMC payload connection replaces the master connection. However,
the “master” signaling for the OpenScape 4000 remains established.
This is illustrated in the figure below:
Figure 429. HG 3500 subscriber which functions as a DMC proxy
Explanation:
A distinction is made between the DMC proxy and the DMC endpoint.
The latter is the endpoint for DMC signaling and the DMC payload channel
(RTP). Both gateways (HG 3500, HG 3575) and subscribers function as DMC
endpoints. HG 3500-Trk in node 300 and the SIP phone in node 200 are
therefore DMC endpoints in the diagram.
Note that the HG 3500 in this example is not part of a payload connection.
However, a DSP is reserved for the connection in case activation of a
feature terminates the DMC and causes a fallback to the master connection.
When the DMC is terminated, a master payload connection must be renegotiated
by SIP re-invite, as the connection does not exist for the SIP subscriber.
Given the fact that the SIP subscribers are themselves not DMC-capable,
we no longer talk about DMC connections as of HiPath 4000 V3.0, but instead
more generally about an end-to-end payload connection, or e2epc for short.
Setup of the master connection, which leads to a master payload connection
between the calling SIP endpoint and HG 3500 (requested in order to transmit
announcements and tones from the OpenScape 4000 to the SIP endpoint)
is not displayed. DMC is initiated with the Connect of the called side.
The procedure described above is even used for a call between two
SIP subscribers, i.e. an H.323-based DMC is set up from HG 3500 to HG
3500 (or internally if both subscribers are registered on the same gateway).
A direct connection between OpenScape 4000 SIP subscribers without DMC
is not possible at present.