[cisco-voip] SIP transfer problems - CUCM 9.1.2

pwalenta at wi.rr.com pwalenta at wi.rr.com
Thu Jul 17 15:01:31 EDT 2014


Thanks for the tips.  Between the service change and CSS setting all is working as I would expect. 
---- "Ryan Ratliff (rratliff)" <rratliff at cisco.com> wrote: 
> Granted it's been forever since I looked at a 79XX running SIP but most transfer operations in UCM don't work if you just hang up.  We don't have a true one-step transfer like you are expecting.
> The behavior you describer, transfer->dial->hang up requires onHook transfer to be enabled (service parameter, "Transfer On-hook Enabled").
> 
> -Ryan
> 
> On Jul 17, 2014, at 12:36 PM, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:
> 
> So the Refer is coming in for transferring to extension 1001.  Is that extension in the None partition?  There's no partitions listed in the partition list so that extension needs to either be in the None partition or you need to set the Re-Routing CSS on the phone since that's what's used in a SIP Refer type transfer.
> 
> Brian
> 
> 
> On Thu, Jul 17, 2014 at 11:46 AM, <pwalenta at wi.rr.com<mailto:pwalenta at wi.rr.com>> wrote:
> So it's been a while since I've had to test equipment.  I fired up a CUCM 9.1.2 system, attached a few 7942's in SIP mode, a few third party devices.  Set regions, location bandwidth, partition, CSS etc.
> 
> I cannot however seem to transfer a call.  I hit transfer on a 7942, dial a number, hang up.  I never see the call appear on the other phone, and the call on the phone being transfered drops as well.
> 
> I have tried adding in MTP, adding a CSS to the line itself all to no avail.
> 
> Any ideas why I keep getting messages like this in the logs (and then shortly thereafter, a 404 not found shows up):
> 
> 00007706.001 |10:00:33.619 |AppInfo  |//SIP/Stack/Info/0x0/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 (SIP_APPLICATION_MSG), for event 33 (SIPSPI_EV_CC_REFER_RESP)
> 00007705.004 |10:00:33.619 |AppInfo  |Digit Analysis: Host Address=10.30.0.50 DOES NOT MATCH top level org domain.
> 00007705.005 |10:00:33.619 |AppInfo  |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
> 00007705.006 |10:00:33.619 |AppInfo  |Digit analysis: match(pi="1",fqcn="1004", cn="1004", plv="5", pss="", TodFilteredPss="", dd="1001",dac="0")
> 00007705.007 |10:00:33.619 |AppInfo  |Digit analysis: potentialMatches=NoPotentialMatchesExist
> 00007706.002 |10:00:33.619 |AppInfo  |//SIP/Stack/Transport/0x0/sipSPITransportSendMessage: msg=0xb262b010, addr=10.4.0.182, port=50187, sentBy_port=5060, is_req=0, transport=1,
> 00007706.003 |10:00:33.619 |AppInfo  |//SIP/Stack/Transport/0x0/sipTransportPostSendMessage: Posting send for msg=0xb262b010, addr=10.4.0.182, port=5060, connId=0 for UDP
> 00007707.000 |10:00:33.619 |SdlSig   |SNFNotifyReq                           |call_hold                      |SIPStationCdfc(1,100,67,2)       |SIPStationD(1,100,66,15)         |1,100,238,1.312^10.4.0.182^*             |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0]  SNFSubscriptionId = 1|0|3, SNFNotifyMsg: state = 1, reason = 0, retryAfter = -1, subscriptionType =  REFER , content = SNFSmartBase
> 
> 00007706.004 |10:00:33.619 |AppInfo  |//SIP/Stack/States/0x10033618/sipSPIChangeState: 0x10033618 : State change from (STATE_RECD_XFER, SUBSTATE_NONE)  to (STATE_ACTIVE, SUBSTATE_NONE)
> 00007708.000 |10:00:33.619 |SdlSig   |DaRes                                  |intercept_da                   |Cdcc(1,100,212,1)                |Da(1,100,204,1)                  |1,100,238,1.312^10.4.0.182^*             |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] CI=18513169 Block NoPotentialMatchesExist OnNetpatternUsage =2requestID =0
> 00007708.001 |10:00:33.619 |AppInfo  |Cdcc(0000001) - verifySymmetricPrecedenceAfterJoined - A.pl[5], B.pl[5]
> 00007709.000 |10:00:33.619 |SdlSig   |SIPSPISignal                           |wait                           |SIPUdp(1,100,63,1)               |SIPHandler(1,100,72,1)           |1,100,238,1.312^10.4.0.182^*             |*TraceFlagOverrode
> 00007709.001 |10:00:33.619 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.4.0.182:[5060]:
> [994,NET]
> SIP/2.0 202 Accepted
> Via: SIP/2.0/UDP 10.4.0.182:5060;branch=z9hG4bK2256cac4
> From: <sip:1009 at 10.30.0.50<mailto:sip%3A1009 at 10.30.0.50>>;tag=001a2f80356c00084bdc1e9d-3cb95c08
> To: "1004" <sip:1004 at 10.30.0.50<mailto:sip%3A1004 at 10.30.0.50>>;tag=236~f9582617-b769-4b66-9a4c-055f00fc8c88-18513170
> Date: Wed, 16 Jul 2014 16:00:33 GMT
> Call-ID: 465d0400-3c61a191-2a-32001e0a at 10.30.0.50<mailto:465d0400-3c61a191-2a-32001e0a at 10.30.0.50>
> CSeq: 102 REFER
> Contact: <sip:1004 at 10.30.0.50:5060<http://sip:1004@10.30.0.50:5060/>>
> Content-Length: 0
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 



More information about the cisco-voip mailing list