Half Call Design Pattern

The Half Call design pattern is described using a standard pattern definition template.

Intent

The actions involved in a call processing can be categorized in two half calls. One half of the call handles the signaling involved in the originating end of the call. Other half call component handles the signaling involved in the terminating end of the call. This partitioning of a call in half call components simplifies the call design. Consider that a switch were to support N signaling systems. If half call design pattern is not used, it would have to deal with N x N call types to support all the signaling interworking call scenarios. With half call design pattern, each signaling type maps to originating and terminating half calls. Thus the number of call types to be supported is reduced to 2 x N.

Also Known As

• End Call Design Pattern
• End Point Protocol Design Pattern

Motivation

Consider the case where a switch has to support the following signaling schemes:

• SS7 ISUP (ISDN User Part)
• R2 Signaling
• POTS (Plain Old Telephone Service) Subscriber
• V5.2 Subscriber

If half call was not supported, the switch will have to support the following call types:

• ISUP to R2 Call
• R2 to ISUP Call
• ISUP to POTS Call
• POTS to ISUP Call
• POTS to R2 Call
• R2 to POTS Call
• ISUP to V5.2 Call
• V5.2 to ISUP Call
• R2 to V5.2 Call
• V5.2 to R2 Call
• POTS to V5.2 Call
• V5.2 to POTS Call
• ISUP to ISUP Call
• R2 to R2 Call
• POTS to POTS Call
• V5.2 to V5.2 Call

With half call design pattern, the switch will have to support only the following call types:

• ISUP Originating Call
• ISUP Terminating Call
• R2 Originating Call
• R2 Terminating Call
• POTS Originating Call
• POTS Terminating Call
• V5.2 Originating Call
• V5.2 Terminating Call

Thus there is a major simplification in the design when half call design pattern is used.

Applicability

This design pattern can be applied whenever a system needs to support interworking between different types of protocols. If the design models the interactions between originating and terminating end points as a single entity, the interworking design would be complicated by the large number of entity types. Also, the design would scale very poorly when new protocol type needs to be supported. In such cases, apply the half call design pattern. The originating and the terminating protocol end points should be modeled as separate entities (half calls).

Structure

Instead of having a N x N mesh of protocol end point interactions, this design pattern implements the system with 2 x N end points. For this design pattern to work, a standard protocol should be defined between a typical originating and terminating end point protocol.

Participants

The originating and terminating protocol end points are the main actors in this design pattern. In some scenarios, an intermediate broker object may have to be designed to coordinate the interactions between originating and terminating end points.

Collaboration

The originating and terminating end point protocols use a standard protocol to communicate with each other. The originating and terminating ends are not aware of the type of the other end of the protocol.

Consequences

The design becomes simple and it is fairly modular and can be easily scaled to introduce support for new protocols.

Implementation

If the standard protocol between originating and terminating end points is not defined properly, it would soon grow in complexity with the addition new protocol types.

Coming up with this standard protocol is the most challenging part of implementing this design pattern. Sometimes the implementation of a broker object helps in simplifying the standard protocol into the incoming and outgoing protocols.

Known Uses

The half call design pattern has been in use in implementing telephone switching systems involving support for multiple signaling protocols.

Related Patterns

None