Modify calling number in SIP invite on CUCM 10.5
Hello,
I am working at a customer with CUCM 10.5 who uses MGCP gateways to access the PSTN via T1 PRI ISDN.
They use four digit DNs internally and need to prefix these with 713657 to make the outbound CLID work ok - i.e. a call to the PSTN from extension 1000 needs to send 7136571000 to the ISDN provider.
I configured this using Calling Party Transformations and this works fine e.g.
A Calling Party Transformation for 1XXX would prefix 713657.
The problem I have is that the customer has a NICE active recording system which communicates with the CUCM cluster using a SIP trunk.
The invites that CUCM sends via the SIP trunk show the full ten digits rather than the four digit extension which will not work according to company deploying the recording system.
If I remove the Calling Party Transformation then the SIP invite shows four digits and the call recording works but the outbound CLID does not work.
Can anyone suggest a way to fix this? The customer does not want to change the gateway protocol from MGCP to H323 which would be my favoured choice. Any change of calling party setting on CUCM (e.g. ticking the use external mask for calling party on route pattern) affects the SIP invite.
Ideally I need a way to modify the number in the SIP invite but I cannot find any example of how to do this.
Any suggestions are welcome.
Thanks
Hi, thanks for your response.
The Calling Party Transformation CSS is not applied to the SIP trunk but is applied to the T1 port of the MGCP gateway.
The Transformations are still applied to the SIP Invite messages via the trunk so I guess this is a quirk of the calling recording profile setup on CUCM.
I did try creating another Calling Party Transformation setup which stripped the unwanted digits and applied it to the SIP trunk but it had no effect.
Similar Messages
-
Unable to place call on calls on hold - SIP Trunk from CUCM to CUBE and from CUBE to ISTP
Hi Cisco Community,
I have a SIP Trunk setup between the CUCM and CUBE and another SIP Dial Peers from the CUBE to the ITSP. All incoming/outgoing calls, DTMF-Relay works well except one thing which is the ability to hold the call.
On the SIP Trunk from the CUCM to the CUBE, I did not select “MTP” because when I do so, I am forced to select my preferred MTP codec which when selected G.729/G.729a, all my outgoing calls goes out using G.729r8. This codec works well for most of the calls until the ITSP replies back with G.729br8. When this condition occur, my call simply fails (this is very intermittent and only some random numbers).
That said, I have some issues with DTMF Relay when I select MTP on the SIP Trunk. DTMF Relay only works if the call is G.729r8 all the way from the CUCM to the ITSP. If the ITSP replies back with G.729br8, the call might established but will simply be “voice-only”.
The current setup is no MTP is selected and everything is working perfectly. I am happy with that until I place a call on hold, which when I do so, the call immediately terminate. Could you please help me understand why?
I have all media resources configured such as G.729r8 MTP, G.729br8 MTP, G.711u MTP, Transcoding with all codecs, etc. All MRG and MRGL are configured on all devices and SIP Trunks.
Below is an example of a call that is connected with the current setup:
Note:
IP: 10.18.81.2 (CUBE)
IP: 10.18.81.11 (CUCM SUB)
IP: 10.111.111.254 (ITSP SBC)
PM-HO-VG-01#
PM-HO-VG-01#
Nov 30 11:44:29.938: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.18.81.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
Session-Expires: 1800
Contact: <sip:[email protected]:5060>
Max-Forwards: 70
Content-Length: 0
Nov 30 11:44:29.942: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:29.946: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1417347869
Contact: <sip:[email protected]:5060>
Call-Info: <sip:10.18.81.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 301
v=0
o=CiscoSystemsSIP-GW-UserAgent 7676 6958 IN IP4 10.18.81.2
s=SIP Call
c=I
PM-HO-VG-01#N IP4 10.18.81.2
t=0 0
m=audio 22256 RTP/AVP 18 0 8 101
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Nov 30 11:44:29.950: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Nov 30 11:44:30.658: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Session Progress
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Session: Media
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:30.662: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2747 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:31.226: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Session Progress
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Session: Media
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
X-BroadWorks-Correlation-Info: bbf9
PM-HO-VG-01#4839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Accept: application/media_control+xml,application/sdp,application/xml
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 10.111.111.254
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC81D00
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:31.634: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2747 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:31.726: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72075e3a02c1
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 236
v=0
o=CiscoSystemsCCM-SIP 9082578 1 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 10.18.80.40
b=TIAS:8000
b=AS:8
t=0 0
m=audio 21928 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 10.18.80.40
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
PM-HO-VG-01#
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 10.18.80.40
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
PM-HO-VG-01#sh sip
PM-HO-VG-01#sh sip-ua call
PM-HO-VG-01#sh sip-ua calls
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
SIP UAC CALL INFO
Call 1
SIP Call ID : [email protected]
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 27218091323
Called Number : 0862000000
Bit Flags : 0xC04018 0x10000100 0x0
CC Call ID : 64511
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : [10.111.111.254]:5060
Destn SIP Resp Addr:Port: [10.111.111.254]:5060
Destination Name : 10.111.111.254
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 64511
Stream Type : voice+dtmf (0)
Stream Media Addr Type : 1
Negotiated Codec : g729br8 (20 bytes)
Codec Payload Type : 18
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [10.18.81.2]:22256
Media Dest IP Addr:Port : [10.111.111.254]:20074
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Client(UAC) calls: 1
SIP UAS CALL INFO
Call 1
SIP Call ID : [email protected]
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 0218091323
Called Number : 0862000000
Bit Flags : 0xC0401E 0x10000100 0x80004
CC Call ID : 64510
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : [10.18.81.11]:5060
Destn SIP Resp Addr:Port: [10.18.81.11]:5060
Destination Name : 10.18.81.11
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 64510
Stream Type : voice+dtmf (1)
Stream Media Addr Type : 1
Negotiated Codec : g729br8 (20 bytes)
Codec Payload Type : 18
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [10.18.81.2]:22350
Media Dest IP Addr:Port : [10.18.80.40]:21928
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
PM-HO-VG-01#
PM-HO-VG-01#
PM-HO-VG-01#
As you can see, the call is connected and everything is working perfectly. When I press the hold button, here is what I get:
NOTE: I have # debug ccsip messages and #debug ccsip calls (running)
PM-HO-VG-01#
PM-HO-VG-01#
Nov 30 11:44:49.210: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsCCM-SIP 9082578 2 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:8000
b=AS:8
t=0 0
m=audio 21928 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Nov 30 11:44:49.218: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:49.218: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC9241
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Timestamp: 1417347889
Contact: <sip:[email protected]:5060>
Call-Info: <sip:10.18.81.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7676 6959 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 22256 RTP/AVP 18 101
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC9241
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 102 INVITE
Timestamp: 1417347889
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp,application/xml
Contact: <sip:[email protected]:5060;transport=udp>
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 360
v=0
o=BroadWorks 316169737 2 IN IP4 10.111.111.254
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
a=inactive
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 0.0.0.0
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.282: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECA2633
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:49.282: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2748 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 22350 RTP/AVP 18 101
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Nov 30 11:44:49.282: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72094953dfea
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Content-Length: 0
Nov 30 11:44:49.290: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:[email protected]:5060>
Content-Length: 0
Nov 30 11:44:49.294: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 103 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:49.294: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECB16F3
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 103 INVITE
Max-Forwards: 70
Timestamp: 1417347889
Contact: <sip:[email protected]:5060>
Expires: 180
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:49.338: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECB16F3
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 103 INVITE
Timestamp: 1417347889
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp,application/xml
Contact: <sip:[email protected]:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 306
v=0
o=BroadWorks 316169737 3 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:49.342: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 2
PM-HO-VG-01#00 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 103 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2749 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:49.350: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720b594cd517
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 213
v=0
o=CiscoSystemsCCM-SIP 9082578 3 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 10.18.81.10
t=0 0
m=audio 4000 RTP/AVP 18
a=X-cisco-media:umoh
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=sendonly
Nov 30 11:44:49.354: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECC55
From: <sip:[email protected]>;tag=3C365010-1E42
To: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Max-Forwards: 70
Timestamp: 1417347889
CSeq: 101 BYE
Reason: Q.850;cause=86
P-RTP-Stat: PS=874,OS=17480,PR=872,OR=17440,PL=0,JI=0,LA=0,DU=17
Content-Length: 0
Nov 30 11:44:49.354: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECD1ECD
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Max-Forwards: 70
Timestamp: 1417347889
CSeq: 104 BYE
Reason: Q.850;cause=65
P-RTP-Stat: PS=872,OS=17440,PR=952,OR=19040,PL=0,JI=0,LA=0,DU=17
Content-Length: 0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Race Condition
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECD1ECD
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
Timestamp: 1417347889
CSeq: 104 BYE
Content-Length: 0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 10.111.111.254
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 65
Disconnect Cause (SIP) : 200
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECC55
From: <sip:[email protected]>;tag=3C365010-1E42
To: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 101 BYE
Content-Length: 0
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 0.0.0.0
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 86
Disconnect Cause (SIP) : 200
PM-HO-VG-01#Hi Manish,
Again, excellent feedback. Much appreciated.
I will try the commands suggested above and see if I can get DTMF to work correctly while interworking H.323 and SIP.
But my ultimate goal is to have SIP all way from the CUCM to the CUBE and from the CUBE to the ITSP.
If I enable SIP Early Offer with MTP on the CUCM going to the CUBE, all SIP Invite sent from the CUCM to the CUBE uses G.729r8 as the codec and once the call is established using G.729r8 should the ITSP reply with that codec, the call succeed and I am able to see an active MTP session using G.729 when I issue the command # show sccp connections.
One thing that I saw is that my ITSP love so much sending G.729br8 most of the times, so even if using SIP EO with MTP on the SIP Trunk to the CUBE, when I sent my INVITE out from the CUCM to the CUBE using G.729r8, specially on call center numbers such as 0800 numbers, you will see that the call established but the codec being negotiated is G.729br8 which is voice only (missing DTMF).
I will be doing some intensive test again later on this week and will send the logs.
Here is my question to both of you:
Which is the best way of having a proper SIP to SIP setup all the way that will not pose any problem?
Do I have to enable Early Offer on the SIP Profile used by the CUBE SIP Trunk or should I use the normal Standard SIP Profile? Do I need to enable MTP on my CUBE SIP Trunk or not?
From the CUBE point of view, I have a voice class codec that support G.729r8 or G.729br8 and the DTMF Relay method supported by the ITSP is RFC 2833.
I will send more logs for each scenario. I think that we are getting close to the resolution of this problem.
Thanks again for your support fellows. -
Get '500 Internal Server Error' during SIP INVITE - cause 44
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Get ‘500 Internal Server Error’ during SIP INVITE - cause 44
Have you ever seen anything like this before? It usually works, but intermittently, we see calls get rejected. It somehow seems related to high loads on the router. We reduced the occurrences by changing our code to throttle the number of SIP INVITEs we send, but this doesn’t scale well. Once it occurs, the only way to clean it up is to do a shut/no shut on the voice-port associated to SIP INVITE.
Any suggestions on how we can proceed to debug this issue?
BACKGROUND:
Cisco 2811 running (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)
NAME: "2811 chassis", DESCR: "2811 chassis" PID: CISCO2811
NAME: "9 Port FE Switch on Slot 0 SubSlot 1", DESCR: "9 Port FE Switch" PID: HWIC-D-9ESW
NAME: "WIC/VIC/HWIC 1 Power Daughter Card", DESCR: "9-Port HWIC-ESW Power Daughter Card" PID: ILPM-8
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 2", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 3", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "PVDMII DSP SIMM with four DSPs on Slot 0 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "High Density Voice2 Network module with on board two port interface on Slot 1", DESCR: "High Density Voice2 Network module with on board two port interface " PID: NM-HDV2-2T1/E1
NAME: "2nd generation two port EM voice interface daughtercard on Slot 1 SubSlot 0", DESCR: "2nd generation two port EM voice interface daughtercard" PID: VIC2-2E/M
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 2", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 3", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 5", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
WIRESHARK:
No. Time Source Destination Protocol Info
2 0.057246 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 2 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
3 0.071428 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 3 (1109 bytes on wire, 1109 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
4 0.089917 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 4 (1116 bytes on wire, 1116 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
7 1.661867 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 7 (469 bytes on wire, 469 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
8 1.676056 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 8 (1107 bytes on wire, 1107 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
10 1.700567 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 10 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
11 1.726376 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 11 (1114 bytes on wire, 1114 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
13 1.727645 10.194.154.136 171.68.115.156 SIP Status: 500 Internal Server Error
Frame 13 (526 bytes on wire, 526 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 500 Internal Server Error
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>;tag=4864C50-3C3
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=44
Reason Protocols: Q.850
Cause: 44(0x2c)[Requested circuit/channel not available]
Content-Length: 0
Thanks!
-JohnSince it appears you are a Cisco Employee, my recommendation is that you use the many internal resource available to you (including, but not limited to) , like TAC access, internal forums, team leaders, etc.
This not to give the casual reader, the impression that the best source of support at Cisco is a customer's public forum. -
CUCM 8.6 call busy between SIP phones and thirdparty phones
Hi Everybody,
I have the following error on my logs:
Invalid Disconnect Cause(cause=47), No Reason Header Appended
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getXCiscoViPRFallbackIDAndDTMFKey: Device type 8, Pstn Fallback is not enabled|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefCcRegister: Secure status=1, mSrtpPresent=0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/compareAndUpdateMedia: sdpStatus=0, CMEndPointSDP role=1, SIPEndPointSdpRole=2|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefCcRegister: Secure status=1, mSrtpPresent=0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSIPUACSessionExpires: isMidCall[0], response[200], method[102]|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/parseSessionExpires: refresh_interval[1800], refresher[uas]|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/setSIPSessionExpiresTimer: interval[1768] secs|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSecureRec: enforce srtp flag: 0, remote end srtp support: 0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/updateCNToCC: identityCngFlag[0x1f], isConnInfoInd[1], ccContactHeader[]|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSIPConnectInd: Exit with state = outCall_200Rcvd|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSIPConnectInd: Exit with state = outCall_200Rcvd|3,100,63,1.36454459^192.168.0.15^*
14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/setSIPUpdateFlags: mIsUpdateForSignalingAllowed = 1 mIsUpdateForMediaAllowed = 1 mPendingOutgoingUpdate = 0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/appendReasonHdr: appendReasonHdr - Invalid Disconnect Cause(cause=47), No Reason Header Appended|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/addTransparencyInfo: attaching transparency object|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/appendRPIDHdrForOriginalCalledParty: SIP device does not Support Orig Dialled Phone nego: 0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefAe: SIPCdpc=281707, nodeId=3, processNumber=73 ci=144600614, branch=0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |MRM::waiting_MrmDeallocateMtpResourceReq- Deallocate received for CI=53993831 count=0|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |MRM::waiting_DeallocateMtpResourceReq- ERROR Deallocate received for an unknown Call Identifier Ci = 53993831|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPHandler/ccbId=0/scbId=0/sip_stop_timer: type=SIP_TIMER_DISCONNECT value=500 retries=10|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPHandler/ccbId=0/scbId=0/sip_start_timer: type=SIP_TIMER_DISCONNECT value=500 retries=10|3,100,63,1.36454459^192.168.0.15^*
14:46:50.098 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.168.0.15:[5060]:
the calling number is 34967850938
the callied number is 19026Julien,
Please use the link be low to collect cucm traces and use the advanced editor on the forum (located on top right hand corner of the discussion widnow) to attach the trace
https://supportforums.cisco.com/docs/DOC-29901
Ensure you collect the trace from the folowing
1. the server that the phone is registered to
2. If this server is different from the server in the cucm group of the sip trunk, then you need to also collect traces from the server (s) in the cucm group assiged to the sip trunk that connects to the 3rd party cluster...
NB: If you have three servers in the cucm group of the sip trunk, you have to collect the trace from all three servers. This is because calls are dsitributed in a round robin fashion to servers in a sip trunk...
FInally before you send the trace over, please ensure the calling and called numbers are present. Also include the time of the test call
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared" -
CUCM 8.6 Dropped call transfers involving SIP phones
Hi All,
I am a developer who has been tasked with figuring out why call transfers are being dropped by Cisco CUCM when the original call comes from a SIP phone. This scenario works:
Cisco phone calls another Cisco phone, which transfers the original call to a SIP phone
These scenarios do not work:
SIP phone calls Cisco phone, which transfers the original call to another Cisco phone
SIP phone calls Cisco phone, which transfers the original call to another SIP phone
I have researched the Call Manager traces to the best of my ability, and I see some info in there that could potentially point to the source of the problem. I am just unable to understand what the trace means:
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/active_CcDisconnReq: ccDisconnReq.onBehalfOf=Media : ccDisconnReq.s.sv=2 : ccDisconnReq.c.cv=47 |1,100,63,1.93259^10.10.10.85^*
10:23:08.672 |//SIP/Stack/Info/0x0/sipConstructContainerContext #### Created container=0xb0b42f58|1,100,71,1.1^*^*
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/appendReasonHdr: appendReasonHdr - Invalid Disconnect Cause(cause=47), No Reason Header Appended|1,100,63,1.93259^10.10.10.85^*
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/appendRPIDHdrForOriginalCalledParty: SIP device does not Support Orig Dialled Phone nego: 0|1,100,63,1.93259^10.10.10.85^*
I have been wondering whether this could be a codec issue, however the SIP phones we are using are configured with the following codecs:
G711U
G711A
G722
ILBC
GSM
and our SIP software is also set to accept the first codec offered by the remote side. It seems from the SIP client logs that G722 is being used as the codec to communicate with the Cisco phones, but perhaps I'm misinterpreting.
I have attached a CUCM trace of a call from a SIP phone (ext. 491) to a Cisco handset (ext. 170) where the Cisco handset attempts to transfer the call to another SIP phone (ext. 492). The trace snippet shown above is from this log.
I would really appreciate it if someone more experienced with VoIP/SIP/CUCM could take a look and offer any ideas on what the issue might be, and also how we might be able to address it. I can try to provide more info about our CUCM configuration if needed.
Thanks in advance!Leslie, so here is what I found from the traces....
To understand the difference we need to understand how cucm performs call transfers from a sccp signalling point and a sip signalling point
SCCP
When the transfer key is pressed
1. CUCM sends a CloseReceiveChannel and StopMediaTransmission to the IP phone involved in active media (referenced by the callids)
NB, here CUCM updates the call state on the phone to a call state of 8 which is "Hold"
2.CUCM tells the held party to listen MOH from MOH server
3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected
4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party
5..CUCM sends a CloseReceiveChannel between the held phone and MOH server (to tear down the media)
6. Next CUCM sends a CloseReceiveChannel and StopMediaTransmission to the transfering party & transfered party to remove Xferring party from call
7. finally CUCM sends OpenReceiveChannel between the original called party and the transfered party..and call is done
For SIP signalling. when the first transfer key is pressed
1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path
2. CUCM sends a Delayed offer to insert MOH or to resume Media stream
NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK
3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected
4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party
5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)
6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call
7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call
Now having explained all of these, we need to look at where the call is failing for SIP-----SCCP----SIP calls without MTP
lets look at succesful SCCP-----SCCP-----SIP without MTP
Point 4 above
++++++++Extension 170 presses the transfer button to connect the two calls (Callid=24378483)+++++++++++++
(0003395) SoftKeyEvent softKeyEvent=4(Trnsfer) lineInstance=1 callReference=24378483
Point 5 above
++++Next CUCM closed the media between extension 160 and MOH server callid=24378480(this is the only active call on this callid)+++
(0003396) CloseReceiveChannel conferenceID=24378480 passThruPartyID=16777845. myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
Point 6 Above
+++++Next cucm closes the call between extension 170 and 490 callid=(24378483)++++++++
(0003395) CloseReceiveChannel conferenceID=24378483 passThruPartyID=16777847. myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a8b(10.10.10.139)
(0003395) StopMediaTransmission conferenceID=24378483 passThruPartyID=16777847. myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a8b(10.10.10.139)
Point 6 above for the sip side (since the destination is SIP, to tear down media to SCCP phone, so as to connect the caller to the xfered party)
+++++++Next CUCM sends a re-invite with a=inactive SDP to the sip phone ++++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885626,NET]
INVITE sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23332dbee978
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
o=CiscoSystemsCCM-SIP 192115 2 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 0.0.0.0
m=audio 24560 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive-----------------------------------------------------Inactive
Still part of Point 6 for SIP signalling
++++++++++++Next sip phone responds with a 200 OK recevonly SDP +++++++++++++++++++
//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 62220 index 1890 with 683 bytes:
[885628,NET]
SIP/2.0 200 OK
v=0
o=- 18077 11099 IN IP4 10.10.10.104
s=yasdjip
c=IN IP4 10.10.10.104
t=0 0
a=ptime:20
a=recvonly-------------------------------------a=recvonly
Finally Point 7 above..
+++++++++++++=Next cucm sends a DO re-invite to extension 492-sip phone++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885630,NET]
INVITE sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK233534ffec4a
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: ;tag=5B0E9816C2CA6D70F3166FB972EDE4C2
+++++++Next we get a 200 OK from sip phone with sdp=sendrecv+++++++++=
/SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 62220 index 1890 with 683 bytes:
[885634,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK233534ffec4a
Contact:
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
Call-ID: [email protected]
v=0
o=- 18077 11099 IN IP4 10.10.10.104
s=yasdjip
c=IN IP4 10.10.10.104
t=0 0
m=audio 16574 RTP/AVP 9 101
a=rtpmap:101 TELEPHONE-EVENT/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
+Now CUCM sends an OpenReceiveChannel and start media xmission to sccp phone (callid=24378480) with media parameters of sip phone++++++
(0003396) OpenReceiveChannel conferenceID=24378480 passThruPartyID=16777848 millisecondPacketSize=20 compressionType=6(Media_Payload_G722_64k) RFC2833PayloadType=101 qualifierIn=? sourceIpAddr=IpAddr.type:0 ipAddr:0x0a0a0a68000000000000000000000000(10.10.10.104). myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
(0003396) startMediaTransmission conferenceID=24378480 passThruPartyID=16777848 remoteIpAddress=IpAddr.type:0 ipAddr:0x0a0a0a68000000000000000000000000(10.10.10.104)
remotePortNumber=16574 milliSecondPacketSize=20 compressType=6(Media_Payload_G722_64k) RFC2833PayloadType=101 qualifierOut=?. myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
+++++++++++=Next Phone sends its ACK+++++++++++++++
(0003396) OpenReceiveChannelAck Status=0, IpAddr=IpAddr.type:0 ipAddr:0x0a0a0a89000000000000000000000000(10.10.10.137), Port=20352, PartyID=16777848
+++++++++++=Next CUCM sends ACK to 200 OK from SIP Phone+++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885635,NET]
ACK sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23366067b8c0
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: ;tag=5B0E9816C2CA6D70F3166FB972EDE4C2
Date: Tue, 19 Feb 2013 21:44:45 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 237
v=0
o=CiscoSystemsCCM-SIP 192115 3 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.137
b=TIAS:64000
b=AS:64
t=0 0
m=audio 20352 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Now at this point all is well...and the call is connected....
Now here is where the call is failing on the SIP-SCCP-SIP call without MTP
From Point 2 above, CUCM sends a DO to insert MOH, and then gets response, then sends an ACK to 200 Ok back to SIP Phone..
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 53361 index 1810
[881160,NET]
ACK sip:[email protected]:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22035ecc1fcb
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Date: Tue, 19 Feb 2013 17:38:50 GMT
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
Max-Forwards: 70
CSeq: 102 ACK
o=CiscoSystemsCCM-SIP 190666 3 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195---------------------------------------IP address of MOH server
t=0 0
m=audio 4000 RTP/AVP 0--------------------------------MOH port 4000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendonly---------------------------------------------------------sendonly
+++++NOW Point 6 above (SIP) CUCM sends a=inactive to break media path to MOH server to connect caller and xfered party++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 53361 index 1810
[881161,NET]
INVITE sip:[email protected]:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22045bb7f918
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Date: Tue, 19 Feb 2013 17:39:04 GMT
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 164
v=0
o=CiscoSystemsCCM-SIP 190666 4 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 0.0.0.0--------------------------------------------------------------------Media IP is 0.0.0.0
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive---------------------------------------------------------------------media inactive
At this point, we should get a response back from the sip phone...
and here is what we got..
++Trying which is expected++++
//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 53361 index 1810 with 331 bytes:
[881162,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22045bb7f918
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
CSeq: 103 INVITE
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Content-Length: 0
++++++++Then we get a BYE+++++++++++++++
/SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 53361 index 1810 with 576 bytes:
[881163,NET]
BYE sip:[email protected]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.104:53361;branch=z9hG4bKa2vdQvR7J9OiMyjU;rport
Contact:
Max-Forwards: 70
From: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY
Supported: replaces, path
User-Agent: Acrobits Softphone Business/2.4.8
To: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
CSeq: 3 BYE
Content-Length: 0
So this is the root cause of the problem. Your SIP phone does not know how to respond to multiple media break between it and the MOH server.
The difference between this and the succesful SCCP-SIP--SCCP, is that the held party was a sccp phone, hence the sip phone only has to process one a=inactive SDP message, where as in the SIP-SCCP-SIP, the help party was sip, so the sip phone has to process two a=inactive SDP messages
Now what is the difference when MTP is involved! A Big difference. MTP stays in the media path. So there is never a break in media and no inactive SDP attribute is sent. The flow looks like below:
for the initial call...The SIP phone sends its media to MTP and likewise the SCCP phone
SIP------Media------MTP------------Media-------SCCP Phone
When the new destination is dialled and transfer is commited,
SIP-------------media----MTP--------media---------MTP
The final invoite sent to connect 492 and 491 has MTP as the IP address to connect Media to.
++++++++Ivite to 492 ++++++++++++++
INVITE sip:[email protected]:61303;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231a3b24b862
From: ;tag=192048~d8e94532-127d-4dca-bba0-64b1675da032-24378472
To: ;tag=78FF5BF6C019A55EA020B69BB6A767E2
Date: Tue, 19 Feb 2013 21:24:59 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 214
v=0
o=CiscoSystemsCCM-SIP 192048 1 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195---------------------------------------------------------------the MTP ip address
t=0 0
m=audio 25038 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
+++++++Invite to 491 +++++++++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.94 on port 50376 index 1887
[885429,NET]
INVITE sip:[email protected]:50376;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231b78d1b56
From: ;tag=192046~d8e94532-127d-4dca-bba0-64b1675da032-24378467
To: "491" ;tag=F13CE94DE942C47680356A647DC7F916
Date: Tue, 19 Feb 2013 21:24:59 GMT
Call-ID: AE7045FFB2D8D9C28D54651473A14A5D41B5B93C
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: "Leslie2" ;party=calling;screen=no;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 237
v=0
o=CiscoSystemsCCM-SIP 192046 1 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195----------------------------------------MTP
b=TIAS:64000
b=AS:64
t=0 0
m=audio 25030 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Wao! That was a long one isnt it...It was fun too.
So now you can look at your sip phones and see if they can accept two inactive sdp messages within the same call. That way you can remove MTP. otherwise you will have MTP involved in every single call involving a sip phone, even if they do not involve transfers
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared" -
SIP Invite change for anonymous calls
I noticed a change in IOS Gateways in how it deals with anonymous calls. Anonymous calls in version 12.4(25g) generates an SIP INVITE:
From: "anonymous" <sip:[email protected]>
A anonymous calls on version 15.1(4)M8 generates a SIP INVITE:
From: "anonymous" <sip:[email protected]>
The p-asserted-identity and remote-party-id did not change. None of our other SIP systems use the "anonymous@" format.
How do I get the 15.1 GW to use "<number>@" instead of "anonymous@" for these calls?
Thanks,
-JohnHi John,
The only possible solution that i could think of for this scenario is through the use of SIP profiles on the gateway. There are quite a few posts and docs which you can check to try and configure one for your setup
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/105624-cube-sip-normalization.html
http://www.gossamer-threads.com/lists/cisco/voip/127376
HTH
Manish -
CUCM not forwarding CTI called number - Subscriber Sign-in
I am running into an issue in CUCM/CUC 8.6(2a) when setting up external voicemail access.
I set up a CTI RP (Dn=2300) to forward to voicemail and set up a routing rule to send the Call
to subscriber sign in. The call keeps going to the opening greeting. I did a port status monitor
and I don't see the forwarding stations directory number. Just the Unity Pilot Point number.
I just set this up in CUCM 8.6(1) and I have it working. I mirrored the config but don't get the same results.
I'm not sure if maybe a service parameter changed or something and I am missing it.
TIAThanks for sharing your findings Rob. Your post helped me solve an issue I was having with a SIP trunk between CUCM and CUC.
Just to recap in case this post can help anyone else, if you don't check the Redirecting Diversion Header Delivery - Outbound then Call Manager will not forward calls with a redirect number or reason code to Unity. Using RTMT Port Monitor you'll find the call will complete but as a direct call to Unity.
The problem I was facing was CFNA (internal, external, etc) from a DN in CUCM to CUC would send the caller to the Opening Greeting, instead of the voicemail box of the user, which in this case was functioning properly because Redirecting Diversion Header Delivery was not checked.
Thanks again to both Robs for your thread,
Derek -
Third Party Phone over SIP Trunk with CUCM 9.x
Hi all,
I have a problem where my Third Party SIP phones wont go over the SIP trunk configured in my CUCM 9.x cluster. My Cisco phones work fine and goes out the trunk. I have noticed a distinct difference in wireshark with the invite packets from Third Party SIP phones and the Cisco ones.
I have configured the SIP trunk in CUCM with the following route pattern (60.!#)and configured it with associated group and list. Heres the differense between the invite packets from Cisco and Third Party phones.
Cisco Phone: INVITE sip.60xxxx%23@ipadress
Third Party SIP Phone: INVITE sip:[email protected]
It seems the Cisco phones gets some extra configured the Third Party ones dont...
Thanks in advance for any help.
//PerThanks for the answer
Yeah i have DNS configured and i have the trunk pointed to a domain destination SRV record and like i said it works fine when calling from a Cisco phone. I tried changing the domain to an ip address but same result. I also changed the Plycom phone from being registered towards the domain of CUCM to an IP adress of CUCM and then the SIP INVITE messages in wireshark began to look kinda the same expet for the "%23" section but it still dont work.
When i look at the Real Time Data in RTMT the orig and final called from the cisco phone has stripped the 60 and forwared the rest of the number towards the correct domain for the SIP trunk.
When looking at the data from the Polycom phone the orig and final called data still contains the 60 prefix part and the called device name field is empty. The termination Cause Code is that the number requested is Unallocated/Unassigned..
In other words something is missing to get CUCM to strip 60 from the Polycom phones dialed number and send it towards the SIP trunk like it does when the Cisco phones call it.
Unfortunatley i dont have the meens to attach the trace...
Thanks again for any help/advice
With regards, Per. -
Hello,
I am writing a UCCX script that pulls the calling and called numbers and does some other cool stuff to find an outcome and finally what to do with that specific call.
Everything is working except I am not getting the called number. The called number I am seeing is the CTI Route Point number that was called to get the call into UCCX rather than the PSTN number.
The setup is as follows:
PSTN ---> SIP ---> CUBE ---> CUCM ---> UCCX
I can see the called number in the SIP messages and of course call manager is routing based all the called number I have done everything I can think off but it is still not showing me the PSTN called number in UCCX.
I have attached a screen shot of the Get Call Contact Info step in UCCX scripting let me know if you need to see anything else related to the script.
Any help appreciated.
ThanksIf the DNIS supplied at ingress to CUCM does not match the CTI RP DN then either you have Significant Digits stripping the called number down on the SIP trunk or a translation pattern modifying the called number before it gets to the CTI RP. In either case, CCX can only work with what CUCM gives it over the CTI QBE channel. A translation pattern resets the calling/called number to whatever transform it is performing so "Original Called Number" won't work either.
Just mentally map the PSTN DNIS to the CTI RP DN and program the script to act accordingly based on the CTI RP DN. -
Good morning,
Please, could you kindly help me with the following matter?
I have some questions regarding how CUCM builds some fields in a SIP INVITE message. Last week I was reviewing logs and I found the below R-URI when an extension calls another extension:
A number--> 7100 ---(1 SIP invite) ----> CUCM ---- (2 SIP invite) ----> B number 7101
1 SIP invite R-URI: sip:[email protected]; user=phone
2 SIP invite R-URI: sip:[email protected]:51544;transport=tcp where
5ea27f5e-033b-880c-e304-0729574bfb1 is the user part.
I thought the first invite should be sip:[email protected]; user=phone. Concerning the invite from CUCM to B number, how does CUCM build the user part from the B number?
Moreover, what are Contact ang tag fields used for in a sip message? how does CUCM build them?
Thanks in advance.
Juan.Juan,
I will explain how a sip phone signals to CUCM when making a call...Two major things happen
1. The first digit dialled is sent in the INVITE
2. The remaining digits are sent via NOTIFY (in the NOTIFY, you will see the digits that are dialled
The trace below details what happens when a sip phone makes a call. I stopped this trace after digit=8 was dialled
Called number=918772888362
Here we get INVITE with SDP from the sip phone to CUCM
29/2010 10:36:33.771 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 1717 bytes:
INVITE sip:[email protected];user=phone SIP/2.0 (first digit dialled =9)
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Call-ID: [email protected]
Max-Forwards: 70
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP9951/9.0.1
Contact:
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Test User 1" ;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,Xcisco-
service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-5.0.0,X-cisco-xsi-9.0.1
Allow-Events: kpml,dialog
Content-Length: 632
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 26964 0 IN IP4 172.18.159.152
s=SIP Call
t=0 0
m=audio 29254 RTP/SAVP 0 8 18 102 9 116 124 101
c=IN IP4 172.18.159.152
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:9 G722/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:124 ISAC/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 25466 RTP/AVP 97
c=IN IP4 172.18.159.152
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E
a=recvonly
+++Next CUCM sends trying++++
03/29/2010 10:36:33.773 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port
51682 index 2321
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Date: Mon, 29 Mar 2010 14:36:33 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
+++++Unified CM Sends a REFER to play Outside Dialtone++++
03/29/2010 10:36:33.780 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 409
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
DtOutsideDialTone
user
++++Unified CM Sends a SUBSCRIBE for KPML++++
03/29/2010 10:36:33.781 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682 index 2321
SUBSCRIBE sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To:
Call-ID: [email protected]
CSeq: 101 SUBSCRIBE
Date: Mon, 29 Mar 2010 14:36:33 GMT
User-Agent: Cisco-CUCM8.0
Event: kpml; [email protected]; from-tag=00260bd9669e07147bcb3aac-3cda8f0c
Expires: 7200
Contact:
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
<?xml version="1.0" encoding="UTF-8" ?>
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">
[x#*+]|bs
++++ Phone Sends 200 OK for the REFER and SUBSCRIBE ++++
03/29/2010 10:36:33.802 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port 51682 index 2321 with 453
bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To: ;tag=00260bd9669e07167c743311-343ee3af
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
Phone Sends 200 OK for the REFER and SUBSCRIBE
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
Unified CM Sends a SUBSCRIBE for KPML
220
++++User Dials a ‘1’, phone sends a NOTIFY to CUCM for the digit++++
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 1001 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="1" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK++++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
++++Unified CM Replies Sends a REFER to Disable Outside Dialtone+++
03/29/2010 10:36:34.353 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 401
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
Dt_NoTone
user
+++Phone Replies With 200 OK to REFER++++
03/29/2010 10:36:34.402 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 453 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To: ;tag=00260bd9669e07184b08b96b-796ab86f
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
++++User Dials a ‘8’, phone sends a NOTIFY to CUCM+++
03/29/2010 10:36:34.944 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 896 bytes:
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK647d03c1
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:34 GMT
CSeq: 1002 NOTIFY
Event: kpml
Subscription-State: active; expires=7195
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="8" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK+++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
As you can see this is similar to what you are seeing...The first digit dialled is seen in the INVITE, the remaining digits will be seen in NOTIFY.
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared" -
How does a 4G VoLTE UE know the destination SIP URI format to create the SIP INVITE
This trace is the output from an ASR500 for a VoLTE call,
For VoLTE the UE and IMS core network must support Public User Identities as defined in section 13.4 of 3GPP TS 23.003, which includes all of the following types of addresses:
•Alphanumeric SIP-URIs
sip:[email protected]
•MSISDN represented as a SIP URI:
sip:[email protected];user=phone
•MSISDN represented as a Tel URI:
tel:+447700900123
sip:[email protected]
In the SIP SDP you will see: sip:[email protected]
Mobile Originating UE: sip:[email protected]
Mobile Terminating UE: tel:+14047808898
Notice the two different formats.....
Below in the initial SIP INVITE you will see that the MO (Mobile Originating) sends the SIP URI in the proper format (1 of 3) to the MT (Mobile Terminating 4G handset).
My questions is: does the MO know the SIP URI format of the MT (User Endpoint / 4G smartphone) because it has some sort of Address Book, or is that the designated format for a SIP INVITE (to: tel+###########) because he MO knows the MSIDSN (tel number) dialed .
I do not understand how the MO knows how to format the SIP URI format of the MT (Mobile Terminating) and would appreciate any insight into this.
PROTOCOL PAYLOAD FOLLOWS:
2600:100c:8221:6dc9:f77a:8b7:5e38:a5d5.60717 > 2001:4888:3:fe0f:c0:105:0:17.5060: . [tcp sum ok] 1:1357(1356) ack 1 win 214 <nop,nop,timestamp 64706 423317258> (len 1388, hlim 64)
PROTOCOL PAYLOAD ENDS.
PDU HEX DUMP FOLLOWS:
0x0000 30ff 0594 c20d 0073 6000 0000 056c 0640 0 ......s`....l.@
0x0010 2600 100c 8221 6dc9 f77a 08b7 5e38 a5d5 & ....!m..z..^8..
0x0020 2001 4888 0003 fe0f 00c0 0105 0000 0017 ..H.............
0x0030 ed2d 13c4 e245 e405 fcb6 417e 8010 00d6 .-...E....A~....
0x0040 f720 0000 0101 080a 0000 fcc2 193b 4f0a .............;O.
0x0050 494e 5649 5445 2074 656c 3a2b 3134 3034 INVITE.tel:+1404
0x0060 3738 3038 3839 3820 5349 502f 322e 300d 7808898.SIP/2.0.
0x0070 0a4d 6178 2d46 6f72 7761 7264 733a 2037 .Max-Forwards:.7
0x0080 300d 0a52 6f75 7465 3a20 3c73 6970 3a5b 0..Route:.<sip:[
0x0090 3230 3031 3a34 3838 383a 333a 6665 3066 2001:4888:3:fe0f
0x00a0 3a63 303a 3130 353a 3a31 375d 3a35 3036 :c0:105::17]:506
0x00b0 303b 6c72 3e0d 0a56 6961 3a20 5349 502f 0 ;lr>..Via:.SIP/
0x00c0 322e 302f 5443 5020 5b32 3630 303a 3130 2. 0/TCP.[2600:10
0x00d0 3063 3a38 3232 313a 3664 6339 3a66 3737 0c:8221:6dc9:f77
0x00e0 613a 3862 373a 3565 3338 3a61 3564 355d a:8b7:5e38:a5d5]
0x00f0 3a35 3036 303b 6272 616e 6368 3d7a 3968 :5060;branch=z9h
0x0100 4734 624b 3030 3033 3335 3933 2d31 6361 G4bK00033593-1ca
0x0110 6630 3633 340d 0a43 5365 713a 2031 2049 f0634..CSeq:.1.I
0x0120 4e56 4954 450d 0a46 726f 6d3a 203c 7369 NVITE..From:.<si
0x0130 703a 2b31 3931 3236 3735 3738 3639 4076 p:+19126757869@v
0x0140 7a69 6d73 2e63 6f6d 3e3b 7461 673d 3534 zims.com>;tag=54
0x0150 3436 375f 3030 3033 3339 6130 2d33 6665 467_000339a0-3fe
0x0160 3439 3434 380d 0a54 6f3a 203c 7465 6c3a 49448..To:.<tel:
0x0170 2b31 3430 3437 3830 3838 3938 3e0d 0a41 +14047808898>..AHi Tod,
The "session target registrar " point to the SIP-TRUNK to the PSTN, as detailed exaplaination:
session target (VoIP dial peer)
To designate a network-specific address to receive calls from a VoIP or VoIPv6 dial peer, use the session target command in dial peer configuration mode. To reset to the default, use the no form of this command.
A ideal situation would be to use session target ipv4: of the ITSP:
dial-peer voice 105 voip
description **Outgoing Call to SIP Trunk**
translation-profile outgoing PSTN_Outgoing
destination-pattern 91%...........
session protocol sipv2
session target ipv4:11.11.11.11:6034 <<(1st SIP-TRUNK)
voice-class codec 2
dtmf-relay rtp-nte
no vad
dial-peer voice 106 voip
description **Outgoing 2ND Call to SIP Trunk**
translation-profile outgoing PSTN_Outgoing
destination-pattern 91%...........
session protocol sipv2
session target ipv4:22.22.22.22:6035 <<(2ND SIP-TRUNK)
voice-class codec 2
dtmf-relay rtp-nte
no vad
Rate the post accordingly.
Regards,
Kevin -
3rd Party SIP phone to CUCM via SIP Proxy
Hi all,
This is the scenario i'm currently working on :
3rd party SIP phone <--> Internet <--> SIP Proxy <--> LAN <--> CUCM
The SIP proxy basically terminates everything (REGISTER, INVITE, etc), including the RTP stream.
I can register the 3rd party SIP phone to CUCM and in CUCM and i can see SIP Proxy IP Address as the registered address of the phone.
Calls from the 3rd party SIP phone to internal Cisco or internal 3rd party SIP phone and vice versa work like charm.
The only (fatal) problem is i can only register 1 3rd party SIP phone to CUCM via this SIP proxy.
Since this SIP Proxy always use its internal IP Address and port 5060 (TCP) as its source of registration, CUCM sees multiple registrations for multiple extensions (users) come from a single IP and port, and rejects the second registration request.
It seems that CUCM binds a digest user to an IP address and port, therefore cannot accept multiple registrations from a single IP and port.
Can anyone clarify this? Or is there any way around this?
I'm using CUCM 8.6.2 and CUCM 9.X (both do not work).
Regards,
ChristianThis is most likely because of the following...
Because third-party SIP phones do not send a MAC address, they must identify themselves by using digest authentication.
The REGISTER message includes the following header:
Authorization: Digest username="xxxxxxxxxx",realm="ccmsipline",nonce="GBauADss2qoWr6k9y3hGGVDAqnLfoLk5",uri="sip:172.18.197.224",algorithm=MD5,response="126c0643a4923359ab59d4f53494552e"
The username, xxxxxxxxxxx, must match an end user that is configured in the End User Configuration window of Cisco Unified CallManager Administration. The administrator configures the SIP third-party phone with the user; for example, swhite, in the Digest User field of Phone Configuration window.
See the following document.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/5_1_3/ccmcfg/b09sip3p.html
Also Try this bug CSCef88775 -
Transfer called number from FSX port SPA8000 to FXO port analog PBX.
Hello all!
I have CUCM 8.6 which connecting with SPA8000 by SIP trunk.
FXS port SPA8000 connect to FXO port analog PBX.
When I call from CUCM to analog PBX through SPA8000, SPA8000 does not pass called number in line.
Anybody have ideas?Here is what I would recomend, I have set this up at several installations and it works well. The only difference would be that the ones that I have setup had more than 64K between sites but that is still doable so long as you keep the traffic on that link well regulated.
Anyhow. At each site install a VIC-2FXO and a VIC-2FXS into your 1760. You can use the higer density modules if you need more paths. Tie the FXOs to analog station ports on your PBX and the FXSs to analog CO ports. This may seem backwards but it is correct. Cisco's FXS is expecting to provide dialtone and the analog CO ports on the PBX are expecting to receive dial tone. Depending on what you are using for call processing ITS/CCME/CCM configure your gateway and your route pattern, etc. You will also need to be able to somehow access those fxs ports for outbound calls. You could have direct line access buttons on your phones and instruct users that when calling the remote site the must use lines 7 and 8 as an example. You could also setup a line pool code for these new lines.
Now when site A wants to call Site B, they dial whatever you wish them to dial. You do whatever translations you may wish prior to sending the call. Here is how the call flow works. User at site A accesses the line either by hitting a line button or dialing the line pool code. This grabs the analog line tied to one of the FXs ports on the router. The call is then sent over the 64K link. The router at Site B then uses one of the FXO ports to pass the call to an analog station port on the other PBX. To the PBX at site B it will appear as though someone pickedu picked up an analog station and dialed a local extension.
Hope this helps. If you need any further clarification on this let me know and I will try to clear it up further for you. -
Does SPA122 support a custom "From" header in SIP INVITE msg?
Our SIP service provider allows me to specify the calling line identification (CLI) for outgoing calls by placing the appropriate string in the "From" field of the SIP INVITE msg.
This is independent of the "User ID" needed to register with the service.
Does the SPA122 provier a way to specify a suitable "From" string?You can use the 'Display Name' field to send another name or number out to the other side.
-
How to create multiple sip trunks between cucm and cisco unified sip proxy
Dear Expert,
Is there a way to create multiple sip trunks between CUCM and Cisco Unified SIP Proxy (CUSP)? How to achieve it without creating multiple IP interfaces on the CUSP module.
CUCM: 8.5.1.10000-9
CUSP: 8.5.2
Thank you,
.wanHello Michael,
This SIP trunk is part of UCCE solution, which used between CVP, CUSP, and CUCM.
The requirements:
1) To have different codecs for different type of calls, as the phones are at few countries
2) To pass different number of digits from CUSP to CUCM for different call treatments
.wan
Maybe you are looking for
-
Unit calculation at routine in update rule
Hello, Can anybody explain me how to calculate unit in update rule routine. In update rule routine how to access infocube keyfigure like we access communication structure as comm_structure. Is there any sample code? Please help me out. Thanks, Regard
-
In trying to edit a track - I want to "Delete and Move" the track to automatically fill the area that I deleted - However, after selecting a section to delete - the "Delete and Move" option is grayed out. How do I fix this?
-
MSI Pro-E X58 help plz plz plz
So I have six GB of ddr3 memory installed on my core I7 930. I'd just gotten off the phone with MSI they told me it was a memory problem as i had 1333 ram, it was meant to be oc'd and i need to do that if i want it to work rite. the whole reason i ca
-
We bought a machine that easily captures our videos from camera to DVD, It plays back in Quicktime but will not import into IMovie for editing. Any suggestions?
-
Hi; I need a query that needs the data of the "A004 table pool", but the query doesn't accept this kind of table nor ITAB tables because they are not defined in the BAP dictionary. How can a mix ITABS or TABLE POOL in a SELECT Statement...? Thanks on