Avaya CM <-> SES <-> Asterisk - SIT Tones &

Asterisk Asterisk Support
1

We have successfully configured Asterisk to interconnect with an Avaya CM via SES, more details on how this is done here:

avaya.co.uk/emea/en-us/re…terisk13AN.pdf

Now, there are two edge cases that we are trying to work on to get this fully functional in all use cases. These are:

  1. Dialing outbound (Asterisk -> SES -> CM -> ISDN/PSTN) when a SIT Tone is reached (ie - disconnected or number changed message) we only hear silence on the Asterisk side and then a ‘Temporarily Unavailable’ message once the message has completed playback from the ISDN network. The reason is that Answer Supervision is never taken, so the call is never answered so Asterisk hears silence (or plays ringing if instructed in the dial cmd). The issue is that we want the caller on Asterisk to hear the message so they know if it is disconnected or changed and may update their database. The thing to keep in mind is that the extension/station dial to the calling party is over the SES to an Avaya station/handset, and this is when it may not be heard. The SIT tone may be heard if dialed with a SIP/Xlite extension right off of Asterisk.

Any ideas on this?

  1. Dialing inbound (ISDN/PSTN -> CM -> SES -> Asterisk) to a station, we hear silence until the call is picked up. How may we ensure the SES delivers ringing so the caller has a ‘normal’ experience? I know that Answering/Ringing in the dialplan of Asterisk is an option, but not preferred in this scenario.

Any insight from anyone on these points would be greatly appreciated. Thanks!

2

I’m assuming that Asterisk <-> SES is SIP.

There should never be answer supervision for SIT type responses. To the extent that we are talking SIP, a SIP Progress message should be sent, to indicate that there are in-band indications. If that is being sent, (please use sip debug or sip set history), Asterisk is behaving properly and the upstream switch is at fault.

However, if you cross technology boundaries, there can be complications, e.g. in crossing to QSIG, once ringing has been sent, the RFCs require in band indications to be ignored. You can also have problems in crossing to a public network, as such networks will not propagate in band progress signals from end users, as that would allow users to provide one way calls free of charge.

For your second point, Asterisk should send SIP RInging. If it does so, it has fulfilled its responsibilities, and you need to look a the other switch.

3

You are correct on all counts. I verified the SIP aspect of this by doing:

ISDN PSTN <-> Avaya CM <-> Avaya SES <-> Asterisk <-> SIPPhone <-> Gizmo5

And, the SIT tone came through just fine without Answer Supervision from the ISDN network. So, it appears to be something on the Avaya CM/SES when I try to push it to an Avaya station as opposed to Gizmo5.

[quote=“david55”]I’m assuming that Asterisk <-> SES is SIP.

There should never be answer supervision for SIT type responses. To the extent that we are talking SIP, a SIP Progress message should be sent, to indicate that there are in-band indications. If that is being sent, (please use sip debug or sip set history), Asterisk is behaving properly and the upstream switch is at fault.

However, if you cross technology boundaries, there can be complications, e.g. in crossing to QSIG, once ringing has been sent, the RFCs require in band indications to be ignored. You can also have problems in crossing to a public network, as such networks will not propagate in band progress signals from end users, as that would allow users to provide one way calls free of charge.

For your second point, Asterisk should send SIP RInging. If it does so, it has fulfilled its responsibilities, and you need to look a the other switch.[/quote]