1 / 19

iNOW! Interdomain Profile Test Scenarios

iNOW! Interdomain Profile Test Scenarios. Objective: Test scenarios and scoring for the Inter-domain Profile. CoChair: Terry L Anderson, Lucent Technologies tla@lucent.com. Domain A. GK. GW. GW. GW. Models. Clearing House. CH. or. Domain B. GK. GW. GW. GW.

jadzia
Télécharger la présentation

iNOW! Interdomain Profile Test Scenarios

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. iNOW! Interdomain ProfileTest Scenarios Objective: Test scenarios and scoring for the Inter-domain Profile CoChair: Terry L Anderson, Lucent Technologies tla@lucent.com

  2. Domain A GK GW GW GW Models Clearing House CH or Domain B GK GW GW GW Clearing House or Peer

  3. Scope • Interoperability between administrative domains or between administrative domains and a clearinghouse. Not within an administrative domain (between gateway and gatekeeper) • Thus the units of test in these scenarios are: • Administrative Domains – consisting of an endpoint (gateway or terminal), a gatekeeper and a border element. Two or more of these entities may be in a single host system. • Clearinghouse • All entities in a single unit of test will be supplied by a single team referred to as participant.

  4. Scope - con’t • This document is not intended to provide an exhaustive testing of all facets of iNOW! operation. Specific scenarios were chosen to provide coverage of the more common commercial deployments of the iNOW! V2 Interdomain profile.

  5. Test Profiles • A profile specifies a set of configuration options for a call. Addressing Comments • 1 Audio G.711 E.164 • 2 Audio G.729A E.164 • 3 Audio G.723.1 E.164 • 4 Fax T.38 / UDP E.164

  6. Scenario 1 - Peers

  7. Scenario 1 Steps • 1. Establish service relationship (optional) • 1.1. The border element (BE1) in administrative domain 1 (AD1) optionally established a service relationship with the border element (BE2) in administrative domain 2 (AD2) by sending ServiceRequest. • 1.2. BE2 returns ServiceConfirmation to BE1 if itreceives ServiceRequest.

  8. AD1 calls AD2 • 2.1. AD1 has a call that it wishes to terminate in AD2. The test is not concerned with the events inside the AD but it may have arrived at this state by: • 2.1.1. Endpoint 1 obtaining called party number from the user and optionally a userId and pin • 2.1.2. If AD1 is using Direct Call Signaling model (DCS): Endpoint 1 sending ARQ to Gatekeeper 1, who optionally authenticates the user and attempts to select an endpoint to terminate the call. Not finding a suitable endpoint in AD1 it chooses to attempt to terminate the call with AD2. • 2.1.3. Or if AD1 is using the Gatekeeper-routed Call Signaling model (GRCS): Endpoint 1 sending ARQ to GK1 which optionally authenticates the user and returns its own Call Signaling Address to endpoint 1. Endpoint 1 then sends Setup to GK1 who attempts to select another endpoint to terminate the call. Not finding a suitable endpoint in AD1 it chooses to attemptto terminate the call with AD2.

  9. AD1 calls AD2: AccessRequest • 2.2.1. AD1’s Border Element (BE1) sends AccessRequest to the Border Element of AD2 (BE2) at the AnnexG address known from configuration using UDP. • 2.2.2. Optionally, if BE1 did not send ServiceRequest to establish a service relationship, BE2 might reject the AccessRequest with an AccessReject and AccessRejectReason of noServiceRelationship. If BE1 receives this is sends ServiceRequest, receives ServiceConfirmation and repeats the AccessRequest. • 2.2.3. BE2 decides to accept the request and returns one or more AddressTemplates in AccessConfirm. Each AddressTemplate will contain a RouteInformation with messageType set to sendSetup and contain a CallSigAddr. How this CallSigAddr is chosen is not the concern of the test. BE2 might have selected an endpoint and return the CallSigAddr of the endpoint to use in a Direct Call Signaling model or it might return the CallSigAddr of a gatekeeper in AD2 for use in a Gatekeeper-Routed Call Signaling model. Type in RouteInformation will indicate whether the CallSigAddr points to a GW or a GK. • Note: iNOW does not permit the use of other messageTypes in RouteInformation, for example, sendAccessRequest. • 2.2.4. BE1 receives the AccessConfirm.

  10. AD1 calls AD2 - pt 3 • 2.3. AD1 initiates call signaling using fast connect proceedures. Which entity in AD1 uses the CallSigAddr is not the concern of this test. BE1 might be a gatekeeper using Gatekeeper-routed Call Signaling model and directly send Setup or it might be a gatekeeper using Direct Call Signaling and return an ACF to the originating endpoint so that the endpoint will send Setup. • 2.4. Call signaling continues and a call is established. • 2.5. Endpoint in AD2 terminates the call by sending ReleaseComplete • 2.6. BE1 sends BE2 UsageIndication if it was requested in AccessConfirmation for this route. • Note: Only Clearinghouses are required to requrest a UsageIndication, but BEs must send one if they use a template that asks for one.

  11. Scenario 1 -end • 3. AD2 calls AD1 in same way (3.1-3.6). • 4. AD1 calls AD2 with an unknown E.164 address • 4.1. AccessRequest • 4.1.1. BE1 sends AccessRequest with a destinationInfo containing an E.164 address unknown to BE2. • 4.1.2. BE2 returns AccessRejection with AccessRejectionReason of noMatch. • 4.2. AD1 releases call • 5. AD2 calls AD1 with an unknown E.164 address as above (5.1-5.2).

  12. Scoring • New score sheet has separate rows for domain A originating and for domain B originating. • Use 1 if an element played its role properly for each column, eg, sent ARQ (originating) or sent ACF or ARJ (terminating). • Use 0 if it did not perform role • Use x if untested due to previous failure

  13. Scenario 2 - Clearinghouse

  14. Scenario 2 Steps pt 1 • 1. BE1 establishes service relationship with CH (not optional) • 1.1. The border element (BE1) in administrative domain 1 (AD1) establishes a service relationship with the clearinghouse (CH) by sending ServiceRequest. • 1.2. CH returns ServiceConfirmation to BE1 and sends ServiceRequest to BE1 to establish a service relationship in the other direction. • 1.3. BE1 returns ServiceConfirmation to CH. • 2. BE2 establishes service relationship with CH in same way

  15. AD1 calls AD2 • 3.1. AD1 has a call that it wishes to terminate by using the CH. The test is not concerned with the events inside the AD but it may have arrived at this state by: • 3.1.1. Endpoint 1 obtaining called party number from the user and optionally a userId and pin • 3.1.2. If AD1 is using Direct Call Signaling model (DCS): Endpoint 1 sending ARQ to Gatekeeper 1, who optionally authenticates the user and attempts to select an endpoint to terminate the call. Not finding a suitable endpoint in AD1 it chooses to attempt to terminate the call using the CH. • 3.1.3. Or if AD1 is using the Gatekeeper-routed Call Signaling model (GRCS): Endpoint 1 sending ARQ to GK1 which optionally authenticates the user and returns its own Call Signaling Address to endpoint 1. Endpoint 1 then sends Setup to GK1 who attempts to select another endpoint to terminate the call. Not finding a suitable endpoint in AD1 it chooses to attempt to terminate the call with using the CH.

  16. AD1 calls AD2 - Access Request • 3.2.1. AD1’s Border Element (BE1) sends AccessRequest to the CH at the AnnexG address known from configuration using UDP. • 3.2.2. CH selects AD2 to terminate the call and sends AccessRequest to the BE2. • 3.2.3. BE2 decides to accept the request and returns one or more AddressTemplates in AccessConfirm. Each AddressTemplate will contain a RouteInformation with messageType set to sendSetup and contain a CallSigAddr and a terminationToken. How this CallSigAddr is chosen is not the concern of the test. BE2 might have selected an endpoint and return the CallSigAddr of the endpoint to use in a Direct Call Signaling model or it might return the CallSigAddr of a gatekeeper in AD2 for use in a Gatekeeper-Routed Call Signaling model. Type in RouteInformation will indicate whether the CallSigAddr points to a GW or a GK. • Note: iNOW does not permit the use of other messageTypes in RouteInformation, for example, sendAccessRequest which would instruct BE1 to communicate directly with BE2. • 3.2.4. CH sends AccessConfirm to BE1 with the AddressTemplate received from BE2, adding clearinghouse token and setting usageSpec to require UsageIndication. • 3.2.5. BE1 receives the AccessConfirm.

  17. AD1 calls AD2 - Access Request - pt2 • 3.3. AD1 initiates call signaling using fast connect proceedures. Which entity in AD1 uses the CallSigAddr is not the concern of this test. BE1 might be a gatekeeper using Gatekeeper-routed Call Signaling model and directly send Setup or it might be a gatekeeper using Direct Call Signaling and return an ACF to the originating endpoint so that the endpoint will send Setup. • 3.4. Call signaling continues and a call is established. • 3.5. Endpoint in AD2 terminates the call by sending ReleaseComplete • 3.6. BE1 sends CH UsageIndication. • 3.7. BE2 sends CH UsageIndication.

  18. Scenario 2 - last • 4. AD2 calls AD1 in same way (4.1-4.7). • 5. AD1 calls AD2 with an unknown E.164 address • 5.1. AccessRequest • 5.1.1. BE1 sends AccessRequest with a destinationInfo containing an E.164 address unknown to BE2. • 5.1.2. BE2 returns AccessRejection with AccessRejectionReason of noMatch. • 5.2. AD1 releases call • 6. AD2 calls AD1 with an unknown E.164 address as above (6.1-6.2).

  19. Example Test • Note: The score sheet on the following page shows an example of a test of Scenario 2. Option #2 of the scenario is being used where the Clearinghouse directs calls back to the originating Administrative Domain. Thus the AD is both originating and terminating and Endpoints A and B, Gatekeepers A and B, and Border Elements A and B are listed as the same systems and same Company being tested. The separate lines score its behavior in each role. The BE fails to establish a Service Relationship (even though Scenario 2 requires it) and so receives a ‘0’. Because of this the Clearinghouse is untested for this element and receives an ‘x’. The CH accepts the AccessRequest without the service relationship and so the test can continue. BE only sends a UsageIndication when it was the originating AD (even though the CH requested it) and so BE receives a ‘1’ in one case and a ‘0’ in the other for each call direction. The CH is only partially tested since only 1 UsageIndication was sent so it receives a ‘1’ in one case and an ‘x’ in the other.

More Related