Last updated on FEBRUARY 22, 2017
Applies to:Oracle Communications MetaSolv Solution - Version 6.2.1 and later
Information in this document applies to any platform.
CA's not being copied from Current to Pending Issue for Circuit Emulation Virtual Circuit
Detected version: 220.127.116.119.b5
When building a TDM circuit through an EWO and assigning it to a Bandwidth circuit in order to make it a circuit emulated connection, after placing the connection In Service, upon issuing a Change order (EWO) against the same circuit, when working the RID task, a new Issue is created in a Pending status, but the Custom Attributes from the "current" (i.e. previous ) issue are NOT copied into the new issue. Specifically, this is happening under the following circumstances:
- Order type: EWO for new and change actions
- Circuit Type: Trunk (CLM), modifed to be circuit emulation
Note that in testing, the same scenario using a standard (non circuit emulation) virtual connection, built and modifed via an EWO (and hence not a customer circuit but an "internal" or "facility" virtual),
the CA's ARE successfully copied from the Current to the Pending issue when working the change order's RID. That says the problem likely lies in the circuit emulation code not checking for CA's to be copied.
Recreation is straightforward:
1) define some sample CA's against a given virtual connection spec, and ensure that spec allows circuit emulation
2) using an EWO, create a new trunk connection, and upon designing, assign it to a bandwidth circuit. Select the virtual connection spec chosen above that contains CA's.
3) Define the CA's, and save the design. Complete the EWO and put the connection In Service
4) issue an EWO change order against the same connection. Assign a workplan with a RID task.
5) when working the RID, notice that the CA's are missing in the latest "pending" issue, but still present in the previous "Current" issue.
6) test the same scenario with a standard virtual connection (using the same spec) that's NOT circuit emulation and see that the CA's ARE copied.
When building internal circuits to model SIP Peering trunk groups, the attributes defined on the original connection are not copied over into the new designs for an EWO change order.
This means the circuits have to have all their CA's redefined each time there is a change against such a connection.
These CA's hold the provisioning information pertaining to the SIP Peering attributes of the associated trunk group, and are therefore important to be correct.
Having to copy these from issue to issue introduces errors as well as increases the workload.
The movement of CA's from previous to new issue is standard functionality that's available in all other scenarios, so we assume this is an oversight since circuit emulation is relatively new in it's use.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms