cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1784
Views
0
Helpful
5
Replies

Transfer Attempt Fails with 404 User Not Found

lkoutsavlis
Level 1
Level 1

I'm running a Cisco CUCM with multiple partitions along with a SIP trunk connected to another SIP based PBX used as an IVR. I'm able to place calls from any registered softphone or IP Communicator phone through the SIP Trunk and have IVR answer the call. IVR is also able to originate it's own call to one of the Softphones or IP Communicator phones without a problem.

When IVR attempts to perform a transfer via (REFER) from a softphone to another IP Communicator phone or vice versa we are getting a 404 User Not Found response. Any direction\help would be appreciated. I have this working on CUCM 8.6 but without TLS if that matters at all

26709521.003 |10:32:18.226 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.130.196 on port 49498 index 21968 with 684 bytes:
[564133,NET]
REFER sip:8618@10.11.80.182:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.50.130.196;branch=z9hG4bKaZ2pc5my1gy0K
Max-Forwards: 70
From: <sip:3250@10.50.130.196>;tag=SUKFv17pBc2yF
To: <sip:8618@10.11.80.182>;tag=204361~c84093ec-dc7a-4720-9922-e2eab9ff0a2b-56104686
Call-ID: a6e5c200-84a1ce7d-10ef8-b6500b0a@10.11.80.182
CSeq: 100312704 REFER
Contact: <sip:3250@10.50.130.196:5061;transport=tls>
User-Agent: FreeSWITCH-mod_sofia/1.4.12~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Refer-To: <sip:8648@10.11.80.182>
Referred-By: <sip:10.50.130.196>
Content-Length: 0

At first the transfer is accepted and IVR recieves 3 messages (Accepted,Notify, Update)

26709554.001 |10:32:18.229 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.130.196 on port 49498 index 21968
[564134,NET]
SIP/2.0 202 Accepted
Via: SIP/2.0/TLS 10.50.130.196;branch=z9hG4bKaZ2pc5my1gy0K
From: <sip:3250@10.50.130.196>;tag=SUKFv17pBc2yF
To: <sip:8618@10.11.80.182>;tag=204361~c84093ec-dc7a-4720-9922-e2eab9ff0a2b-56104686
Date: Fri, 09 Dec 2016 15:32:18 GMT
Call-ID: a6e5c200-84a1ce7d-10ef8-b6500b0a@10.11.80.182
Server: Cisco-CUCM10.5
CSeq: 100312704 REFER
Contact: <sip:8618@10.11.80.182:5061;transport=tls>
Content-Length: 0

26709573.001 |10:32:18.230 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.130.196 on port 5061 index 21961
[564135,NET]
NOTIFY sip:3250@10.50.130.196:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.11.80.182:5061;branch=z9hG4bK113fa32f0a8d1
From: <sip:8618@10.11.80.182>;tag=204361~c84093ec-dc7a-4720-9922-e2eab9ff0a2b-56104686
To: <sip:3250@10.50.130.196>;tag=SUKFv17pBc2yF
Call-ID: a6e5c200-84a1ce7d-10ef8-b6500b0a@10.11.80.182
CSeq: 102 NOTIFY
Max-Forwards: 70
Date: Fri, 09 Dec 2016 15:32:18 GMT
User-Agent: Cisco-CUCM10.5
Event: refer
Subscription-State: active;expires=60
Contact: <sip:8618@10.11.80.182:5061;transport=tls>
P-Asserted-Identity: <sip:8618@10.11.80.182>
Content-Type: message/sipfrag;version=2.0
Content-Length: 20

SIP/2.0 100 Trying

26709603.001 |10:32:18.233 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.130.196 on port 5061 index 21961
[564136,NET]
UPDATE sip:3250@10.50.130.196:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.11.80.182:5061;branch=z9hG4bK113fb1a344a5d
From: <sip:8618@10.11.80.182>;tag=204361~c84093ec-dc7a-4720-9922-e2eab9ff0a2b-56104686
To: <sip:3250@10.50.130.196>;tag=SUKFv17pBc2yF
Date: Fri, 09 Dec 2016 15:32:18 GMT
Call-ID: a6e5c200-84a1ce7d-10ef8-b6500b0a@10.11.80.182
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 UPDATE
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= Unknown; gci= 3-16761; isVoip
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Min-SE: 1800
P-Asserted-Identity: <sip:8618@10.11.80.182>
Remote-Party-ID: <sip:8618@10.11.80.182>;party=calling;screen=yes;privacy=off
Contact: <sip:8618@10.11.80.182:5061;transport=tls>
Content-Length: 0

After a short period another Notify is sent to IVR

26709630.001 |10:32:18.239 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.130.196 on port 5061 index 21961
[564137,NET]
NOTIFY sip:3250@10.50.130.196:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.11.80.182:5061;branch=z9hG4bK113fc440e151b
From: <sip:8618@10.11.80.182>;tag=204361~c84093ec-dc7a-4720-9922-e2eab9ff0a2b-56104686
To: <sip:3250@10.50.130.196>;tag=SUKFv17pBc2yF
Call-ID: a6e5c200-84a1ce7d-10ef8-b6500b0a@10.11.80.182
CSeq: 104 NOTIFY
Max-Forwards: 70
Date: Fri, 09 Dec 2016 15:32:18 GMT
User-Agent: Cisco-CUCM10.5
Event: refer
Subscription-State: terminated
Contact: <sip:8618@10.11.80.182:5061;transport=tls>
P-Asserted-Identity: <sip:8618@10.11.80.182>
Content-Type: message/sipfrag;version=2.0
Content-Length: 23

SIP/2.0 404 Not Found

5 Replies 5

dashoward
Level 1
Level 1

I'd treat the SIP trunk like an Cisco Unity Connection SIP Trunk integration. I haven't found Cisco documentation on the actual definition but this has solved a couple of issues for me in the past when integrating with Unity Connection. When a call reaches Cisco Unity Connection from an inbound call it is then transferred to the opening greeting. Your IVR is trying to do a transfer so this sounds similar. I'd recommend on your SIP Trunk Configuration page to check the "Redirecting Diversion Header Delivery - Outbond" on the Outbound calls section. And for safe measure check the option on the Inbound Calls also. "Redirecting Diversion Header Delivery - Inbound". Let me know if this works for you. DASH

I gave that a shot setting both Inbound and Outbound Redirecting Diversion but not luck. I thought that was going to be it. Thanks for the recommendation.

Do you also have Run on all nodes checked on the trunk configuration page?

I just gave that a shot on both of my SIP Trunks along with the Diversion settings for inbound\outbound. Same results.

I too am having this issue. I was wondering if you ever resolved it?