Hello alexsunny123,

Would you be able to provide logs of a failed call? If so, please follow these instructions:

1. ce dlogon
2. ce dlogw > asm.log.alex1
3. make the call and let it fail
4. ctrl-c <to stop the ce dlogw command in step 2>
5. ce dlogoff
6. Attach the asm.log.alex1 log file to this thread.

If your goal is to NOT use CM, then we believe that it is not possible to use the duplicate the CM's group page feature where the caller can speak to multiple called parties by just using Breeze.

If, however, you wanted to play an announcement to multiple called parties, you could refer to the MultiChanBroadcast sample services to make one-party calls and use the OutgoingSipMessageListener (as described in the Breeze API) to add an "auto-answer" header to the outbound initial INVITES.

When sending a SIP request outbound, the following callback is made:

void sendingOut(SipRequest request, Participant targetParticipant)

You would then add a SIP header to the request:

request.addHeader("Answer-Mode", "Auto");


If, however, you still wanted to use CM, but NOT use CM group-page feature you could consider:

1. Caller calls a VDN on CM (through callIntercept on Breeze), or Caller calls a callable service on Breeze.
- If callable service, the services addParticipant(VDN).
2.Snapin possibly plays an announcement informing the caller that participants are being added?
3. Snapin invokes 2-party make call between VDN and called party. (Call VDN first) Use SipOutgoingMessageListener to add "auto-answer" header to outgoing SIP messages to called party.
- Repeat for all called parties.
4. Snapin possilbly plays an annoucement that all parties have been connected?
5. Caller can now speak to all called parties on speaker.

It would be helpful if you described the intended call scenario from the Breeze service's point of view.

For example:
Caller 'A' dials caller 'B'. Called 'B' includes Breeze in its terminating sequence. Breeze intercepts the call and plays an announcement to 'A'. Breeze then allows the call to proceed to 'B'. 'B' rings, etc.

or

The service is a callable service. Caller 'A' dials the callable service. Breeze receives the call. The service plays an announcement to 'A'. The service then adds called 'B'. Breeze dials 'B'. 'B' rings, etc.

or

The service dials caller 'A'. 'A' rings. 'A' answers'. The service plays an announcement to 'A'. The service dials called 'B'. 'B' rings. 'B' answers, etc.

Please be as descriptive as possible. When your issue below occurs, please be clear in what you expected to happen instead.

Thanks!

This is an innocuous 'ERROR' log that prints an exception stack trace. This occurs when Breeze is in the middle of processing some type of request previous to having had received a new inbound reINVITE.

I will look into changing this log to a different log level (other than ERROR) and removing the stack trace.

https://jira.forge.avaya.com/browse/ZEPHYR-68418

I sent you a private message. Let me know if you have received it. I have not sent one before.

Please provide updated logs, calling-from/called-to number, timestamp, etc, and your updated snapin code.

It might be helpful if you spell out, step by step, your actions and your expected events afterward.

MichaelNorman,

In the callIntercepted() method, you need to add 'call.suspend()' to prevent the call from proceeding to its original target. There is an implicit 'call.allow()' after callIntercepted() completes if it is not suspended.

Both traces (fail/pass) indicate that Breeze is instructing AAMS(Breeze's media server) to play a RINGBACK.wav towards the first caller.

The difference in the two traces is that for the failed scenario where the first party is a CM station, CM is sending a reINVITE w/o SDP to probably shuffle media off its local media resource, and in the pass scenario there is no CM and no reINVITE.

My best guess why you do not hear ringback is because CM, its media server, or the endpoint are not continuing to listen for the ring back media AAMS is playing towards it after CM decided to shuffle the media off its media resource.

We had an issue with a similar call scenario involving CM and Breeze 3.2 recently. They did not complain about not hearing ringback, but they did complain about the fact the called party (2nd party in the call) continuing to ring even after the first party hung up. I was able to look up the emails and JIRA about this issue since you mentioned seeing the same symptoms. The correct fix was for CM to address a bug on CM, but the involved teams decided that it would be simpler for Breeze to modify its behavior as a workaround. We have a patch for this issue. I have concluded that this patch should fix your 'continuous ringing' issue, and have a strong suspicion that it will fix your 'no ring back' issue as well.

I will try to see if we can send out this patch and update this thread with instructions on how to get it.

Lefteris,

Please provide a log of a single call failure.

ce dlogon
ce dlogw > asm.log.ringback-fail
-- perform the call where no ringback is heard --
ctrl-c (to stop the log collection)
ce dlogoff

Provide us with asm.log.ringback-fail

It would also probably be helpful to see the same trace where ringback is heard. Follow the same steps as above except perform the call where ringback is heard and name the file something like asm.log.ringback-pass.


Sean

The call termination policy 'ONE_PARTICIPANT_REMAINS means the call will drop when a 2 party call loses a participant and only one participant remains. Breeze will then drop the remaining participant.

Can you try to set the call termination policy to 'NO_PARTICIPANT_REMAINS' and see if that fixes your issue?

If that does not work, let us know and we will fix the issue. Setting the call termination policy to 'NO_PARTICIPANT_REMAINS' in addParticipantFailed() should work in my opinion. If this does not work, as a work around, try setting the call termination policy to 'NO_PARTICIPANT_REMAINS' in the call intercepted phase. You can change the call termination policy later after the added participant answers if you want.

RaymondGaston,

Can you also include the information Dinesh suggested you supply about the "Installation Details" found by pressing the "Installation Details" button in the Help -> About Eclipse popup? It would be good to know if 'm2e - Maven Integration for Eclipse' is installed.

It is my understanding that the JEE version of eclipse will include Maven Integration. If you used the standard version of Eclipse, you probably did not get Maven included and will have to download and install that yourself.

I resolved liu159's issues outside this thread.
I should have updated this thread after doing so.

1. liu159's snapin is making a 1Party makeCall. liu159 wanted to play an announcement to the party that answered the call. This worked when the snapin was installed on Breeze 3.0.
2. After upgrading Breeze to 3.1.1, the callAlerting(), nor callAnswered() call backs were not being invoked, so no announcement was played.
3. I informed liu159 they needed to add the following piece of code to set the media policy to INCLUDED before calling call.initiate().

call.getCallPolicies().setMediaServerInclusion(MediaServerInclusion.INCLUDED);

The following line of code suggested by Swapnil_Bhosale could have been used instead, but is deprecated.

call.enableMediaBeforeAnswer();

4. Things still did not work. The issue liu159 was now facing was addressed in a patch for 3.1.1 that liu159 did not have installed. Instead of instructing liu159 to install the latest patch for 3.1.1, I suggested they upgrade to 3.1.1.1.
5. The call proceeded further, but the party answering the call could not hear an announcement. I instructed liu159 to change their snapin code FROM playing the annc to call.getCalledParty() TO playing the annc to call.getAnswringParty(). I theorized that something downstream was causing the 'calledParty' to be different than the 'answeringParty'. This can happen in cases of downstream forking, or a far end that responds with a different user/domain in the provisional and final SIP responses.
6. The scenario finally worked.

liu159,

Please add the following line of code to your snapin BEFORE the code calling call.initiate();

call.getCallPolicies().setMediaServerInclusion(MediaServerInclusion.INCLUDED);

Let me know if this fixes your issues, and I can elaborate on the need for this line of code for others referencing this thread.

liu159,

I need the output logged to /var/log/Avaya/sm/asm.log.

If you are logged in as cust, I think you should be able to execute the command:

ce dlogon
ce dlogw > /home/cust/asm.log.liu159

If not can you attach the /var/log/Avaya/sm/asm.log file? It might be large. That was way I was hoping to get the output from 'ce dlogw > /home/cust/asm.log/liu159'.

Do you have root access? Is there any location on the server where you have write permission?

liu159,

Were you able to collect logs? You should be able to write to /tmp or to /home/cust.