[cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

Maciej Bylica mbgatherer at gmail.com
Tue Oct 16 06:02:08 EDT 2018 

We will try to convince the customer to adjust the settings on his side
(unique Call-ID for every OPTIONs would do the job).
As a workaround we do have C3845 with 12.x IOS :)

Many thanks for your help
Maciej.


czw., 11 paź 2018 o 23:52 Anthony Holloway <avholloway+cisco-voip at gmail.com>
napisał(a):

> Fair enough.  We're not always paid to perform the second O in PPDIOO.
> Your answer is better than "I don't know"  ;)  Again, thanks for sharing
> your experiences.
>
> On Thu, Oct 11, 2018 at 3:57 PM Kent Roberts <kent at fredf.org> wrote:
>
>> Oh sorry, I didn’t catch that on the receiving part.    Well, I probably
>> should re-look at some of the commands, but we were one of the first
>> adopters of SIP and not all the defaults that exist today, existed back
>> then.   Some of it got left in cause it works with the carrier.    :)
>> Some of it was also trial and error with the carrier, and well when it
>> starts working sometimes things don’t get revisited….   Hows that for an
>> answer!!!
>>
>>
>>
>> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>> Kent,
>>
>> I'm not sure why you sent that.  The problem is not with sending OPTION
>> Ping, it's with responding to received OPTION Ping.
>>
>> *"The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only to the
>> first OPTIONS packet that is received from the endpoint.  The rest of
>> OPTIONs are dropped with following debug output"*
>>
>> But since you brought it up... The default for that command is:
>>
>> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5
>>
>> What is your reason for changing it from the default?  The rule of thumb
>> is "use the defaults, unless you have a reason not to"
>>
>> I see the obvious answer here: it pings less often; however, it's the
>> *why* which I am interested in.
>>
>> Thanks for sharing what you do.
>>
>> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts <kent at fredf.org> wrote:
>>
>>> Here is what I use:
>>>
>>> voice-class sip options-keepalive up-interval 180 down-interval 60 retry
>>> 2
>>>
>>> Sh dial-peer voice sum    the Keepalive line will show busyout or active.
>>>
>>>
>>>
>>>
>>> On Oct 11, 2018, at 12:36 PM, Nick Barnett <nicksbarnett at gmail.com>
>>> wrote:
>>>
>>> I don’t know what the problem is either. Maybe if you grab ccapi inout
>>> debugs at the same time, your voice service voip section (at least, whole
>>> config would be better), sh ver, and show run | sec voice. Maybe even do a
>>> debug ccsip all if you have the ability to do that and NOT crash your CUBE.
>>> Obviously don’t debug ccsip all without thinking about what that will do.
>>>
>>>
>>> Even with all of that, I’m not sure I’ll have an answer, but I’ll look.
>>> I’ve had similar issues with my CUBEs and it was due to binding issues and
>>> another time it was a straight up bug and I had to bounce the box (which
>>> “fixed” it).  I don’t know why your initial debug was showing “could
>>> not add ccb to table” and I’m not even sure which CCB it’s talking about.
>>> My thoughts were that is customer callback… but I’m probably wrong on that
>>> one.
>>>
>>>
>>> Nick
>>>
>>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <
>>> avholloway+cisco-voip at gmail.com> wrote:
>>>
>>>> I feel obligated to reply, since I chimed in earlier....unfortunately,
>>>> I don't have any ideas for you.  In fact, I have seen CUBE just ignore
>>>> incoming SIP messages before, both OPTIONS and INVITEs alike.  Not many
>>>> occasions, just a few.  I have never gotten resolution on it, it has either
>>>> fixed itself, or in one special case, still happens.  It's my own, in
>>>> fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
>>>> is on my to-do list, but...  The cobbler's children are always the
>>>> worst-shod
>>>> <https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv>.
>>>> The Calls Per Second on my CUBE is like 1.7, however, there are no other
>>>> calls being setup, torn down, sup service, etc, and CUBE still just ignores
>>>> its responsibility.
>>>>
>>>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <mbgatherer at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> Do you have an idea how to get around this problem?
>>>>> Have you ever encountered such limitations in the process of
>>>>> processing OPTIONS packages?
>>>>>
>>>>> Thanks
>>>>> Maciej.
>>>>>
>>>>> śr., 10 paź 2018 o 09:13 Maciej Bylica <mbgatherer at gmail.com>
>>>>> napisał(a):
>>>>>
>>>>>> Hello
>>>>>>
>>>>>> Anthony, thanks for the hint, but you were right this is not the core
>>>>>> of the issue.
>>>>>>
>>>>>> I made some test via sipp with following results
>>>>>> 1)
>>>>>> Test: Send 15xOPTIONS with the same Call-ID and From-tag
>>>>>> Result: All OPTIONS were replied
>>>>>>
>>>>>> 2)
>>>>>> Test: shortly after completing the above test I made another test:
>>>>>> Send 15xOPTIONS with the same Call-ID as previously but different From-tag.
>>>>>> Result: None of the OPTIONS we’re replied.
>>>>>>
>>>>>> 3)
>>>>>> Test: Test 2 was re-run after a while
>>>>>> Result: All OPTIONS were replied
>>>>>>
>>>>>> So it seems Cisco records the Call-ID and From-tag somewhere in
>>>>>> memory and drops subsequent OPTIONS with the same Call-ID and different
>>>>>> From-tag that come from the same endpoint for some time.
>>>>>>
>>>>>> I have similar situation here.
>>>>>> The customer we are trying to connect sends several OPTIONS within
>>>>>> miliseconds.
>>>>>> First OPTIONS is replied properly, but subsequent packets with the
>>>>>> same Call-ID and different From-tag dropped.
>>>>>>
>>>>>> Is there any solution for this.
>>>>>> Our customer is very reluctant to proceed with any changes (another
>>>>>> open source SIP proxies replies all the OPTIONS).
>>>>>>
>>>>>> Thanks
>>>>>> Maciej.
>>>>>>
>>>>>> wt., 9 paź 2018 o 23:45 Anthony Holloway <
>>>>>> avholloway+cisco-voip at gmail.com> napisał(a):
>>>>>>
>>>>>>> I hope you saw that I wrote "Pseudo Config" and don't just try to
>>>>>>> copy and paste that.  I'm also not very convinced that this is the core of
>>>>>>> your issue, but you're more than welcome to give it a try.
>>>>>>>
>>>>>>> You said the first OPTIONS does respond, so I'm guessing it's not
>>>>>>> going to be a binding error.  In fact, if it was a binding error, OPTIONS
>>>>>>> would still respond, it would just have wrong IP info in the headers.
>>>>>>>
>>>>>>> Anyway, good luck with that test.
>>>>>>>
>>>>>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <mbgatherer at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks, i am about to modify the config to check.
>>>>>>>>
>>>>>>>> Many thanks
>>>>>>>>
>>>>>>>>
>>>>>>>> wt., 9 paź 2018 o 20:58 Anthony Holloway <
>>>>>>>> avholloway+cisco-voip at gmail.com> napisał(a):
>>>>>>>>
>>>>>>>>> OPTIONS does not have to match a dial peer to work.  However, if
>>>>>>>>> you are going to match a dial peer at all, it would likely be for the
>>>>>>>>> express purpose of replying from the correct interface, if you have more
>>>>>>>>> than one potential interfaces, and you for some reason cannot bind
>>>>>>>>> globally.  Thus using the correct bind statement on a dial-peer for OPTIONS
>>>>>>>>> reply, would be necessary.  In which case, you would need to match an
>>>>>>>>> incoming call leg dial peer by the SIP Via header alone, and not, say for
>>>>>>>>> example, incoming called number.
>>>>>>>>>
>>>>>>>>> Example Pseudo Configuration:
>>>>>>>>>
>>>>>>>>> voice class sip uri 100
>>>>>>>>>  host ipv4:10.1.1.1
>>>>>>>>> !
>>>>>>>>> dial-peer voice 100 voip
>>>>>>>>>  incoming uri via 100
>>>>>>>>>  bind media interface g0/1
>>>>>>>>>  bind control interface g0/1
>>>>>>>>> !
>>>>>>>>>
>>>>>>>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <mbgatherer at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for prompt answer.
>>>>>>>>>>
>>>>>>>>>> No, i am not using CCP.
>>>>>>>>>> As i see OPTIONS ping does not match with any dialpeer
>>>>>>>>>>
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric
>>>>>>>>>> calling number: *stringhere*
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA
>>>>>>>>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match
>>>>>>>>>> incoming dialpeer for Calling number: : *stringhere*
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:
>>>>>>>>>>  input arg error
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match
>>>>>>>>>> found for P-Called-Party-ID
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:
>>>>>>>>>>  input argument error
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition
>>>>>>>>>> tag absent in Require/Supported header
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media
>>>>>>>>>> Antitrombone disabled
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the
>>>>>>>>>> configured mode as FLOW-THROUGH
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder
>>>>>>>>>> high-density disabled
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode
>>>>>>>>>> set to FLOW_THROUGH
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer
>>>>>>>>>> leg - using RTP Supported Codecs
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 18
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 0
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 8
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 9
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 4
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 2
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 15
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>>>>>>>>> Codecs supported by GW 255
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:
>>>>>>>>>> MF: Not a Forked SIP leg..
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp
>>>>>>>>>> configure for this leg.
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:
>>>>>>>>>> peer_callID=0
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:
>>>>>>>>>>
>>>>>>>>>>  MF: *Dial-peer is absent*..
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state
>>>>>>>>>> = 0 & New state = -1
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:
>>>>>>>>>> MF: Anchor leg config reset done...
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:
>>>>>>>>>>
>>>>>>>>>>  MF:video profile Dial-peer is absent..
>>>>>>>>>>
>>>>>>>>>> OPTIONS looks like following:
>>>>>>>>>> OPTIONS sip:domain.name.here:5060 SIP/2.0
>>>>>>>>>> From: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a
>>>>>>>>>> To: <sip:*stringhere*@domain.name.here>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I do not have any script in use there, the configuration in
>>>>>>>>>> pretty basic.
>>>>>>>>>> What i have found is that second OPTIONS (the one that is
>>>>>>>>>> left/dropped without OK) also generates following output:
>>>>>>>>>> Oct  9 17:50:38.070:
>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:
>>>>>>>>>> Checking Invite Dialog
>>>>>>>>>> Oct  9 17:50:38.070:
>>>>>>>>>> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:
>>>>>>>>>> *****CCB found in UAS Request table. ccb=0x2766B958
>>>>>>>>>> Oct  9 17:50:38.070:
>>>>>>>>>> //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying
>>>>>>>>>> with child CCB 0x0 index 0 curr_child 0
>>>>>>>>>>
>>>>>>>>>> Oct  9 17:50:38.070:
>>>>>>>>>> //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:
>>>>>>>>>>
>>>>>>>>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL
>>>>>>>>>> old_from: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a
>>>>>>>>>> old_to: <sip:*stringhere*@domain.name.here>;tag=D7E844-1438
>>>>>>>>>> new_from: <sip:*stringhere*@domain.name.here>;tag=6c7f09452671
>>>>>>>>>> new_to: <sip:*stringhere*@domain.name.here>
>>>>>>>>>> ....
>>>>>>>>>> Oct  9 17:50:04.068:
>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:
>>>>>>>>>>
>>>>>>>>>>  Freeing NULL pointer!
>>>>>>>>>>
>>>>>>>>>> Could you please point me where i can find some information how
>>>>>>>>>> to create such dial-peer for OPTIONS or give me a brief example of this
>>>>>>>>>> configuration please.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Maciej.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> wt., 9 paź 2018 o 16:39 Nick Barnett <nicksbarnett at gmail.com>
>>>>>>>>>> napisał(a):
>>>>>>>>>>
>>>>>>>>>>> Are you using Customer Call Back? Which dial peer is the options
>>>>>>>>>>> ping hitting? Does that dial peer have the CCB script on it? If so... maybe
>>>>>>>>>>> make another dial peer for options pings that does not have the script
>>>>>>>>>>> enabled. This is just a hunch...
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <
>>>>>>>>>>> mbgatherer at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> I have really strange problem with SIP OPTIONS pings.
>>>>>>>>>>>> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds
>>>>>>>>>>>> only to the first OPTIONS packet that is received from the endpoint.
>>>>>>>>>>>> The rest of OPTIONs are dropped with following debug output:
>>>>>>>>>>>>
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694907: Oct  9 10:55:58.194:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
>>>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694908: Oct  9 10:55:58.194:
>>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:
>>>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694909: Oct  9 10:55:58.194:
>>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State
>>>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
>>>>>>>>>>>> SUBSTATE_NONE)
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694910: Oct  9 10:55:58.194:
>>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694911:  *Could not add ccb to
>>>>>>>>>>>> table*. ccb=0x258D7210
>>>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694912: Oct  9 10:55:58.194:
>>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:
>>>>>>>>>>>> Oct  9 12:52:06 10.10.10.10 8694913:  *Resource failure,
>>>>>>>>>>>> dropping OPTIONS*
>>>>>>>>>>>>
>>>>>>>>>>>> The true is that Cisco receives quite significant amount of SIP
>>>>>>>>>>>> OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within
>>>>>>>>>>>> miliseconds.
>>>>>>>>>>>> The after-effect i want to achieve is a response for each
>>>>>>>>>>>> incoming OPTIONS
>>>>>>>>>>>>
>>>>>>>>>>>> Example of a successful response:
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625106: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
>>>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625107: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:
>>>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625108: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State
>>>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
>>>>>>>>>>>> SUBSTATE_NONE)
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625109: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to
>>>>>>>>>>>> table. ccb=0x258B1110
>>>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance
>>>>>>>>>>>> 1
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625110: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:
>>>>>>>>>>>> Adding call id 23DA9 to table
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625111: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event:
>>>>>>>>>>>> ccsip_spi_get_msg_type returned: 3 for event 38
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625112: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created
>>>>>>>>>>>> msg=0x203FFDA4 with refCount = 1
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625113: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:
>>>>>>>>>>>> Associated container=0x2673A528 to Options Response
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625114: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:
>>>>>>>>>>>> sipSPIAppHandleContainerBody len 164
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625115: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:
>>>>>>>>>>>> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,
>>>>>>>>>>>> is_req=0, transport=1, switch=0, callBack=0x4F48054
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625116: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP
>>>>>>>>>>>> extension config:1, check sys cfg:1
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625117: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable
>>>>>>>>>>>> for sending msg immediately
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625118: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to
>>>>>>>>>>>> send resp=0x203FFDA4 to default port=5060
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625119: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:
>>>>>>>>>>>> connection required for raddr:11.11.11.11, rport:5060 with laddr:
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625120: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceGetConnectionId: Registering
>>>>>>>>>>>> gcb=0x258B1110 with connection=0x2426673C context list
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625121: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection
>>>>>>>>>>>> obtained...sending msg=0x203FFDA4
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625122: Oct  9 09:34:28.569:
>>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send
>>>>>>>>>>>> for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for
>>>>>>>>>>>> UDP
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625123: Oct  9 09:34:28.569:
>>>>>>>>>>>> //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625124: Sent:
>>>>>>>>>>>> Oct  9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015
>>>>>>>>>>>>
>>>>>>>>>>>> Could someone help me with this? I really appreciate your
>>>>>>>>>>>> advice.
>>>>>>>>>>>>
>>>>>>>>>>>> Maciej
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>> 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/20181016/32640840/attachment.html>

More information about the cisco-voip mailing list