Was wondering if anyone has come across this issue in deploying vpn'less Jabber with Expressway E and C deployment. All internal calls generate a ringback tone, but dialing externally there is dead air till the call connects. Our deployments are straightforward and there is ringback on all calls when connected via the vpn or internally with jabber. This happens on both sip and pri calls. Any help is much appreciated.
Yes in every deployment all the jabber devices have the correct MRGL with annunciators in the device pool and even on the device itself.
I have smilar problem with my MRA deployment. Expressway version : 8.9
Some of outgoing calls does not provide ringbacktone via MRA.
TCT client associated MRGL (ıts contain annonciator.)
I upload working and non-working scnerio logs on attached.
Expressway-E-->Expressway-C--> CUCM--> Sip trunk--> SBC
Had a similar problem.
My solution was to changing the dial-peers on my pstn gateway (ISDN) connected to cucm via sip trunk. Unfortunately I don't know what I configured exactly... :/
The Config looks like:
voice call send-alert
voice call disc-pi-off
voice call convert-discpi-to-prog
voice service voip
ip address trusted list
ipv4 x.x.x.x 255.255.255.0
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h225-notify cid-update
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
h225 signal overlap
call preserve limit-media-detection
modem passthrough nse codec g711alaw redundancy
bind control source-interface BVI10
bind media source-interface BVI10
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 ilbc
codec preference 4 g729r8
voice class sip-profiles 1
response 183 sip-header Remote-Party-ID remove
response 200 sip-header Remote-Party-ID remove
response 180 sip-header Remote-Party-ID remove
dial-peer voice 10 pots
translation-profile outgoing topstn
progress_ind alert strip
dial-peer voice 200 voip
progress_ind setup enable 3
session protocol sipv2
session target ipv4:x.x.x.x
voice-class codec 1
dtmf-relay rtp-nte sip-kpml sip-notify
ip qos dscp cs3 signaling
Expressway does not support Early Offer audio at this point of time
Unsupported features (general)
-- DTLS is not supported through the Expressway- C/Expressway-E; attempts to make secure calls will fail
-- SIP Early Media
-- SIP KeyPad Markup Language (KPML)
Correct SIP Early Media is not supported on the Expressway series devices. I have however corrected the issue with my call flow. Each call flow will have a different resolution.
MRA Device >> Expressway-E >> Expressway-C >> CUCM Cluster 1 >> SIP >> CUCM SME Cluster >> MGCP >> MGCP ISDN PRI.
Basically all I did was disable option "SIP REL1XX" on the SIP trunk between CUCM Cluster 1 and the CUCM SME Cluster. Now my MRA endpoint receives a 180 Ringing message instead of a 183 with SDP. The end result is that the MRA user hears ringing.
The drawback is that you wont get early media from the telco provider that typically provide informational messages to the caller. I like the drawback better than not getting ringing at all.
Nick, I'm not sure if you're still having this issue or not.
If you still do not have ringback from your MRA registered devices.. Can you run a debug on your VCSc (with PCAP) and determine how the ringing message is being delivered to the VCSc? I'm guessing you'll find a 183 with SDP for ringing which you'll find coming inbound from a CUCM node and it wont be forwarded to the VCSe.
Please post your findings (screen shots or even the entire pcap).