09-18-2014 01:52 PM - edited 03-17-2019 12:13 AM
I've run into an issue where callers coming from the PSTN do not hear ringback after being transferred using a Cisco Unity call handler.
Ringback works internally between phones, and also works internally if I dial the call handler DN and request a transfer.
Call flow is this: SIP Provider -> CUBE -> SIP Trunk -> CUCM -> Unity Connection (SCCP)
The caller just hears dead air until the phone is picked up, or it bounces to voicemail.
There is an MRGL assigned to the SIP trunk to CUBE that contains an announciator and MoH.
The weird thing is the caller does hear about a second of MoH when Unity begins the transfer, but nothing after that.
debug ccsip messages:
1111111111 is the called party/number, 2222222222 is the calling number (my cellphone)
000925: Sep 18 14:08:06.696 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>
Contact: <sip:2222222222@208.43.85.75>
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Date: Thu, 18 Sep 2014 20:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 361
v=0
o=root 1022 1022 IN IP4 208.43.85.75
s=session
c=IN IP4 208.43.85.75
b=CT:384
t=0 0
m=audio 11300 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 14308 RTP/AVP 34 99
a=rtpmap:34 H263/90000
a=rtpmap:99 H264/90000
a=sendrecv
000926: Sep 18 14:08:06.708 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:700@10.135.191.12:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
Remote-Party-ID: "2222222222" <sip:2222222222@172.18.0.1>;party=calling;screen=no;privacy=off
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1453513609-1051070948-2183255881-0835455271
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1411070886
Contact: <sip:2222222222@172.18.0.1:5061;transport=tls>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 394
v=0
o=CiscoSystemsSIP-GW-UserAgent 6324 6685 IN IP4 172.18.0.1
s=SIP Call
c=IN IP4 172.18.0.1
t=0 0
m=audio 16420 RTP/AVP 0 101
c=IN IP4 172.18.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 16422 RTP/AVP 34 119
c=IN IP4 172.18.0.1
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=000000
000927: Sep 18 14:08:06.712 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Content-Length: 0
000928: Sep 18 14:08:06.716 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
000929: Sep 18 14:08:06.728 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "Cisco Unity" <sip:800@10.135.191.12>
Remote-Party-ID: "Cisco Unity" <sip:800@10.135.191.12>;party=called;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>
Content-Length: 0
000930: Sep 18 14:08:06.732 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Cisco Unity" <sip:800@184.71.242.2>;party=called;screen=yes;privacy=off
Contact: <sip:700@184.71.242.2:5060>
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Content-Length: 0
000931: Sep 18 14:08:06.804 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Require: timer
P-Asserted-Identity: "Cisco Unity" <sip:800@10.135.191.12>
Remote-Party-ID: "Cisco Unity" <sip:800@10.135.191.12>;party=called;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>;isFocus
Content-Type: application/sdp
Content-Length: 406
v=0
o=CiscoSystemsCCM-SIP 6169 1 IN IP4 10.135.191.12
s=SIP Call
c=IN IP4 10.135.191.12
b=TIAS:64000
b=CT:64
b=AS:64
t=0 0
m=audio 25280 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 0 RTP/AVP 31 34 96 97
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
a=rtpmap:96 H263-1998/90000
a=rtpmap:97 H264/90000
a=content:main
a=inactive
000932: Sep 18 14:08:06.808 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:700@10.135.191.12:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40F1BB8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
000933: Sep 18 14:08:06.812 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Cisco Unity" <sip:800@184.71.242.2>;party=called;screen=yes;privacy=off
Contact: <sip:1111111111@184.71.242.2:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292
v=0
o=CiscoSystemsSIP-GW-UserAgent 4672 7011 IN IP4 184.71.242.2
s=SIP Call
c=IN IP4 184.71.242.2
t=0 0
m=audio 16416 RTP/AVP 0 101
c=IN IP4 184.71.242.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 0 RTP/AVP 34
c=IN IP4 184.71.242.2
000934: Sep 18 14:08:06.896 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK243fd8d0;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Contact: <sip:2222222222@208.43.85.75>
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Content-Length: 0
000935: Sep 18 14:08:17.351 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:2222222222@172.18.0.1:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bK8347ed20ac
From: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
To: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
Date: Thu, 18 Sep 2014 20:08:07 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 UPDATE
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Min-SE: 1800
P-Asserted-Identity: "Anthony" <sip:270@10.135.191.12>
Remote-Party-ID: "Anthony" <sip:270@10.135.191.12>;party=calling;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>
Content-Length: 0
000936: Sep 18 14:08:17.351 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bK8347ed20ac
From: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
To: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
Date: Thu, 18 Sep 2014 20:08:17 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
CSeq: 101 UPDATE
Allow-Events: telephone-event
Contact: <sip:270@172.18.0.1:5061;transport=tls>
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Length: 0
000937: Sep 18 14:08:22.894 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK7d5b6278;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Content-Length: 0
000938: Sep 18 14:08:22.898 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK7d5b6278;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:22 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
CSeq: 103 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=804,OS=128640,PR=693,OR=98712,PL=0,JI=0,LA=0,DU=16
Content-Length: 0
000939: Sep 18 14:08:22.898 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:700@10.135.191.12:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK4102F8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:17 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Max-Forwards: 70
Timestamp: 1411070902
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=693,OS=98712,PR=804,OR=128640,PL=0,JI=0,LA=0,DU=16
Content-Length: 0
000940: Sep 18 14:08:22.902 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK4102F8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:23 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Server: Cisco-CUCM10.5
CSeq: 102 BYE
Content-Length: 0
CUBE Dialpeers and voice config:
voice service voip
ip address trusted list
mode border-element
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
registrar server expires max 1200 min 300
rel1xx disable
midcall-signaling passthru
g729 annexb-all
dial-peer voice 1000 voip
description *** Outbound CUCM ***
destination-pattern ...
session protocol sipv2
session target ipv4:XXXXXX
session transport tcp tls
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 2000 voip
description *** Inbound CUCM ***
session protocol sipv2
session transport tcp tls
incoming called-number ...
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 101 voip
description *** Incoming Dial-Peer ***
translation-profile incoming INCOMING1
session protocol sipv2
session target sip-server
incoming called-number 1111111111
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 1 voip
description *** Outbound Dial-Peer ***
translation-profile outgoing Strip9
destination-pattern 9.+
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
10-17-2014 01:24 PM
To me this is service impacting as well - I have been trying to be patient with TAC especially since I suspected this may have been a bug and I understand those aren't fixed instantly.
My Cisco partner manages the interaction with TAC as part of a contract I have with them, but the delay is not coming from them (my Cisco partner), I can tell this for sure based on the email timestamps in the conversation between them and TAC... (And me)
I don't mean to point fingers here, just posting this for full transparency. I've poked them again for another update, won't hold my breath though because it's Friday. If poking doesn't work maybe I'll start throwing office supplies... (Kidding)
Anthony
10-17-2014 01:28 PM
Good luck Anthony, eagerly waiting fir the solution. Please let us know. :-)
10-17-2014 01:35 PM
Anthony,
If you do not get any feedback by Monday, let me know and I will open a case with cisco. I will need your email to send the webex invite..You can PM me. hopefully we can resolve this by monday
10-17-2014 02:03 PM
I'd be happy to take you up on that - I'll keep everyone posted on this.
I'll shoot you a PM on Monday with my email depending on how this plays out here.
Anthony
10-18-2014 08:41 AM
Anthony can you give one more try with below changes and let me know.
voice class sip-profiles 5
response 200 sdp-header Audio-Attribute modify "inactive" "sendrecv"
dial-peer voice 1000 voip
voice-class sip profiles 5
And attach these outputs here.
1.debug ccsip message
2."show media streams" and "utils network capture eth0" through SSH login to CUCM server where ANN is registered and when call is transferred from call handler.
10-18-2014 02:21 PM
I added the requested config to CUBE and unfortunately there is still no ringback present.
Find attached the requested debug information. Time of call 3:07PM, other information remains the same as previous from thread.
I'm somewhat puzzled because "show media streams" seems to indicate an active ANN stream...? Or am I reading this wrong?
Thank you,
Anthony
10-19-2014 03:32 AM
Yes there is an active ANN stream from 10.135.191.12:24580 to 172.18.0.1:18690 and which also can be verified by checking the RTP stream from the packet capture after the exchange of SIP ACK message.
Now what puzzling me here is why ITSP sends media=inactive in response to CUCM DO Re-Invite. Now that something you can check with Telco but just for a workaround can you do one more change and let me know.
voice class sip-profiles 6
request REINVITE sdp-header Audio-Attribute modify "inactive" "sendrecv"
dial-peer voice 1 voip (if this is your outgoing dial-peer towards ITSP)
voice-class sip profiles 6
Now attach ccsip message only.
10-19-2014 11:14 AM
10-19-2014 08:58 PM
Because sip profile 6 did not kicked in to modify DO Re-Invite.
Did you applied it to correct dial-peer ?( You can check with debug voice ccapi inout). If dial-peer is correct then modify sip-profile 6 with this...
request any sdp-header audio-attribute modify "inactive" "sendrecv"
response any sdp-header audio-attribute modify "inactive" "sendrecv"
My purpose in modifying those parameters is to extend media stream till ITSP interface , which remain terminated at CUBE inside interface.
Do attach ccsip message.
10-19-2014 09:42 PM
It looks like it is under the right dial peer so I modified as suggested again. (Unless I have misunderstood, this should be the outgoing dial peer towards my provider, not the incoming dial peer from the provider, and not the dial peer facing CUCM, apologies if I'm off the mark)
Class 6 now looks like:
There is still no ringback present (assuming I have this configured right).
Attached are ccsip messages output from a call at 10:36PM.
Thanks,
Anthony
10-19-2014 10:08 PM
Anthony can you give one more last try from my side. Add these in sip profile 6.
voice class sip-profiles 6
request ANY sdp-header Audio-Attribute modify "inactive" "sendrecv"
response ANY sdp-header Audio-Attribute modify "inactive" "sendrecv"
request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "184.71.242.2"
request ANY sdp-header Connection-Info modify "0.0.0.0" "184.71.242.2"
response ANY sdp-header Connection-Info modify "0.0.0.0" "184.71.242.2"
response ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "184.71.242.2"
If that didn't work then i think i have to wait till TAC's answer on this.
10-19-2014 10:55 PM
Added the four new lines to the same voice class, unfortunately this did not have an effect.
Thanks for the help, let me know if there is anything else I can provide.
Anthony
10-19-2014 11:06 PM
This certainly will be my last try :)
Can you please provide packet capture for inside and outside interface of CUBE router. I just want to check whether RTP stream has reached its interface or not.
10-19-2014 11:34 PM
10-20-2014 02:12 AM
Here is the summary of packet capture
ITSP OK
Connection Information (c): IN IP4 204.101.100.12
Media Description, name and address (m): audio 11750 RTP/AVP 0 101
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): ptime:20
CUBE ACK
Connection Information (c): IN IP4 184.71.242.2
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 18780 RTP/AVP 0 101
Connection Information (c): IN IP4 184.71.242.2
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
---------------------------------------------------------------------------------------
CUBE OK
Media Description, name and address (m): audio 18782 RTP/AVP 0 101
Connection Information (c): IN IP4 172.18.0.1
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
CUCM ACK
Connection Information (c): IN IP4 10.135.191.12
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 24608 RTP/AVP 0
Media Attribute (a): X-cisco-media:umoh
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:0 PCMU/8000
And this is actual RTP packet exchange between CUCM , CUBE and ITSP.
Src: 10.135.191.12 (10.135.191.12), Dst: 172.18.0.1 (172.18.0.1)
User Datagram Protocol, Src Port: 24608 (24608), Dst Port: 18782 (18782)
Src: 184.71.242.2 (184.71.242.2), Dst: 204.101.100.12 (204.101.100.12)
User Datagram Protocol, Src Port: 18780 (18780), Dst Port: 11750 (11750)
Every thing is matching from source to destination , i don't know what stopping the media to play at caller phone. Two possibility that i can think of right now first ANN file is corrupt (which is not possible as in other cases it playing correctly) and second there is something ahead of CUBE which is blocking this media.
When you receive an incoming call from ITSP in normal case scenario, do you hear ringback or moh ? Can you share packet capture from CUBE for a moh call ?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide