This page describes how Party Identification will be supported on Sessions.
Sessions and Party Identification
The Session implementation will be modified to provide access to an IdentificationManager as defined in the existing PartyIdentificationIf.ice. The access to IdentificationManager will be as a facet of the Session proxy. The facet name will be defined in SessionCommunicationsIf.ice.
As a refresher, the IdentificationManager interface defined in PartyIdenitifcationIf.ice looks like this:
A new class, SipSessionIdentificationManager, will provide the servant for the IdentificationManager interface. It will have the necessary logic to add, update and provide access to the Party Identification class types defined in PartyIdentificationIf.ice embedded into SessionCookies attached to a Session, as shown below:
Setting the Caller and Dialed values
So now the question becomes how the cookies get on the Session to begin with.
The approach will be to add configuration items for endpoints as shown below. There are two options shown. The first is to simply set the name and number fields in the endpoint configuration parameters if a single Caller record is adequate. For cases where multiple Caller records should be attached, the second approach is to define a list of references to identity records defined separately from the endpoint.
The configuration handler will create cookies (CallerCookie) for the Caller records and add them as default session cookies on the endpoint. Whenever the endpoint's session factory method is called, these CallerCookie objects will be attached to the new Session.
The Dialed information (which is just the number) will be set based on the "destination" parameter passed into the Session constructor.
Updating the Connected Line information
Based on Mark's discussion below, I propose we define a new type of indication in SessionCommunicationsIf.ice:
This provides the means for the Bridge (via a SessionListener) to be notified of changes in identity of a Session so that IdentificationManager::updateConnectedLine() can be called for the bridged sessions.
Updating Redirecting info
We have two options here. We could add an extension point to the Routing Service for operations that redirect Sessions, and provide a hook that calls the IdentificationManager::updateRedirecting() for the Session being transferred. Or, we accept this is a basic routing service and just always do the updateRedirecting() call. I propose the latter for expediency.
- Is using cookies to store the party identification actually beneficial? The SessionListener is the only place I see in the Session-related area that we push cookies to someone, and in this instance we also send a reference to the Session itself. The client would probably want to just access the IdentificationManager interface rather than parse through the cookies themselves. (Although it saves an RPC.)
- Are the two alternative ways of setting the config information overly complicating things? (FYI, My approach to handle the case where a particular config file specified both a list and the two fields would be to add the individual Caller record defined in the endpoint to those in the list.)
- Should there be be a way to default the party identification to something sensible if it is left off of configuration?
- When a Session is being created for an outgoing call, do we just use the "destination" field for the Dialed number? Or do we get a cookie back (via an indicate or something) and THEN set the Dialed object? (Or maybe the latter is the ConnectLine information... I bet it is.) (EDIT: Mark answered this and I've incorporated into the above description.)
- Does this task include handling outgoing interactions to pjsip to insure that the party identification information is sent to a dialed party? (EDIT: Mark pointed out that this is actually covered by another task.)