[cisco-voip] SIP transfer problems - CUCM 9.1.2

Thu Jul 17 13:20:07 EDT 2014

Yea, you can't hang up the call on a refer transfer until CUCM sends the
Notify with the 200OK right after the Refer is accepted at least on a SIP
Trunk Refer.  I would imagine it would work fairly similar on the 79XX
running SIP.  Might be worth just waiting like 10 seconds before hanging up
and see if that helps.

On Thu, Jul 17, 2014 at 1:06 PM, 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> 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> 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>;tag=001a2f80356c00084bdc1e9d-3cb95c08
>> To: "1004" <sip:1004 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
>> CSeq: 102 REFER
>> Contact: <sip:1004 at 10.30.0.50:5060>
>> Content-Length: 0
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>  _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140717/988b7e0f/attachment.html>