Half Call Design Pattern

The Half Call design pattern is described using a standard pattern definitiontemplate.

Intent

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

Also Known As

• End Call Design Pattern
• End Point Protocol Design Pattern

Motivation

Consider the case where a switch has to support the following signalingschemes:

• 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 followingcall 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 thefollowing 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 designpattern is used.

Applicability

This design pattern can be applied whenever a system needs to supportinterworking between different types of protocols. If the design models theinteractions between originating and terminating end points as a single entity,the interworking design would be complicated by the large number of entitytypes. Also, the design would scale very poorly when new protocol type needs tobe supported. In such cases, apply the half call design pattern. The originatingand 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, thisdesign pattern implements the system with 2 x N end points. For this designpattern to work, a standard protocol should be defined between a typicaloriginating and terminating end point protocol.

Participants

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

Collaboration

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

Consequences

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

Implementation

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

Coming up with this standard protocol is the most challenging part ofimplementing this design pattern. Sometimes the implementation of a brokerobject helps in simplifying the standard protocol into the incoming and outgoingprotocols.

Sample Code and Usage

Refer to the following links available in Xenon:

• V5.2 Call Processing
• ISUP Call Processing

Known Uses

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

Related Patterns

None