·GetInfoReq()，此异步方法请求在适当的时候提供与呼叫Leg相关的信息；
·GetCall()，此方法请求与呼叫Leg相关的呼叫：
·AttachMedia()，此方法请求呼叫Leg与它的呼叫对象相连；
·DetachMedia()，此方法使呼叫Leg与它的呼叫相分离；
·GetLastRedirectedAddress()，此方法用来查询要转向的最后地址；
·ContinueProcessing()，此操作继续呼叫Leg的处理，在呼叫Leg处理由于应用预约的事件通知被检出而中断后调用此操作；
·SetChargePlan()，设定操作员定义呼叫的计费策略。计费策略必须在呼叫Leg路由至目的地前设定。此方法也可以用来改变目前呼叫的计费策略；
·SetAdviceOfCbarge()，此方法允许AOC信息发送到可以接收该信息的终端；
·SuperviseReq()，调用此方法监视呼叫Leg；
·Deassign()，此方法请求重新指定应用和呼叫Leg以及相关对象的关系。
接口IpAppCallLeg继承自IpInterface，应用呼叫Leg接口用来处理与呼叫Leg请求相关的响应和错误。
·EventReportRes()，此异步方法报告所要请求报告的事件；
·EvenlReportErr()，此异步方法指示处理呼叫Leg事件报告的请求未成功以及原因；
·GetlnfoRes()，此异步方法报告应用所请求的所有必要信息；
·GetInfoErr()，此异步方法报告源端请求错误；
·RouteErr()，此方法报告路由错误；
·SuperviseRes()，此异步方法报告呼叫Leg监视事件给应用；
·SuperviseErr()，此异步方法报告呼叫Leg监视错误；
·CallLegEnded()，此方法指示应用网络中Leg已结束。
3.多媒体呼叫控制
在多媒体呼叫中，涉及以下七个接口：IpMultiMediaCallControlManager、IpAppMultiMediaCallControlManager、IpMultiMediaCall、IpAppMultiMediaCall、IpMultiMediaCallLeg、IpAppMultiMediaCallLeg以及IpMultiMediaChannel。
接口IpMultiMediaCallControlManager继承了IpMultiPartyCallControlManager提供的所有方法而且通过提供两个新的方法扩展了它的能力。通过这些方法可以媒体信道通知能力。当激活媒体信道通知能力时，包含两个标准集。两个标准集必须在信道报告给客户应用前全部实现。首先，多媒体呼叫必须与呼叫标准匹配(即目的呼叫码必须在一定范围内)，而且媒体信道指示也必须匹配。企业侧的对应接口IpAppMultiMediaCallControlManager继承了IpAppMultiPartyCallControlManager接口的所有方法，引入了一个新方法，即媒体信道事件通知方法。
为代表网络侧的多媒体呼叫，使用一个实现IpMultiMediaCall接口的对象。接口继承了IpMultiPartyCall接口的操作，引入一个新方法去设定一个呼叫认可的数据流量(以微秒测算)。当给定的数据量过期后，企业侧称IpAppMultiMediaCall的对应接口收到事件的通知。
接口IpMultiMediaCallLeg继承了IpCallLeg的所有操作，客户应用通过调用这个接口的方法能够监控和影响媒体信道。该接口提供了三个新的操作，其中一个是能够监控打开和关闭媒体信道，这又包括两种监控类型：一般监控(满足任何媒体类型)或指定监控(仅当使用指定媒体类型的信道才发送通知)。如果监控设置为中断模式，为打开这种媒体信道，应用必须显式地允许接入。IpMultiMediaCallLeg接口提供相应的方法，其引入的最新方法使得可以接入所有与这个呼叫Leg相关的已打开的媒体信道列表的方法(注意，一个呼叫Leg可与几个媒体信道相联系)。
在企业侧必须实现IpAppMuhiMediaCallLeg接口，它继承了父类IpAppCallLeg的方法。引入一个新的操作，即媒体信道通知，当打开或关闭满足请求的检测标准时，由Parlay网关调用。
多媒体呼叫控制包含的最后一个接口是IpMulfiMediaChannel，这个接口表现为与呼叫Leg联系的单向数据流。只有一个方法可用，即关闭信道。
4.会议呼叫控制控制
会议呼叫控制是ParlayAPI定义的最高级的呼叫控制形式。会议呼叫控制服务用会议和子会议的概念提升了多媒体呼叫控制服务。会议与多媒体、多方呼叫的不同点是会议资源可提前保留。子会议是会议中全部Legs的子集，只有在同一子会议中的Legs才能相互通信(即只有在同一子会议的Legs间才有媒体通路)。
有两种会议开始方式：没有会议资源的优先保留和有会议资源的优先保留。在会议呼叫控制服务中，有六个接口最重要：
·IpConfCallControlManager是必须用以生成会议和资源管理的接口。它继承了父类接口IpMultiMediaCallControlManager，但也增加了重要的新成员。该接口提供建立新会议及检测会议是否有足够的资源可用、为会议预留资源和释放分配资源的方法。当建立一个新的会议时，应用必须指明要用的子会议数目。它至少为1，会议参加者数目和预期的会议时长也在建立会议的请求时提供，网络随后尽力在指定的时间分配必要的资源。如果资源可用，会议开始。当会议时长超出了资源预留的时间，资源不再保证，但会议可以继续。注意，如果需要资源满足另外的请求，会议可能被网络结束或拒绝。
IpConfCallControlManager接口也提供检测在给定的预计时间是否有足够的资源可用的方法。调用此方法时，必须输入指定的开始和结束日期以及时间(代表搜索间隔)、可选的期望参加者数目和会议周期。搜索算法返回实际可利用的资源、会议时长和开始时间。注意此方法仍然没有保留资源。为了保留资源，IpConfCallControlManager接口提供了另一个方法。作为此方法的参数，必须制定开始的日期和时间，参加者数目和会议预期时长，以及会议指定的策略、内容、是否允许会议建立以后实体加入等。
IpConfCallControlManager接口提供的最后一个方法专为释放先前保留的资源，本方法有效地取消了资源预留。
·IpAppConfCallControlManager提供了当会议因先前的预约由网络建立时，Parlay网关调用的方法。它继承了IpAppMuhiMediaCallManager接口，除了以上描述的方法外，没有引入新的方法。
·lpConfCall接口继承了IpMuhiMediaCall接口，用以管理子会议，也可向不需要知道有多个子会议的应用隐藏子会议。除了继承的方法外，该接口提供了请求会议中所有子会议列表的新方法，以建立新子会议和请求监控事件。
·IpAppConfCall是相对于lpConfCall接口的企业侧接口。IpAppConfCall接口接收通过IpConfCall接口调用的请求的响应。它继承了父接口IpAppMultiMediaCall的方法，且提供了两个新方法。
首先，通过lpAppConfCall接口，提供当到达一个新的实体(和呼叫Leg)时的通知方法。例如可以用于计划会议(会议资源已经预留)，这里参加者使用资源预留期间提供的地址可以拨进会议(如果会议策略允许拨入)。
