How do I respond 200 OK to a hold request in TCL IVR?

Version 1

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 10:45:07 AM
    Can ypu please show the section of your script whre you need to make the hold ? Is this "hold" after connecting calling and called parties ?
     
    Thanks !
    This document was generated from CDN thread

    Created by: Keith Haugen on 15-05-2013 10:37:03 AM
    My application has to handle hold requests on its own and it works fine for PSTN <-> SIP calls, but for SIP to SIP calls I need to send a 200 OK back to the console that made the hold request and I can not figure out which TCL IVR command will allow for this.  Does anyone know?

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 11:05:01 AM
    The hold is after the call has been established (both parties are connected).  Here is my on-hold handler:
     
    proc act_OnHold { } {
       global hold_status
       global send_hold_ok
    # Process the on hold so that we can put a failed transfer
    # back in the correct hold state.
    # "unknown" is only used for hold requests
       if { "unknown" == [infotag get evt_feature_type] } {
    # Only need to do hold processing if there is an audio
    # connection.
          if { [infotag get con_all] != ""} {
             fsm setstate CALL_ONHOLD
             set hold_status "on"
    # Tear down the audio connection between the 2 legs
             connection destroy con_all
             set send_hold_ok "yes"
          }
       }
    }

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 11:38:30 AM
    SIP <-> PSTN trace:
    Received:
    INVITE sip:918473872681@10.5.55.250:5061;transport=tls SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-1ac5157abd704477-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:918473872681@10.5.55.250>;tag=AED56AFC-22F3
    From: "234"<sip:234@10.5.55.250:5061>;tag=4e195561
    Call-ID: MjYyN2IyZmMzMWFlNGRjYTM3ODY2ZmE3ZDVhMTE1Mzc.
    CSeq: 2 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 90
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 194
    v=0
    o=- 13013109245375000 13013109245375000 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32565 RTP/AVP 0 8
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendonly
    SIP: Attribute mid, level 1 instance 1 not found.
    2741244: *May 15 16:31:44.017: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-1ac5157abd704477-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=4e195561
    To: <sip:918473872681@10.5.55.250>;tag=AED56AFC-22F3
    Date: Wed, 15 May 2013 16:31:44 GMT
    Call-ID: MjYyN2IyZmMzMWFlNGRjYTM3ODY2ZmE3ZDVhMTE1Mzc.
    CSeq: 2 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Content-Length: 0

    2741245: *May 15 16:31:44.021: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent: (this is the message I do not see in the SIP to SIP scenario, back to the SP phone doing the hold)
    SIP/2.0 200 OK
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-1ac5157abd704477-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=4e195561
    To: <sip:918473872681@10.5.55.250>;tag=AED56AFC-22F3
    Date: Wed, 15 May 2013 16:31:44 GMT
    Call-ID: MjYyN2IyZmMzMWFlNGRjYTM3ODY2ZmE3ZDVhMTE1Mzc.
    CSeq: 2 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: <sip:8475760534@10.5.55.250>;party=called;screen=no;privacy=off
    Contact: <sip:918473872681@10.5.55.250:5061;transport=tls>
    Supported: replaces
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Require: timer
    Session-Expires:  1800;refresher=uac
    Supported: timer
    Content-Type: application/sdp
    Content-Length: 199
    v=0
    o=CiscoSystemsSIP-GW-UserAgent 398 8835 IN IP4 10.5.55.250
    s=SIP Call
    c=IN IP4 10.5.55.250
    t=0 0
    m=audio 19110 RTP/AVP 8
    c=IN IP4 10.5.55.250
    a=recvonly
    a=rtpmap:8 PCMA/8000
    a=ptime:20
     
    SIP to SIP -- the 200 OK is received from the SIP phone being held but it is not sent to the SIP phone doing the holding:
    Received:
    INVITE sip:233@10.5.55.250:5061;transport=tls SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-107fb522a5d1624b-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:233@10.5.55.250>;tag=AAC73C70-13EA
    From: "234"<sip:234@10.5.55.250:5061>;tag=5efcbe67
    Call-ID: NTZlZjY0ODVlOTkwN2YwZDExMDRiMTlhMjZmMTAyMmY.
    CSeq: 2 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 90
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 194
    v=0
    o=- 13013041199546875 13013041199546875 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32565 RTP/AVP 0 8
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendonly
    2670868: *May 14 21:37:38.498: //536775/4F960DC0B1D8/SIP/Error/ccsip_api_request_offer:
     Unable to add passthru hdrs to container
    SIP: Attribute mid, level 1 instance 1 not found.
    SIP: (536776) Group (a= group line) attribute, level 65535 instance 1 not found.
    2670869: *May 14 21:37:38.502: //536775//TCL :/tcl_PutsObjCmd: ev_mode_update_ind is being ignored
    2670870: *May 14 21:37:38.502:
    2670871: *May 14 21:37:38.502: //536776/4F960DC0B1D8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    INVITE sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKD9825D3
    From: sip:234@10.5.55.250;tag=AAC73C64-861
    To: <sip:233@10.5.55.250>;tag=6fd59165
    Date: Tue, 14 May 2013 21:37:38 GMT
    Call-ID: 4F987EF8-BC1511E2-B1DECBB5-8C3C255E@10.5.55.250
    Supported: timer,resource-priority,replaces
    Min-SE:  1800
    Cisco-Guid: 1335233984-3155497442-2983775157-2352751966
    User-Agent: Cisco-SIPGateway/IOS-15.2.3.T2
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    CSeq: 102 INVITE
    Max-Forwards: 70
    Timestamp: 1368567458
    Contact: <sip:234@10.5.55.250:5060>
    Expires: 180
    Allow-Events: telephone-event
    Session-Expires:  1800;refresher=uac
    Content-Type: application/sdp
    Content-Length: 224
    v=0
    o=CiscoSystemsSIP-GW-UserAgent 3163 8553 IN IP4 10.5.55.250
    s=SIP Call
    c=IN IP4 10.5.55.250
    t=0 0
    m=audio 19068 RTP/AVP 8 19
    c=IN IP4 10.5.55.250
    a=sendonly
    a=rtpmap:8 PCMA/8000
    a=rtpmap:19 CN/8000
    a=ptime:20
    2670872: *May 14 21:37:38.506: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-107fb522a5d1624b-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=5efcbe67
    To: <sip:233@10.5.55.250>;tag=AAC73C70-13EA
    Date: Tue, 14 May 2013 21:37:38 GMT
    Call-ID: NTZlZjY0ODVlOTkwN2YwZDExMDRiMTlhMjZmMTAyMmY.
    CSeq: 2 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Content-Length: 0

    2670873: *May 14 21:37:38.506: //536775//TCL :/tcl_PutsObjCmd: ev_mode_update_ind is being ignored
    2670874: *May 14 21:37:38.506:
    2670875: *May 14 21:37:38.506: //536775//TCL :/tcl_PutsObjCmd: ev_mode_update_ind is being ignored
    2670876: *May 14 21:37:38.506:
    2670877: *May 14 21:37:38.506: //536775//TCL :/tcl_PutsObjCmd: ev_destroy_done is being ignored
    2670878: *May 14 21:37:38.506:
    2670879: *May 14 21:37:38.510: //536776/4F960DC0B1D8/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKD9825D3
    Require: timer
    Contact: <sip:233@10.5.55.202:62321>
    To: <sip:233@10.5.55.250>;tag=6fd59165
    From: <sip:234@10.5.55.250>;tag=AAC73C64-861
    Call-ID: 4F987EF8-BC1511E2-B1DECBB5-8C3C255E@10.5.55.250
    CSeq: 102 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 1800
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 170
    v=0
    o=- 13013041199578125 13013041199578125 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32566 RTP/AVP 8
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=recvonly
    2670880: *May 14 21:37:38.510: //536776/4F960DC0B1D8/SIP/Error/ccsip_api_response_answer:
     Unable to add passthru headers to container
    SIP: Attribute mid, level 1 instance 1 not found.
    2670881: *May 14 21:37:38.510: //536776/4F960DC0B1D8/SIP/Error/sip_iwf_common_send_audio_channel_info:
     Unable to report channelInfo
    2670882: *May 14 21:37:38.514: //536775//TCL :/tcl_PutsObjCmd: ev_mode_update_ind is being ignored
    2670883: *May 14 21:37:38.514:
    2670884: *May 14 21:37:38.514: //536776/4F960DC0B1D8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    ACK sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKD9924C7
    From: sip:234@10.5.55.250;tag=AAC73C64-861
    To: <sip:233@10.5.55.250>;tag=6fd59165
    Date: Tue, 14 May 2013 21:37:38 GMT
    Call-ID: 4F987EF8-BC1511E2-B1DECBB5-8C3C255E@10.5.55.250
    Max-Forwards: 70
    CSeq: 102 ACK
    Allow-Events: telephone-event
    Content-Length: 0
     

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 11:20:24 AM
    And the 200 OK is responding to ?

    Maybe SIP messge trace and show where we need a 200 OK ? If you can show PSTN <-> SIP trace and indicate the 200 OK that is missing in SIP to SIP scenario that helps
     
    Thanks !

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 12:13:51 PM
    SIP to SIP -- the 200 OK is received from the SIP phone being held but it is not sent to the SIP phone doing the holding: Received: INVITE sip:233@10.5.55.250:5061;transport=tls SIP/2.0 This original INVITE is from calling party right ? Missing 200 OK here right ? If answer is yes to both. I guess you don't have "leg connect leg_incoming" in you script. Sent: INVITE sip:233@10.5.55.202:62321 SIP/2.0 SIP/2.0 100 Trying Received: SIP/2.0 200 OK Sent: ACK sip:233@10.5.55.202:62321 SIP/2.0  

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 02:30:14 PM
    Yes, if sip phone A called SIP phone B, it is SIP phone A that is sending the hold request in the flow I showed.  The missing 200 OK is the response back to SIP phone A that is missing.  But I am about to do a connection destroy on the leg for SIP phone A and SIP phone B, meaning there is already a connection that I am about to destroy.  So I need to send the leg connect after I have gotten the ev_destory_done event for the connection?  I can not tell from the TCL IVR guide either -- will sending the leg connect do anything internally (like reconnect the incoming and outgoing legs)?  I don't think I want to do that, do I?  Or would I just re-destroy the connection after I got whatever event the leg connect causes to be generated?

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 02:54:31 PM
    No, when you recieve "ev_setup_indication" before doing leg setup to B
    "leg connect" may not need it but if we need to send 200 OK from GW to respond the orginal INVITE then we can use it to send 200 OK.
    If we want to do it precisely can do the follwoing, but for you just add leg connect leg_incoming when handling ev_setup_indication is good enough.
                   set legID [string trim [infotag get leg_incoming]]
                   set legState [infotag get leg_state $legID]
                   #check leg state before do "leg connect
                   #to make sure leg is not connected already
                   if {$legState != "lg_005" && $legState != "lg_008"} {
                       if {$legState == "lg_001"} {
                           puts "\n>>>>>>>>>legstate = lg_001<<<<<<<<<<<\n"
                           leg setupack leg_incoming
                           leg proceeding leg_incoming
                           leg connect leg_incoming
                       } elseif {$legState == "lg_002"} {
                            puts "\n>>>>>>>>>legstate = lg_002<<<<<<<<<<<\n"
                           leg proceeding leg_incoming
                           leg connect leg_incoming
                       } else {
                            puts "\n>>>>>>>>>legstate = $legState<<<<<<<<<<<\n"
                            leg connect leg_incoming
                       }
                   }
                   # end of modification
                   # lg_001 --> LEG_INCOMING_FIRST
                   # lg_002 --> LEG_INCACKED
                   # lg_003 --> LEG_INCPROCEED
                   # lg_005 --> LEG_INCCONNECTED
                   # lg_008 --> LEG_OUTPROCEED

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 03:23:10 PM
    The call is already set up and active for awhile -- I handled the ev_setup_indication already.  This is for a re-invite with the sendonly flag set (a hold request).  I am not getting a 200 OK back to the SIP phone that requested the hold, which is causing problems later on (e.g., if I am doing a blind transfer the REFER is never sent because the transferring phone is waiting for the 200 OK from the hold request)

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 03:49:07 PM
    Yes, that could be different. Maybe let me know what you like to do ?  You like to to blind transfer and you need to send REFER out when receive REFER ? Are you using Cisco SIP phone ? Is it really displaying "Blndxfr" or just "Transfer". If you are using the one display "Transfer"  then it's not really doing blind transfer. But if you see the one display "blndxfr" then it's fine. I am not phone expert, I don't know where we can change the configuration. Also please show me how you do this -- "if I am doing a blind transfer the REFER is never sent" i.e. leg setup after destory legs

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 04:37:58 PM
    Using 3rd party SIP phones but the Cisco 29xx gateway, when doing a SIP to SIP call I do a blind transfer (which causes an on-hold request before the refer).  It works fine when the call is SIP <-> PSTN, I assume because the gateway is proxying for the PSTN side of the call and thus automatically responds with the 200 OK to the hold request.  But for SIP to SIP, the "hold" invite goes to the other SIP phone, which responds with a 200 OK, but this 200 OK is never passed on to the SIP phone doing the blind transfer, so that phone does not send out the REFER:
     
    On an established phone call between SIP phone 1 and SIP phone 2:
    SIP phone 1 -> Cisco 29xx gateway INVITE with sendonly attribute
    Cisco 29xx gateway -> SIP phone 2 INVITE with sendonly attribute
    Cisco29xx gateway -> SIP phone 1 100 Trying
    SIP phone 2 -> Cisco 29xx gateway 200 OK with recvonly attribute
    Cisco 29xx gateway -> SIP phone 2 ACK
    Now there should be a 200 OK from the Cisco 29xx gateway to SIP phone 1, but there is not, so SIP phone 1 never sends the REFER.
     
     
    Once I get the refer I do a leg setup after destroying the connection between the two phone legs (so connection destroy and upon receiving the ev_destroy_done event do the leg setup), to connect SIP phone 2 to the referred destination.  That works fine for SIP <-> PSTN calls, but I have not yet gotten that far for SIP to SIP calls.

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 04:53:09 PM
    The scenario you descbibed has been tested and used (of cause the equipment maybe different but it is in all SIP environment) So when you do leg setup between XEE and XTO after ev_destroy_done, we can do two things to XTO. One is using INVITE one is using REFR. So the question to ask is that can XTO use both methods or just one of them can work ? Can ypu please show me how you do leg setup for XEE and XTO ? (i.e. callInfo() information), I guess that you are comsuing REFER not passing REFER. Thanks.  

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 05:11:40 PM
    Also what really happen after you did leg setup ? what is the setup status ? Any leg got disconneted ?

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 15-05-2013 05:52:17 PM
    I do not even get that far with SIP to SIP because I never get the REFER.  The reason I never get the REFER is my hold request that comes before the REFER in a blind transfer does not get a response.  I need to get my application to respond to the hold request, so that is what I need help with.  Once I can respond to the hold request (or pass through the response from the other SIP phone, but I don't think my TCL application is notified when the response comes in, unless it is one of the ev_mode_update_ind events), then I can worry about processing the REFER.

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 15-05-2013 06:03:04 PM
    I see, the scenario I was talking abount did get the REFER. If you can provide entire SIP trace and deb voip ccapi inout I can ask around for you. You ca send it to developer-support@cisco.com if you feel more comfortable in that way.
     

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 16-05-2013 01:40:04 PM
    I setup two Cisco sip phone on 2900 and did the same test I was able to see 200 OK replying to that sendonly INVITE and tranfer was successful (I only have 2 SIP phone so XTO is a SCCP phone, but I think this passed what you are missing)
     
    Did you try transfer without Tcl ? Is it OK ?
    My IOS version is:
    c2900-universalk9-mz.SPA.153-1.T.bin
     
    Thanks

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 16-05-2013 01:48:43 PM
    Yes, if I use the default application trying to transfer a SIP to SIP call works fine using c2900-universalk9-mz.SPA.152-3.T2.bin.  Here is the SIP trace with debug voip ccapi inout turned on:
    2859845: *May 16 18:43:22.887: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:233@10.5.55.250 SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-3d211143eb101067-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:233@10.5.55.250>
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 1 INVITE
    Session-Expires: 1800
    Min-SE: 90
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path, 100rel
    User-Agent: MCC7500
    Content-Length: 194
    v=0
    o=- 13013203544687500 13013203544687500 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32565 RTP/AVP 0 8
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendrecv
    2859846: *May 16 18:43:22.891: //-1/5209A51889E8/CCAPI/cc_api_display_ie_subfields:
       cc_api_call_setup_ind_common:
       cisco-username=234
       ----- ccCallInfo IE subfields -----
       cisco-ani=sip:234@10.5.55.250:5061
       cisco-anitype=0
       cisco-aniplan=0
       cisco-anipi=0
       cisco-anisi=3
       dest=sip:233@10.5.55.250
       cisco-desttype=0
       cisco-destplan=0
       cisco-rdie=FFFFFFFF
       cisco-rdn=
       cisco-rdntype=0
       cisco-rdnplan=0
       cisco-rdnpi=-1
       cisco-rdnsi=-1
       cisco-redirectreason=-1   fwd_final_type =0
       final_redirectNumber =
       hunt_group_timeout =0
    2859847: *May 16 18:43:22.891: //-1/5209A51889E8/CCAPI/cc_api_call_setup_ind_common:
       Interface=0x2D32C574, Call Info(
       Calling Number=sip:234@10.5.55.250:5061,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed),
       Called Number=sip:233@10.5.55.250(TON=Unknown, NPI=Unknown),
       Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
       Incoming Dial-peer=40002, Progress Indication=NULL(0), Calling IE Present=TRUE,
       Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=575579
    2859848: *May 16 18:43:22.891: //-1/5209A51889E8/CCAPI/ccCheckClipClir:
       In: Calling Number=sip:234@10.5.55.250:5061(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed)
    2859849: *May 16 18:43:22.891: //-1/5209A51889E8/CCAPI/ccCheckClipClir:
       Out: Calling Number=sip:234@10.5.55.250:5061(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed)
    2859850: *May 16 18:43:22.891: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859851: *May 16 18:43:22.891: :cc_get_feature_vsa malloc success
    2859852: *May 16 18:43:22.891: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859853: *May 16 18:43:22.891:  cc_get_feature_vsa count is 1
    2859854: *May 16 18:43:22.891: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859855: *May 16 18:43:22.891: :FEATURE_VSA attributes are: feature_name:0,feature_time:856970728,feature_id:2541
    2859856: *May 16 18:43:22.891: //575579/5209A51889E8/CCAPI/cc_api_call_setup_ind_common:
       Set Up Event Sent;
       Call Info(Calling Number=(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed),
       Called Number=(TON=Unknown, NPI=Unknown))
    2859857: *May 16 18:43:22.891: //575579/5209A51889E8/CCAPI/cc_process_call_setup_ind:
       Event=0x2D5FC6B0
    2859858: *May 16 18:43:22.891: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
       Try with the demoted called number 233
    2859859: *May 16 18:43:22.895: //575579/5209A51889E8/CCAPI/ccCallSetContext:
       Context=0x33165A88
    2859860: *May 16 18:43:22.895: //575579/5209A51889E8/CCAPI/cc_process_call_setup_ind:
       >>>>CCAPI handed cid 575579 with tag 40002 to app "_ManagedAppProcess_outbound_call"
    2859861: *May 16 18:43:22.899: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-3d211143eb101067-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    To: <sip:233@10.5.55.250>
    Date: Thu, 16 May 2013 18:43:22 GMT
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 1 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Content-Length: 0

    2859862: *May 16 18:43:22.903: //575579/5209A51889E8/CCAPI/ccCallSetupAck:
       Call Id=575579
    2859863: *May 16 18:43:22.903: //575579/5209A51889E8/CCAPI/cc_api_set_transfer_info:
       Transfer Number=, Transfer Reason=0x0
    2859864: *May 16 18:43:22.903: //575579/5209A51889E8/CCAPI/ccCallProceeding:
       Progress Indication=NULL(0)
    2859865: *May 16 18:43:22.903: //-1/xxxxxxxxxxxx/CCAPI/ccGetMemPoolFromContainer:
       mempool not found from usrContainer(34EFE5C4)
    2859866: *May 16 18:43:22.903: //-1/xxxxxxxxxxxx/CCAPI/ccCreateMemPoolInContainer:
       Mempool(34D1F32C) created in usrContainer(34EFE5C4)
    2859867: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccCallSetupRequest:
       Destination=, Calling IE Present=TRUE, Mode=0,
       Outgoing Dial-peer=40003, Params=0x3316AC98, Progress Indication=NULL(0)
    2859868: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccCheckClipClir:
       In: Calling Number=sip:234@10.5.55.250:5061(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed)
    2859869: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccCheckClipClir:
       Out: Calling Number=sip:234@10.5.55.250:5061(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed)
    2859870: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccCallSetupRequest:
       Destination Pattern=233$, Called Number=sip:233@10.5.55.250, Digit Strip=FALSE
    2859871: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccCallSetupRequest:
       Calling Number=sip:234@10.5.55.250:5061(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed),
       Called Number=sip:233@10.5.55.250(TON=Unknown, NPI=Unknown),
       Redirect Number=, Display Info=234
       Account Number=234, Final Destination Flag=TRUE,
       Guid=5209A518-BD8F-11E2-89E8-CBB58C3C255E, Outgoing Dial-peer=40003
    2859872: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/cc_api_display_ie_subfields:
       ccCallSetupRequest:
       cisco-username=234
       ----- ccCallInfo IE subfields -----
       cisco-ani=sip:234@10.5.55.250:5061
       cisco-anitype=0
       cisco-aniplan=0
       cisco-anipi=0
       cisco-anisi=3
       dest=sip:233@10.5.55.250
       cisco-desttype=0
       cisco-destplan=0
       cisco-rdie=FFFFFFFF
       cisco-rdn=
       cisco-rdntype=0
       cisco-rdnplan=0
       cisco-rdnpi=-1
       cisco-rdnsi=-1
       cisco-redirectreason=-1   fwd_final_type =0
       final_redirectNumber =
       hunt_group_timeout =0
    2859873: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccIFCallSetupRequestPrivate:
       Interface=0x2D32C574, Interface Type=3, Destination=, Mode=0x0,
       Call Params(Calling Number=sip:234@10.5.55.250:5061,(Calling Name=234)(TON=Unknown, NPI=Unknown, Screening=Network, Presentation=Allowed),
       Called Number=sip:233@10.5.55.250(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
       Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=40003, Call Count On=FALSE,
       Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
    2859874: *May 16 18:43:22.907: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859875: *May 16 18:43:22.907: :cc_get_feature_vsa malloc success
    2859876: *May 16 18:43:22.907: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859877: *May 16 18:43:22.907:  cc_get_feature_vsa count is 2
    2859878: *May 16 18:43:22.907: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
      
    2859879: *May 16 18:43:22.907: :FEATURE_VSA attributes are: feature_name:0,feature_time:856971400,feature_id:2542
    2859880: *May 16 18:43:22.907: //575580/5209A51889E8/CCAPI/ccIFCallSetupRequestPrivate:
       SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
    2859881: *May 16 18:43:22.907: //575580/5209A51889E8/CCAPI/ccCallSetContext:
       Context=0x3316AC48
    2859882: *May 16 18:43:22.907: //575579/5209A51889E8/CCAPI/ccSaveDialpeerTag:
       Outgoing Dial-peer=40003
    2859883: *May 16 18:43:22.911: //575580/5209A51889E8/CCAPI/cc_api_call_proceeding:
       Interface=0x2D32C574, Progress Indication=NULL(0)
    2859884: *May 16 18:43:22.911: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    INVITE sip:233@10.5.55.250:5060 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDEE211
    Remote-Party-ID: "234" <sip:234@10.5.55.250>;party=calling;screen=yes;privacy=off
    From: sip:234@10.5.55.250;tag=B4748F4C-2066
    To: sip:233@10.5.55.250
    Date: Thu, 16 May 2013 18:43:22 GMT
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    Supported: timer,resource-priority,replaces
    Min-SE:  1800
    Cisco-Guid: 1376363800-3180270050-2313735093-2352751966
    User-Agent: Cisco-SIPGateway/IOS-15.2.3.T2
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    CSeq: 101 INVITE
    Timestamp: 1368729802
    Contact: <sip:234@10.5.55.250:5060>
    Expires: 180
    Allow-Events: telephone-event
    Max-Forwards: 69
    Session-Expires:  1800
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 212
    v=0
    o=CiscoSystemsSIP-GW-UserAgent 7964 2822 IN IP4 10.5.55.250
    s=SIP Call
    c=IN IP4 10.5.55.250
    t=0 0
    m=audio 19162 RTP/AVP 8 19
    c=IN IP4 10.5.55.250
    a=rtpmap:8 PCMA/8000
    a=rtpmap:19 CN/8000
    a=ptime:20
    2859885: *May 16 18:43:22.919: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 180 Ringing
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDEE211
    Contact: <sip:233@10.5.55.202:62321>
    To: <sip:233@10.5.55.250>;tag=c0360278
    From: <sip:234@10.5.55.250>;tag=B4748F4C-2066
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    CSeq: 101 INVITE
    User-Agent: MCC7500
    Content-Length: 0

    2859886: *May 16 18:43:22.919: //575580/5209A51889E8/CCAPI/cc_api_call_alert:
       Interface=0x2D32C574, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
    2859887: *May 16 18:43:22.919: //575580/5209A51889E8/CCAPI/cc_api_call_alert:
       Call Entry(Retry Count=0, Responsed=TRUE)
    2859888: *May 16 18:43:22.919: //575579/5209A51889E8/CCAPI/ccCallAlert:
       Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
    2859889: *May 16 18:43:22.919: //575579/5209A51889E8/CCAPI/ccCallAlert:
       Call Entry(Responsed=TRUE, Alert Sent=TRUE)
    2859890: *May 16 18:43:22.919: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 180 Ringing
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-3d211143eb101067-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    Date: Thu, 16 May 2013 18:43:22 GMT
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 1 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: <sip:233@10.5.55.250>;party=called;screen=no;privacy=off
    Contact: <sip:233@10.5.55.250:5061;transport=tls>
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Content-Length: 0

    2859891: *May 16 18:43:25.455: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDEE211
    Require: timer
    Contact: <sip:233@10.5.55.202:62321>
    To: <sip:233@10.5.55.250>;tag=c0360278
    From: <sip:234@10.5.55.250>;tag=B4748F4C-2066
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    CSeq: 101 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 1800
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 170
    v=0
    o=- 13013203547265625 13013203547265625 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32566 RTP/AVP 8
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendrecv
    2859892: *May 16 18:43:25.455: //575580/5209A51889E8/CCAPI/cc_api_caps_ind:
       Destination Interface=0x0, Destination Call Id=-1, Source Call Id=575580,
       Caps(Codec=0x2, Fax Rate=0x2, Fax Version:=0, Vad=0x2,
       Modem=0x0, Codec Bytes=20, Signal Type=2)
    2859893: *May 16 18:43:25.455: //575580/5209A51889E8/CCAPI/cc_api_caps_ind:
       Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
       Playout Max=1000(ms), Fax Nom=300(ms))
    2859894: *May 16 18:43:25.455: //575579/5209A51889E8/CCAPI/cc_api_caps_ack:
       Destination Interface=0x0, Destination Call Id=575580, Source Call Id=575579,
       Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=ON(0x2),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1)
    2859895: *May 16 18:43:25.455: //575579/5209A51889E8/CCAPI/cc_api_caps_ack:
       Destination Interface=0x0, Destination Call Id=575580, Source Call Id=575579,
       Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=ON(0x2),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1)
    2859896: *May 16 18:43:25.455: //575580/5209A51889E8/CCAPI/cc_api_event_indication:
       Event=178, Call Id=575580
    2859897: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/cc_api_event_indication:
       Event Is Sent To Conferenced SPI(s) Directly
    2859898: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/cc_api_call_connected:
       Interface=0x2D32C574, Data Bitmask=0x1, Progress Indication=NULL(0),
       Connection Handle=0
    2859899: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/cc_api_call_connected:
       Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
    2859900: *May 16 18:43:25.459: //575580/xxxxxxxxxxxx/CCAPI/cc_api_ha_call_active_notify:
      
    2859901: *May 16 18:43:25.459: call_info mainst_callID:0x8C85C, peer_callID:0x8C85B, confID:0x0, spi_type:4, media_flo_thru:1, media_passthru:1, num_streams:1, swmtpmsp_present:0
    2859902: *May 16 18:43:25.459: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    ACK sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDEF2517
    From: sip:234@10.5.55.250;tag=B4748F4C-2066
    To: <sip:233@10.5.55.250>;tag=c0360278
    Date: Thu, 16 May 2013 18:43:22 GMT
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    Max-Forwards: 70
    CSeq: 101 ACK
    Allow-Events: telephone-event
    Content-Length: 0

    2859903: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
       (confID=0xFFFFFFFF, callID1=0x8C85B, gcid=520A4140-BD8F11E2-89EBCBB5-8C3C255E, tag=0x0)
    2859904: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/ccConferenceCreate:
       (confID=0xFFFFFFFF, callID2=0x8C85C, gcid=520A4140-BD8F11E2-89EBCBB5-8C3C255E, tag=0x0)
    2859905: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
       Conference Id=0xFFFFFFFF, Call Id1=575579, Call Id2=575580, Tag=0x0
    2859906: *May 16 18:43:25.459: //575579/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859907: *May 16 18:43:25.459: cc_api_get_xcode_stream : 4819
    2859908: *May 16 18:43:25.459: //575580/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859909: *May 16 18:43:25.459: cc_api_get_xcode_stream : 4819
    2859910: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
      
    2859911: *May 16 18:43:25.459: ccConferenceCreate: ret1=0, codecMask1=2, bytes1=160, negot1=1, dtmf1=0
                        ret2=0, codecMask2=2, bytes2=160, negot2=1, dtmf2=0,
                        tx_dynamic_pt1=8, rx_dynamic_pt1=8, codec_mode1=0, params_bitmap1 =0
                        tx_dynamic_pt2=8, rx_dynamic_pt2=8, codec_mode2=0, params_bitmap2 =0
    2859912: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccGetMediaClassTag:
       media class tag 0
    2859913: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccSetMediaclassIp2ipTags:
       media class tags set: NR 0, ASP 0
    2859914: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/ccGetMediaClassTag:
       media class tag 0
    2859915: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/ccSetMediaclassIp2ipTags:
       media class tags set: NR 0, ASP 0
    2859916: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccGet_xc_nr_asp_info:
       media class tags: NR 0, ASP 0
    2859917: *May 16 18:43:25.459: //575580/5209A51889E8/CCAPI/ccGet_xc_nr_asp_info:
       media class tags: NR 0, ASP 0
    2859918: *May 16 18:43:25.459: //575579/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
       xcoder inserted for preferred features w/ mask 0x0
    2859919: *May 16 18:43:25.459: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
       delay media to slow start case, codec negotation is not done
    2859920: *May 16 18:43:25.459: //575579/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859921: *May 16 18:43:25.459: cc_api_get_xcode_stream : 4819
    2859922: *May 16 18:43:25.459: //575579/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859923: *May 16 18:43:25.459: cc_api_get_xcode_stream : 4819
    2859924: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/cc_api_bridge_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575579,
       Destination Call Id=575580, Disposition=0x0, Tag=0x0
    2859925: *May 16 18:43:25.463: //575580/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859926: *May 16 18:43:25.463: cc_api_get_xcode_stream : 4819
    2859927: *May 16 18:43:25.463: //575580/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859928: *May 16 18:43:25.463: cc_api_get_xcode_stream : 4819
    2859929: *May 16 18:43:25.463: //575580/5209A51889E8/CCAPI/cc_api_bridge_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575580,
       Destination Call Id=575579, Disposition=0x0, Tag=0x0
    2859930: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/cc_generic_bridge_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575580,
       Destination Call Id=575579, Disposition=0x0, Tag=0x0
    2859931: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
       Call Entry(Conference Id=0x5EE, Destination Call Id=575580)
    2859932: *May 16 18:43:25.463: //575580/5209A51889E8/CCAPI/ccConferenceCreate:
       Call Entry(Conference Id=0x5EE, Destination Call Id=575579)
    2859933: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccConferenceCreate:
      
    2859934: *May 16 18:43:25.463: confID:0x5EE; callEntry1 callID1:0x8C85B, type:3; callEntry2 callID2:0x8C85C, type:3
    2859935: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/cc_process_notify_bridge_done:
       Conference Id=0x5EE, Call Id1=575579, Call Id2=575580
    2859936: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccCallConnect:
       Progress Indication=NULL(0), Data Bitmask=0x1
    2859937: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccCallConnect:
       Call Entry(Connected=TRUE, Responsed=TRUE)
    2859938: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccSaveDialpeerTag:
       Outgoing Dial-peer=40003
    2859939: *May 16 18:43:25.463: //575580/5209A51889E8/CCAPI/ccSaveDialpeerTag:
       Incoming Dial-peer=40002
    2859940: *May 16 18:43:25.463: //575580/5209A51889E8/CCAPI/ccSaveDialpeerTag:
       Incoming Dial-peer=0
    2859941: *May 16 18:43:25.463: //575580/5209A51889E8/CCAPI/ccCallApp:
       Call Id=575580
    2859942: *May 16 18:43:25.463: //575579/5209A51889E8/CCAPI/ccCallApp:
       Call Id=575579
    2859943: *May 16 18:43:25.467: //575579/5209A51889E8/CCAPI/ccCallAppReturn:
       Conference Id=0xFFFFFFFF, Call Id=575579
    2859944: *May 16 18:43:25.467: //575580/5209A51889E8/CCAPI/ccCallAppTransferReturn:
       Call Id=575580
    2859945: *May 16 18:43:25.467: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-3d211143eb101067-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    Date: Thu, 16 May 2013 18:43:22 GMT
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 1 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: <sip:233@10.5.55.250>;party=called;screen=no;privacy=off
    Contact: <sip:233@10.5.55.250:5061;transport=tls>
    Supported: replaces
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Session-Expires:  1800;refresher=uac
    Require: timer
    Supported: timer
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 187
    v=0
    o=CiscoSystemsSIP-GW-UserAgent 3866 137 IN IP4 10.5.55.250
    s=SIP Call
    c=IN IP4 10.5.55.250
    t=0 0
    m=audio 19160 RTP/AVP 8
    c=IN IP4 10.5.55.250
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    2859946: *May 16 18:43:25.467: //575579/5209A51889E8/CCAPI/ccCallSetContext:
       Context=0x33165A88
    2859947: *May 16 18:43:25.467: //575580/5209A51889E8/CCAPI/ccCallSetContext:
       Context=0x3316AC48
    2859948: *May 16 18:43:25.491: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    ACK sip:233@10.5.55.250:5061;transport=tls SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-9e36c55b6b9b077e-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 1 ACK
    User-Agent: MCC7500
    Content-Length: 0

    2859949: *May 16 18:43:25.491: //575579/xxxxxxxxxxxx/CCAPI/cc_api_ha_call_active_notify:
      
    2859950: *May 16 18:43:25.491: call_info mainst_callID:0x8C85B, peer_callID:0x8C85C, confID:0x5EE, spi_type:4, media_flo_thru:1, media_passthru:1, num_streams:1, swmtpmsp_present:0
    2859951: *May 16 18:43:25.491: //575579/5209A51889E8/CCAPI/cc_api_event_indication:
       Event=200, Call Id=575579
    2859952: *May 16 18:43:25.491: //575579/5209A51889E8/CCAPI/cc_api_event_indication:
       Event Is Sent To Conferenced SPI(s) Directly
    2859961: *May 16 18:43:30.503: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:233@10.5.55.250:5061;transport=tls SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-8e042c5b8dcce701-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 2 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 90
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 194
    v=0
    o=- 13013203552296875 13013203552296875 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32565 RTP/AVP 0 8
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendonly
    2859962: *May 16 18:43:30.503: //575580/5209A51889E8/CCAPI/ccGenerateToneInfo:
       Stop Tone On Digit=FALSE, Tone=Null,
       Tone Direction=Sum Network, Params=0x0, Call Id=575580
    2859963: *May 16 18:43:30.503: //575580/5209A51889E8/CCAPI/cc_api_remote_codec_dnld_done:
       Destination Interface=0x2D32C574, Destination Call Id=575580, Source Call Id=575579, Xmit Function=0x25FE5608
    2859964: *May 16 18:43:30.503: //575580/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
      
    2859965: *May 16 18:43:30.503: cc_api_get_xcode_stream : 4819
    2859966: *May 16 18:43:30.503: //575579/5209A51889E8/CCAPI/cc_api_caps_ind:
       Destination Interface=0x2D32C574, Destination Call Id=575580, Source Call Id=575579,
       Caps(Codec=0x2, Fax Rate=0x2, Fax Version:=0, Vad=0x2,
       Modem=0x0, Codec Bytes=20, Signal Type=2)
    2859967: *May 16 18:43:30.503: //575579/5209A51889E8/CCAPI/cc_api_caps_ind:
       Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
       Playout Max=1000(ms), Fax Nom=300(ms))
    2859968: *May 16 18:43:30.503: //575580/5209A51889E8/CCAPI/cc_api_caps_ack:
       Destination Interface=0x2D32C574, Destination Call Id=575579, Source Call Id=575580,
       Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=ON(0x2),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6977)
    2859969: *May 16 18:43:30.503: //575580/5209A51889E8/CCAPI/cc_api_caps_ack:
       Destination Interface=0x2D32C574, Destination Call Id=575579, Source Call Id=575580,
       Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=ON(0x2),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6977)
    2859970: *May 16 18:43:30.503: //575579/5209A51889E8/CCAPI/cc_api_event_indication:
       Event=177, Call Id=575579
    2859971: *May 16 18:43:30.503: //575579/5209A51889E8/CCAPI/cc_api_event_indication:
       Event Is Sent To Conferenced SPI(s) Directly
    2859972: *May 16 18:43:30.503: //575579/5209A51889E8/CCAPI/cc_api_call_feature:
       Feature Type=50, Interface=0x2D32C574, Call Id=575579
    2859973: *May 16 18:43:30.507: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    INVITE sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDF01C93
    From: sip:234@10.5.55.250;tag=B4748F4C-2066
    To: <sip:233@10.5.55.250>;tag=c0360278
    Date: Thu, 16 May 2013 18:43:30 GMT
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    Supported: timer,resource-priority,replaces
    Min-SE:  1800
    Cisco-Guid: 1376363800-3180270050-2313735093-2352751966
    User-Agent: Cisco-SIPGateway/IOS-15.2.3.T2
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    CSeq: 102 INVITE
    Max-Forwards: 70
    Timestamp: 1368729810
    Contact: <sip:234@10.5.55.250:5060>
    Expires: 180
    Allow-Events: telephone-event
    Session-Expires:  1800;refresher=uac
    Content-Type: application/sdp
    Content-Length: 224
    v=0
    o=CiscoSystemsSIP-GW-UserAgent 7964 2823 IN IP4 10.5.55.250
    s=SIP Call
    c=IN IP4 10.5.55.250
    t=0 0
    m=audio 19162 RTP/AVP 8 19
    c=IN IP4 10.5.55.250
    a=sendonly
    a=rtpmap:8 PCMA/8000
    a=rtpmap:19 CN/8000
    a=ptime:20
    2859974: *May 16 18:43:30.507: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-8e042c5b8dcce701-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    Date: Thu, 16 May 2013 18:43:30 GMT
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 2 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    Content-Length: 0

    2859975: *May 16 18:43:30.511: //575579/5209A51889E8/CCAPI/ccConferenceDestroy:
       Conference Id=0x5EE, Tag=0x0
    2859976: *May 16 18:43:30.511: //575579/5209A51889E8/CCAPI/ccConferenceDestroy:
      
    2859977: *May 16 18:43:30.511: confID:0x5EE; callEntry1 callID1:0x8C85B, type:3; callEntry2 callID2:0x8C85C, type:3
    2859978: *May 16 18:43:30.511: //575579/5209A51889E8/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575579,
       Destination Call Id=575580, Disposition=0x0, Tag=0x0
    2859979: *May 16 18:43:30.511: //575580/5209A51889E8/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575580,
       Destination Call Id=575579, Disposition=0x0, Tag=0x0
    2859980: *May 16 18:43:30.511: //575579/5209A51889E8/CCAPI/cc_generic_bridge_done:
       Conference Id=0x5EE, Source Interface=0x2D32C574, Source Call Id=575580,
       Destination Call Id=575579, Disposition=0x0, Tag=0x0
    2859981: *May 16 18:43:30.515: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDF01C93
    Require: timer
    Contact: <sip:233@10.5.55.202:62321>
    To: <sip:233@10.5.55.250>;tag=c0360278
    From: <sip:234@10.5.55.250>;tag=B4748F4C-2066
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    CSeq: 102 INVITE
    Session-Expires: 1800;refresher=uac
    Min-SE: 1800
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces, timer, norefersub, answermode, tdialog, outbound, path
    User-Agent: MCC7500
    Content-Length: 170
    v=0
    o=- 13013203552328125 13013203552328125 IN IP4 10.5.55.202
    s=-
    c=IN IP4 10.5.55.202
    t=0 0
    m=audio 32566 RTP/AVP 8
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=recvonly
    2859982: *May 16 18:43:30.515: //575580/5209A51889E8/CCAPI/cc_api_caps_ind:
       Destination Interface=0x2D32C574, Destination Call Id=-1, Source Call Id=575580,
       Caps(Codec=0x2, Fax Rate=0x2, Fax Version:=0, Vad=0x2,
       Modem=0x0, Codec Bytes=20, Signal Type=2)
    2859983: *May 16 18:43:30.515: //575580/5209A51889E8/CCAPI/cc_api_caps_ind:
       Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
       Playout Max=1000(ms), Fax Nom=300(ms))
    2859984: *May 16 18:43:30.515: //575580/5209A51889E8/CCAPI/cc_api_event_indication:
       Event=178, Call Id=575580
    2859985: *May 16 18:43:30.515: //575580/5209A51889E8/CCAPI/cc_api_event_indication:
       Event Is Sent To Conferenced SPI(s) Directly
    2859986: *May 16 18:43:30.515: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    ACK sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDF11B98
    From: sip:234@10.5.55.250;tag=B4748F4C-2066
    To: <sip:233@10.5.55.250>;tag=c0360278
    Date: Thu, 16 May 2013 18:43:30 GMT
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    Max-Forwards: 70
    CSeq: 102 ACK
    Allow-Events: telephone-event
    Content-Length: 0

    2860007: *May 16 18:44:10.503: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    BYE sip:233@10.5.55.250:5061;transport=tls SIP/2.0
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-7a288b7064565a22-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:234@10.5.55.202:62321;transport=tls>
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    CSeq: 3 BYE
    User-Agent: MCC7500
    Reason: SIP;description="Stale re-Invite"
    Content-Length: 0

    2860008: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/cc_api_call_disconnected:
       Cause Value=16, Interface=0x2D32C574, Call Id=575579
    2860009: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/cc_api_call_disconnected:
       Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
    2860010: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
    2860011: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    2860012: *May 16 18:44:10.507: //575580/5209A51889E8/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
    2860013: *May 16 18:44:10.507: //575580/5209A51889E8/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    2860014: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x2D32C574, Tag=0x0, Call Id=575579,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    2860015: *May 16 18:44:10.507: //575579/5209A51889E8/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    2860016: *May 16 18:44:10.507: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
      
    2860017: *May 16 18:44:10.507: :cc_free_feature_vsa freeing 331455E0
    2860018: *May 16 18:44:10.507: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
      
    2860019: *May 16 18:44:10.507:  vsacount in free is 1
    2860020: *May 16 18:44:10.511: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Sent:
    BYE sip:233@10.5.55.202:62321 SIP/2.0
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDF22575
    From: sip:234@10.5.55.250;tag=B4748F4C-2066
    To: <sip:233@10.5.55.250>;tag=c0360278
    Date: Thu, 16 May 2013 18:43:30 GMT
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    User-Agent: Cisco-SIPGateway/IOS-15.2.3.T2
    Max-Forwards: 70
    Timestamp: 1368729850
    CSeq: 103 BYE
    Reason: Q.850;cause=16
    P-RTP-Stat: PS=0,OS=0,PR=0,OR=0,PL=0,JI=0,LA=0,DU=45
    Content-Length: 0

    2860021: *May 16 18:44:10.511: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Via: SIP/2.0/TLS 10.5.55.202:62321;branch=z9hG4bK-d8754z-7a288b7064565a22-1---d8754z-;rport
    From: "234"<sip:234@10.5.55.250:5061>;tag=fda2da1e
    To: <sip:233@10.5.55.250>;tag=B4748F54-1601
    Date: Thu, 16 May 2013 18:44:10 GMT
    Call-ID: MjU0ZTBjYWZjZWZiYjY2YjhjOWQ0NjgyNzNhMDMyMGU.
    Server: Cisco-SIPGateway/IOS-15.2.3.T2
    CSeq: 3 BYE
    Reason: Q.850;cause=16
    P-RTP-Stat: PS=0,OS=0,PR=0,OR=0,PL=0,JI=0,LA=0,DU=45
    Content-Length: 0

    2860022: *May 16 18:44:10.515: //575580/5209A51889E8/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 10.5.55.250:5060;branch=z9hG4bKDF22575
    Contact: <sip:233@10.5.55.202:62321>
    To: <sip:233@10.5.55.250>;tag=c0360278
    From: <sip:234@10.5.55.250>;tag=B4748F4C-2066
    Call-ID: 520D4EA1-BD8F11E2-89EECBB5-8C3C255E@10.5.55.250
    CSeq: 103 BYE
    User-Agent: MCC7500
    Content-Length: 0

    2860023: *May 16 18:44:10.515: //575580/5209A51889E8/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x2D32C574, Tag=0x0, Call Id=575580,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    2860024: *May 16 18:44:10.515: //575580/5209A51889E8/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    2860025: *May 16 18:44:10.515: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
      
    2860026: *May 16 18:44:10.515: :cc_free_feature_vsa freeing 33145880
    2860027: *May 16 18:44:10.515: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
      
    2860028: *May 16 18:44:10.515:  vsacount in free is 0
    2860029: *May 16 18:44:10.515: //-1/xxxxxxxxxxxx/CCAPI/ccMemPoolTDFreeHelper:
       data = 3324CF74
    2860030: *May 16 18:44:10.515: ccMemPoolTDFreeHelper:mem_mgr_mempool_free: mem_refcnt(34D1F32C)=0 - mempool cleanup

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 16-05-2013 02:13:52 PM
    FYI,
    I was using tcl script.
     
     
     
     

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 16-05-2013 03:08:36 PM
    Yes, it will also work if I ignore the ev_feature event in my TCL script.

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Keith Haugen on 16-05-2013 03:22:59 PM
    If I do not run the "connection destroy" command when I handle the ev_feature I receive for hold, I don't have the issue.  Leaving the connection up causes me issues in other areas right now, though, so this is just an FYI.

    Subject: RE: How do I respond 200 OK to a hold request in TCL IVR?
    Replied by: Yaw-Ming Chen on 16-05-2013 04:01:48 PM
    You do connection destroy whne you get ev_transfer_request to get XTO information.