cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1823
Views
5
Helpful
23
Replies

CME not forwarding external calls to CUE voicemail

PaulBunyanTech
Level 1
Level 1

I have an issue with our voicemails on Unity Express that are not working form external calls. When I call into our system using an external number my phone will ring correctly but when it should go to voicemail all I hear is just dead air. But when I call to my extension from another extension the voicemail works fine. Our CME is version 12.0 and CUE is Verison 8.6.7. any advice is greatly appreciated.

23 Replies 23

Dennis Mink
VIP Alumni
VIP Alumni

sounds like a routing issue where RTP is not able to set up voice between the two IP addresses.

 

can you provide the debug ccsip messages out put of you are using Sip. or else tell us how the RTP stream is set up (source and destination)

 

 

Please remember to rate useful posts, by clicking on the stars below.

the output is 

v=0
o=CiscoSystemsSIP-GW-UserAgent 5813 1122 IN IP4 192.168.170.1
s=SIP Call
c=IN IP4 172.87.10.120
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.87.10.120

000461: *Mar 29 04:16:55.747: //3986/D9BC38548ECD/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK67ab.b4a0c138cda05692cd54fc9f35a95dc2.0,SIP/2.0/UDP 52.40.141.109:5060;branch=z9hG4bK8313036
From: sip:ping@invalid;tag=uloc-5a1c4ca6-24-33bfe071-5f400856-1fdeed35
To: sip:402@172.87.10.120:1428;tag=A07FB0-12BC
Date: Thu, 29 Mar 2018 04:16:55 GMT
Call-ID: 061bb1c-ec2b90e3-05afce1@0.0.0.0
Server: Cisco-SIPGateway/IOS-15.7.3.M1
CSeq: 1 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 170

v=0
o=CiscoSystemsSIP-GW-UserAgent 8063 1621 IN IP4 192.168.170.1
s=SIP Call
c=IN IP4 172.87.10.120
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.87.10.120

000462: *Mar 29 04:16:55.751: //3987/D9BC38548ECE/SIP/Msg/ccsipDisplayMsg:
Sent:

000470: *Mar 29 04:16:57.459: //3995/DAA7353E8ED6/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:500@192.168.170.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.170.1:5060;branch=z9hG4bK25362F
From: "PB TECHNOLOGIES" <sip:+16513561066@sip.flowroute.com>;tag=A085B8-17B4
To: <sip:500@192.168.170.2>
Date: Thu, 29 Mar 2018 04:16:57 GMT
Call-ID: DAA7D166-323E11E8-8EDAE014-44FCC6DE@192.168.170.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3668391230-0842928616-2396446740-1157416670
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M1
Allow: INVITE, OPTIONS, BYE, Cisposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 3521 5507 IN IP4 192.168.170.1
s=SIP Call
c=IN IP4 172.87.10.120
t=0 0
m=audio 16420 RTP/AVP 0 101
c=IN IP4 172.87.10.120
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

000477: *Mar 29 04:16:58.243: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:500@192.168.170.2:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.170.1:5060;branch=z9hG4bK255215B
From: "PB TECHNOLOGIES" <sip:+16513561066@sip.flowroute.com>;tag=A085B8-17B4
To: <sip:500@192.168.170.2>;tag=ds948d99d6
Date: Thu, 29 Mar 2018 04:16:57 GMT
Call-ID: DAA7D166-323E11E8-8EDAE014-44FCC6DE@192.168.170.1
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M1
Max-Forwards: 70
Timestamp: 1522297018
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=18,OS=2880,PR=29,OR=4481,PL=0,JI=0,LA=0,DU=0
Session-ID: f9ecc0e9c75458039d2d5ff42400e886;remote=8409612e14145a06bf4150b7a1bfedc8
Content-Length: 0


000484: *Mar 29 04:17:13.971: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:16519643771@172.87.10.120:1177 SIP/2.0
Record-Route: <sip:216.115.69.144;lr>
Max-Forwards: 67
Record-Route: <sip:216.115.69.132;lr>
From: "PB TECHNOLOGIES" <sip:+16513561066@fl.gg;isup-oli=00>;tag=gK001f25e8
To: <sip:+16519643771@fl.gg>;tag=A05EA4-14FD
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKab96.4938b03c793a270b2922934e0cfa59f4.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKab96.560cf839fcf87640819ff6f226d2d01d.0
Via: SIP/2.0/UDP 74.120.93.200:5060;branch=z9hG4bK00B714464c9f12ba24a
Call-ID: 1212193536_128347402@74.120.93.200
CSeq: 725551 BYE
Content-Length: 0


000485: *Mar 29 04:17:13.971: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKab96.4938b03c793a270b2922934e0cfa59f4.0,SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKab96.560cf839fcf87640819ff6f226d2d01d.0,SIP/2.0/UDP 74.120.93.200:5060;branch=z9hG4bK00B714464c9f12ba24a
From: "PB TECHNOLOGIES" <sip:+16513561066@fl.gg;isup-oli=00>;tag=gK001f25e8
To: <sip:+16519643771@fl.gg>;tag=A05EA4-14FD
Call-ID: 1212193536_128347402@74.120.93.200
CSeq: 725551 BYE
Content-Length: 0

 

Our CUE is on IP 192.168.170.2

As Dennis mentioned, this is mostly due to routing issue between the IP's involved. Please share complete messages for ccsip debug.  is it a PRI or SIP ? What are the IP address's of CME, CUE ?

Share your CME config and a debug ccsip message in a text file. The shared debugs are incorrect.
Also check if you have "media flow-around" configured under voice service voip or not.

We are using a SIP trunk for our main numbers and 1 PSTN line for 1 number. Our IP of CME is 192.168.170.1 and the IP of CUE is 192.168.70.2. 

 

I have attached our running-config and the output of debug ccsip messages when i was calling in. 

I also did another test and got this

PaulBunyanTech-VoiceServer#
003228: *Mar 30 03:19:04.837: voip_rtp_allocate_port:Possible port leak? callID(39672), port(16456) socket(0x0)

Hi,

In your debug I see that your provider is negotiating g729 while the CUCME is trying to contact the Unity Express using G711ulaw.

Please try to configure codec G711ulaw on your incoming dialpeer.

If it works, you should consider to configure a transcoder resource on your CME.

 

 

Please let me know 

 

 

HTH

 

Regards

 

Carlo

Please rate all helpful posts "The more you help the more you learn"

I have configured the G711ulaw on my inbound dialing peer but I'm have still getting dead air when it hits the unity express

Hi,

Can you please activate a debug ccsip messages while you have g711ulaw configured on your inbound diapeer?

Please post the result here

 

 

Thanks

 

Regards

 

 

Carlo

 

Please rate all helpful posts "The more you help the more you learn"

Here is updated debug ccsip message and running-config

Hi,

INVITE sip:16519643771@172.87.10.120:1094 SIP/2.0

Record-Route: <sip:216.115.69.144;lr>

From: "PB TECHNOLOGIES" <sip:+16513561066@fl.gg;isup-oli=00>;tag=gK0008eb2b

Max-Forwards: 66

Record-Route: <sip:216.115.69.132;lr>

To: <sip:+16519643771@fl.gg>

Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKa81d.f6708eed67ca70cb61cc6aa899ce56e2.0

Via: SIP/2.0/UDP 54.71.6.127:5060;branch=z9hG4bKa81d.6984fd24650d72ebb862d453b3be9c95.2

Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKa81d.047d369bb42962f55ef913d21f9b724c.0

Via: SIP/2.0/UDP 74.120.93.200:5060;branch=z9hG4bK00B74372aacc4070ce6

Call-ID: 1077975299_83728909@74.120.93.200

CSeq: 689530 INVITE

Contact: <sip:+16513561066@74.120.93.200:5060>

Session-Expires: 1800

Min-SE: 90

Content-Length:   223

Content-Type: application/sdp

P-Asserted-Identity: "PB TECHNOLOGIES" <sip:+16513561066@fl.gg>



v=0

o=- 286340 175767 IN IP4 74.120.93.202

s=-

c=IN IP4 74.120.93.202

t=0 0

m=audio 14218 RTP/AVP 0 8 18 101

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no



As you can see, your provider is still requesting to negotiate g729 codec.
You have two options:
1 - Ask them to use G711 codec
2 - Add a transcoder resources to your CME is you have enough DSP to configure it.


HTH

Please Let Me Know


Regards

Carlo
Please rate all helpful posts "The more you help the more you learn"

Thanks for the info. I have tried adding transcoder but it still requesting g729 codec and is not transcoding. But I'm also not sure if the config for the transcoder is correct. I have attached the current config. I also have a ticket in with my provider to see if I can get them to change to g711 or give me some more information. I'm not a voice expert but know enough to be dangerous. 

I think I have the issue with CUE fixed I had to downgrade my IOS version and now calls are going to cue correctly using the sip trunk. but now I also have a new issue that when I call one of my sip trunk numbers it will work normally once or twice. but most of the time it will do a half ring on a phone once and then will say "The number is not in service" or won't even ring the phone. it almost seems like it is not hanging up the call that did work.  This has been just a nightmare to get working correctly, Now I'm wishing I had never upgraded my CME/CUE hardware.  

Hi,

Which call is not working? To CUE or to an IP Phone?

Is your  CUCME  behind nat?

 

Under voice service voip —> SIP

add

early-offer forced 

and

asymmetric payload full

 

After that, please post the output of a debug ccsip messages while a non working call.

Please also post your actual running config

 

Thanks

 

Regards

 

Carlo

 

Please rate all helpful posts "The more you help the more you learn"