We have been working on Avaya ACE webservices . When we make a call from 20071 to 20073, we are able to get session id as follows,

Request Message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<makeCallSession xmlns="http://www.csapi.org/schema/parlayx/third_party_call/v3_4/local">
<callParticipants>sip:20071@avaya.com</callParticipants>
<callParticipants>sip:20073@avaya.com</callParticipants>
<changeMediaNotAllowed>false</changeMediaNotAllowed>
<reference>
<endpoint xmlns="">http://10.10.101.14:5823/CallNotification</endpoint>
<interfaceName xmlns="">ACEExhibitor</interfaceName>
<correlator xmlns="">CallNtf-206152319</correlator>
</reference>
</makeCallSession>
</soapenv:Body>
</soapenv:Envelope>


Response message From Avaya:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<loc:makeCallSessionResponse xmlns:loc="http://www.csapi.org/schema/parlayx/third_party_call/v3_4/local">
<loc:result>a6011bc4-f5f0-4893-8408-b43f254dbda2</loc:result>
</loc:makeCallSessionResponse>
</soapenv:Body>
</soapenv:Envelope>





But in the notification response we receive the call participant status as "CallParticipantTerminated" given below follows, This also happens when try to check the status of session Id.

Notification Send By the Avaya ACE:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<notifyParticipantEvent xmlns="http://www.csapi.org/schema/parlayx/call_notification/v3_8/local">
<correlator>CallNtf-206152319</correlator>
<callSessionIdentifier>a6011bc4-f5f0-4893-8408-b43f254dbda2</callSessionIdentifier>
<callParticipantInformation>
<callParticipantIdentifier xmlns="">sip:20071</callParticipantIdentifier>
<callParticipantStatus xmlns="">CallParticipantTerminated</callParticipantStatus>
<callParticipantStartTime xmlns="">2012-06-19T10:26:39.516-04:00</callParticipantStartTime>
<callParticipantDuration xmlns="">0</callParticipantDuration>
<callParticipantTerminationCause xmlns="">CallParticipantAborted</callParticipantTerminationCause>
</callParticipantInformation>
<callParticipantInformation>
<callParticipantIdentifier xmlns="">sip:20073@avaya.com</callParticipantIdentifier>
<callParticipantStatus xmlns="">CallParticipantTerminated</callParticipantStatus>
<callParticipantStartTime xmlns="">2012-06-19T10:26:39.540-04:00</callParticipantStartTime>
<callParticipantDuration xmlns="">0</callParticipantDuration>
<callParticipantTerminationCause xmlns="">CallParticipantAborted</callParticipantTerminationCause>
</callParticipantInformation>
</notifyParticipantEvent>
</soapenv:Body>
</soapenv:Envelope>

Can you log into the ACE Web GUI and navigate Configuration->Service Providers. Then select the "Rule Validation" tab, and Third Party Call (v3) in the pull down.

Enter sip:20071@avaya.com and sip:20073@avaya.com into the URI fields. Press validate. What do your matching provider rules look like?

For some reason it looks like the domain is being stripped off the "sip:20071" number.

John.

Can you log into the ACE Web GUI and navigate Configuration->Service Providers. Then select the "Rule Validation" tab, and Third Party Call (v3) in the pull down.

Enter sip:20071@avaya.com and sip:20073@avaya.com into the URI fields. Press validate. What do your matching provider rules look like?

For some reason it looks like the domain is being stripped off the "sip:20071" number.

John.

I ran some tests with rule validation in the ACE Web Service remote labs. The reverse transformation was stripping off the domain. I made a change and it should be working better now. Please run another test and post your results.

Still, I experiencing the same problem.

The reverse transformation rules would explain the issue in the notification, but not the reason for call failure. Can you dial between the phones from the soft client?

Hi Parthiban,

How did you login to the two endpoints (sip:20071@avaya.com and sip:20073@avaya.com)? Are you using Avaya One-X SIP Emulator, Avaya Communicator, or IP Phone? Are you able to make calls directly between the two endpoints once logged in?

I just tested your endpoints in the Remote Lab and they are working for me.

Dipesh

The extensions are configured in the Avaya Devconnect's remote lab. i am not sure how it is configured, but we tried using X-Lite softphones with the extension number and password given to us. Connected over VPN to the remote lab, we are able to login using the soft phones and are able to place and receive calls between these two extensions manually. but when the call is made from the ACE Exhibitor, we get this error. We tried

Thanks

Dipesh

We are using the ACEExhibhitor tool to make calls. When i make test calls using TPCCV2 between two SIP extensions, the call is placed and i get a session id. but when i do a GetCallInfo (TPCC V2), I get a CallingPartyNoAnswer error code.

When i do a "EndCall', i get "The callIdentifier 3a383a7c-557a-4113-b6d6-c679a0dde1c2 is invalid" error.

Please find the messages that went to and from the ACEExhibitor:

Outbound Message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<makeCall xmlns="http://www.csapi.org/schema/parlayx/third_party_call/v2_3/local">
<callingParty>sip:20072@avaya.com</callingParty>
<calledParty>sip:20073@avaya.com</calledParty>
</makeCall>
</soapenv:Body>
</soapenv:Envelope>


Inbound message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<loc:makeCallResponse xmlns:loc="http://www.csapi.org/schema/parlayx/third_party_call/v2_3/local">
<loc:result>3a383a7c-557a-4113-b6d6-c679a0dde1c2</loc:result>
</loc:makeCallResponse>
</soapenv:Body>
</soapenv:Envelope>


Outbound Message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getCallInformation xmlns="http://www.csapi.org/schema/parlayx/third_party_call/v2_3/local">
<callIdentifier>3a383a7c-557a-4113-b6d6-c679a0dde1c2</callIdentifier>
</getCallInformation>
</soapenv:Body>
</soapenv:Envelope>


Inbound message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<loc:getCallInformationResponse xmlns:loc="http://www.csapi.org/schema/parlayx/third_party_call/v2_3/local">
<loc:result>
<callStatus>CallTerminated</callStatus>
<startTime>2012-06-29T04:02:07.059-04:00</startTime>
<duration>0</duration>
<terminationCause>CallingPartyNoAnswer</terminationCause>
</loc:result>
</loc:getCallInformationResponse>
</soapenv:Body>
</soapenv:Envelope>


Outbound Message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<endCall xmlns="http://www.csapi.org/schema/parlayx/third_party_call/v2_3/local">
<callIdentifier>3a383a7c-557a-4113-b6d6-c679a0dde1c2</callIdentifier>
</endCall>
</soapenv:Body>
</soapenv:Envelope>


Inbound message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>AgileCE service exception</faultstring>
<detail>
<v2:ServiceException xmlns:v2="http://www.csapi.org/schema/parlayx/common/v2_1">
<messageId>SVC0002</messageId>
<text>Invalid input value for message part %1</text>
<variables>callIdentifier. The callIdentifier 3a383a7c-557a-4113-b6d6-c679a0dde1c2 is invalid</variables>
</v2:ServiceException>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>


Thanks

Dipesh

I believe, the issue could be because of no extensions associated with the user that we have.

We have an user ArlUser7 which doesnt have any associated extensions, which we found from the Personal Assistant web page.

Thanks

That would explain it. ACE will give you a call ID if the call server accepts the call. If the call server later determines that the called party is unavailable the call will fail. In the case of TPCv3 using SIP, we give you a call ID once we know the addresses are routable. The call may still fail if the endpoints are not registered.

John.

Thanks John.

I dont find any option to add the devices to the ACE User. Should I reach out to Remote Lab support?

Oops, I misread your response. If you are specifying the sip URI directly in the request, which you are, then you do not need to have them provisioned against the user in ACE user profile. That is only needed if you are using the "ace:" URI.

The reason your called failed was due to the error "CallingPartyNoAnswer". This means that the calling party did not answer the phone. So this can be caused by a few different things:

1. You didn't answer the phone. Can I assume your soft client didn't ring? You need to answer the call before the second leg will proceed.

2. Your phone is registered with SM but for some reason it cannot accept incoming calls (config/network issue).

John.

When I place calls between two softphones, it works. When I use ACE to make calls between two end points that i configured on the soft phones, i get this error.

The soft phones testing and the ACE Web service testing are done over a VPN connected to the remote lab.

We will need to coordinate a time for you to run the test so we can collect some tracing in the lab. Please open a ticket on the Devconnect website so that we can set something up.