[cisco-voip] cisco-voip Digest, Vol 180, Issue 11
Vladimir Simic
vladimir.simic78 at yahoo.com
Sat Dec 29 11:13:45 EST 2018
On Friday, October 12, 2018, 6:02:26 PM GMT+2, <cisco-voip-request at puck.nether.net> wrote:
Send cisco-voip mailing list submissions to
cisco-voip at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
cisco-voip-request at puck.nether.net
You can reach the person managing the list at
cisco-voip-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Anthony Holloway)
2. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Nick Barnett)
3. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Kent Roberts)
4. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Anthony Holloway)
5. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Kent Roberts)
6. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Kent Roberts)
7. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -
Resource failure, dropping OPTIONS (Anthony Holloway)
8. Any Alertus integrations out there? Successful or otherwise?
(Lelio Fulgenzi)
9. Re: anonymous proximity issues? (Ryan Ratliff (rratliff))
10. Re: [EXTERNAL] Re: 8832 Design Issue? (Ryan Ratliff (rratliff))
11. Re: anonymous proximity issues? (Lelio Fulgenzi)
12. Re: [EXTERNAL] Re: 8832 Design Issue? (Lelio Fulgenzi)
13. Unity Call Handler recording upload (James Dust)
14. Re: Unity Call Handler recording upload (Gary Parker)
15. Re: anonymous proximity issues? (Ryan Ratliff (rratliff))
16. Re: Unity Call Handler recording upload (Anthony Holloway)
17. Re: Unity Call Handler recording upload (Gary Parker)
18. Re: Unity Call Handler recording upload (Anthony Holloway)
19. Re: Unity Call Handler recording upload (James Dust)
20. Re: Unity Call Handler recording upload (Bill Talley)
21. Re: Unity Call Handler recording upload (Myron Young)
22. Re: Unity Call Handler recording upload (James Dust)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Oct 2018 11:11:38 -0500
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
To: Maciej Bylica <mbgatherer at gmail.com>
Cc: Nick Barnett <nicksbarnett at gmail.com>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID:
<CACRCJOiND+8MGY-nuYisQCVU4Ltv1sSMubOP2o8A_4wKryZZRQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/8957f314/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 11 Oct 2018 13:36:58 -0500
From: Nick Barnett <nicksbarnett at gmail.com>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: mbgatherer at gmail.com, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID:
<CAPtKLNC+edyhxWfd5VaLPFWAPWufyX=65VUC5LXuM4k7h3jrjw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/9b310fc1/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 Oct 2018 14:32:20 -0600
From: Kent Roberts <kent at fredf.org>
To: Nick Barnett <nicksbarnett at gmail.com>
Cc: Anthony Holloway <avholloway+cisco-voip at gmail.com>,
"cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID: <AD10D715-86F7-48E9-B5B1-BB86E5714F4E at fredf.org>
Content-Type: text/plain; charset="utf-8"
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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <http://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 at domain.name.here>;tag=4a6000292f6a
> To: <sip:stringhere at 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 at domain.name.here>;tag=4a6000292f6a
> old_to: <sip:stringhere at domain.name.here>;tag=D7E844-1438
> new_from: <sip:stringhere at domain.name.here>;tag=6c7f09452671
> new_to: <sip:stringhere at 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 <mailto: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 <mailto: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 <mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip <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 <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/20181011/2daad8af/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 Oct 2018 15:42:19 -0500
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
To: Kent Roberts <kent at fredf.org>
Cc: Nick Barnett <nicksbarnett at gmail.com>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID:
<CACRCJOjZSesWcyxATgyTOYNXFpmzy0mXKRaq3OjysVeByRAQ0w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/1c3183cf/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 Oct 2018 14:57:21 -0600
From: Kent Roberts <kent at fredf.org>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: Nick Barnett <nicksbarnett at gmail.com>,
"cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID: <B0B6FDD5-F300-4809-B49F-0A728FF51258 at fredf.org>
Content-Type: text/plain; charset="utf-8"
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 <mailto: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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <http://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 at domain.name.here>;tag=4a6000292f6a
>> To: <sip:stringhere at 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 at domain.name.here>;tag=4a6000292f6a
>> old_to: <sip:stringhere at domain.name.here>;tag=D7E844-1438
>> new_from: <sip:stringhere at domain.name.here>;tag=6c7f09452671
>> new_to: <sip:stringhere at 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 <mailto: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 <mailto: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 <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip <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 <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 <https://puck.nether.net/mailman/listinfo/cisco-voip>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/26a22d8c/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 11 Oct 2018 14:59:30 -0600
From: Kent Roberts <kent at fredf.org>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: Nick Barnett <nicksbarnett at gmail.com>,
"cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID: <B54D9D13-9174-4719-9AED-52E4C4527538 at fredf.org>
Content-Type: text/plain; charset="utf-8"
Should also throw out that, one of the carriers, didn?t care about options as long as there was something hitting it.
> On Oct 11, 2018, at 2: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 <mailto: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 <mailto: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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <mailto:avholloway%2Bcisco-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 <mailto: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 <http://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 at domain.name.here>;tag=4a6000292f6a
>>> To: <sip:stringhere at 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 at domain.name.here>;tag=4a6000292f6a
>>> old_to: <sip:stringhere at domain.name.here>;tag=D7E844-1438
>>> new_from: <sip:stringhere at domain.name.here>;tag=6c7f09452671
>>> new_to: <sip:stringhere at 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 <mailto: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 <mailto: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 <mailto:cisco-voip at puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/cisco-voip <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 <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 <https://puck.nether.net/mailman/listinfo/cisco-voip>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/3e038dfa/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 11 Oct 2018 16:52:01 -0500
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
To: Kent Roberts <kent at fredf.org>
Cc: Nick Barnett <nicksbarnett at gmail.com>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE
3945E - Resource failure, dropping OPTIONS
Message-ID:
<CACRCJOhgg1wnjjt=WytuAKpTcGX9yD98aEOahAG7tJfRyYCCmg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/ada74916/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 12 Oct 2018 00:12:03 +0000
From: Lelio Fulgenzi <lelio at uoguelph.ca>
To: cisco-voip voyp list <cisco-voip at puck.nether.net>
Subject: [cisco-voip] Any Alertus integrations out there? Successful
or otherwise?
Message-ID: <D72F646B-BDC7-4426-AC3B-47E24E1CBF5B at uoguelph.ca>
Content-Type: text/plain; charset="utf-8"
Wondering if anyone out there has attempted or completed an Alertus integration.
Preliminary discussions showed they required updating the Description field of the DN in order to build custom groups if the groups we want couldn?t be built from existing configuration options like partitions. Seems like quite a bit of work and upkeep, with lots of room for error.
It also seemed like they weren?t using the ?superprovider? mechanism, because they suggested creating a user and adding each device to the controlled devices section. Again, same issues as above.
The above doesn?t seem bad for a small deployment, but with over four thousand phones, and a model of ?move your own phone?, I have a feeling groups would become out of sync quickly.
Feel free to respond off-line.
Lelio
-sent from mobile device-
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
[University of Guelph Cornerstone with Improve Life tagline]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/dfb66122/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 12 Oct 2018 01:50:33 +0000
From: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
To: Lelio Fulgenzi <lelio at uoguelph.ca>
Cc: cisco-voip list <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] anonymous proximity issues?
Message-ID: <2B433CEA-36CA-407E-975C-78B28DBAB0EF at cisco.com>
Content-Type: text/plain; charset="utf-8"
It?s not PIN controlled, the idea is that if the device is in range of the ultrasound and on a network that has https connectivity to the codec then it can connect.
Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.
If you want your users to have control over toggling the feature take an example from https://github.com/CiscoDevNet/roomdevices-macros-samples and create a macro that works with in-room-controls to give your users a button to flip the config on/off.
-Ryan
On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
Unless I am completely mistaken, it seems that proximity participation in a t/p session enabled for proximity is completely anonymous without acknowledgement from the t/p operator side of things. At least one document says that if you are afraid of people outside your office participating, you should disable proximity on your device. Wait, what?
I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.
I?m thinking of enabling only proximity itself and not sharing, so at least webex users can select the endpoint. I mean, they may call a user?s endpoint, but in the end, they have to accept the call. No biggie there.
But it really is a shame that there was no acknowledgement or PIN displayed, like on an Apple TV when you want to join the session.
Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?
Lelio
---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
<image001.png>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/9993b829/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 12 Oct 2018 01:55:59 +0000
From: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
To: JASON BURWELL <JASON.BURWELL at foundersfcu.com>
Cc: Nimloth <nimloth at nimloth.pl>, cisco-voip list
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?
Message-ID: <49E4DFCD-A978-4CEC-93E1-D54065BA023E at cisco.com>
Content-Type: text/plain; charset="utf-8"
I think this has been covered on this list before but that specific issue is NOT a problem that requires an RMA to resolve.
It?s an incompatibility of older loads with the PoE injector.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/firmware/12-1-1/cs88_b_conference-8832-rn-for-12_1_1.html#concept_E6B0DE96F47A653545A3BF51ED1C1E45
You just need to get it powered up and back on the network with the ethernet injector or force it to boot to the alternate load (after installing a newer load on CUCM).
-Ryan
On Oct 9, 2018, at 3:49 PM, JASON BURWELL <JASON.BURWELL at foundersfcu.com<mailto:JASON.BURWELL at foundersfcu.com>> wrote:
Yes, also we hit some bugs with an early FW release. Once it downgraded from the factory load, it would brick the phone. Must be a major issue because I had to wait almost 2 months for RMA fulfillment. Now that we are running current firmware with that bugfix, we seem to be past that issue but now seeing this problem.
From: Nimloth [mailto:nimloth at nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL <JASON.BURWELL at foundersfcu.com<mailto:JASON.BURWELL at foundersfcu.com>>
Cc: cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?
CAUTION: This email originated outside of Founders Federal Credit Union. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
To be honest I won't deploy 8832 in my org as we still struggling to get one up and running since few months. Few TAC/RMA already in progress.
W dniu 9 pa? 2018, o 20:35, u?ytkownik JASON BURWELL <jason.burwell at foundersfcu.com<mailto:jason.burwell at foundersfcu.com>> napisa?:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged from the phone when people grab it to slide or move the phone towards them? Starting to see some issues with this and I only have a few deployed so far. Hoping someone has figured out a workaround or clip to help retain the cord.
This was never a problem before because all the other Cisco Conf phones are not only held in by RJ45 clip but also cord clips made in to the base. The 8832 has neither, just USB-C cord that plugs in to the back. Thanks! Jason
________________________________
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dvoip&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=22gMLJdSN74XK3lOj2uEqIn5DpBhBOlPlAHXgwa9z0A&s=3fRgiLqNilQGn2SajWlJxQ8Yq8_jdFjihyfQhNbH-aQ&e=>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/de392cd0/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 12 Oct 2018 02:32:28 +0000
From: Lelio Fulgenzi <lelio at uoguelph.ca>
To: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
Cc: cisco-voip list <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] anonymous proximity issues?
Message-ID: <56B13A6D-E9D3-4E2D-A8C4-A57A9594CFAA at uoguelph.ca>
Content-Type: text/plain; charset="utf-8"
Hmmmm, I don?t remember seeing anything on the screen when I connected via proximity. Will have to check again. My head was likely looking down at my device.
The idea of macros is nice, but not sure it really helps secure the system while they actually want to use it.
It?s not ideal, but in EDUs, there?s very little segmentation when it comes to a student logging into wireless vs staff/faculty. Not to say all students are looking to cause trouble, but, well, you know.
And in today?s cubicle environment, those frequencies are reaching far outside the glass walls. But I?ll need to do more testing once the device is in place. Even a quick site survey might appease our concerns.
-sent from mobile device-
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
[University of Guelph Cornerstone with Improve Life tagline]
On Oct 11, 2018, at 9:50 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
It?s not PIN controlled, the idea is that if the device is in range of the ultrasound and on a network that has https connectivity to the codec then it can connect.
Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.
If you want your users to have control over toggling the feature take an example from https://github.com/CiscoDevNet/roomdevices-macros-samples and create a macro that works with in-room-controls to give your users a button to flip the config on/off.
-Ryan
On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
Unless I am completely mistaken, it seems that proximity participation in a t/p session enabled for proximity is completely anonymous without acknowledgement from the t/p operator side of things. At least one document says that if you are afraid of people outside your office participating, you should disable proximity on your device. Wait, what?
I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.
I?m thinking of enabling only proximity itself and not sharing, so at least webex users can select the endpoint. I mean, they may call a user?s endpoint, but in the end, they have to accept the call. No biggie there.
But it really is a shame that there was no acknowledgement or PIN displayed, like on an Apple TV when you want to join the session.
Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?
Lelio
---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
<image001.png>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b08bb11a/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 12 Oct 2018 02:35:46 +0000
From: Lelio Fulgenzi <lelio at uoguelph.ca>
To: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
Cc: JASON BURWELL <JASON.BURWELL at foundersfcu.com>, cisco-voip list
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?
Message-ID: <D3AADD86-B06B-4E89-9781-9F5BC9569206 at uoguelph.ca>
Content-Type: text/plain; charset="utf-8"
?Good save, wedding singer.? comes to mind.
Thanks for sharing this.
-sent from mobile device-
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
[University of Guelph Cornerstone with Improve Life tagline]
On Oct 11, 2018, at 9:56 PM, Ryan Ratliff (rratliff) via cisco-voip <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>> wrote:
I think this has been covered on this list before but that specific issue is NOT a problem that requires an RMA to resolve.
It?s an incompatibility of older loads with the PoE injector.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/firmware/12-1-1/cs88_b_conference-8832-rn-for-12_1_1.html#concept_E6B0DE96F47A653545A3BF51ED1C1E45
You just need to get it powered up and back on the network with the ethernet injector or force it to boot to the alternate load (after installing a newer load on CUCM).
-Ryan
On Oct 9, 2018, at 3:49 PM, JASON BURWELL <JASON.BURWELL at foundersfcu.com<mailto:JASON.BURWELL at foundersfcu.com>> wrote:
Yes, also we hit some bugs with an early FW release. Once it downgraded from the factory load, it would brick the phone. Must be a major issue because I had to wait almost 2 months for RMA fulfillment. Now that we are running current firmware with that bugfix, we seem to be past that issue but now seeing this problem.
From: Nimloth [mailto:nimloth at nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL <JASON.BURWELL at foundersfcu.com<mailto:JASON.BURWELL at foundersfcu.com>>
Cc: cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?
CAUTION: This email originated outside of Founders Federal Credit Union. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
To be honest I won't deploy 8832 in my org as we still struggling to get one up and running since few months. Few TAC/RMA already in progress.
W dniu 9 pa? 2018, o 20:35, u?ytkownik JASON BURWELL <jason.burwell at foundersfcu.com<mailto:jason.burwell at foundersfcu.com>> napisa?:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged from the phone when people grab it to slide or move the phone towards them? Starting to see some issues with this and I only have a few deployed so far. Hoping someone has figured out a workaround or clip to help retain the cord.
This was never a problem before because all the other Cisco Conf phones are not only held in by RJ45 clip but also cord clips made in to the base. The 8832 has neither, just USB-C cord that plugs in to the back. Thanks! Jason
________________________________
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dvoip&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=22gMLJdSN74XK3lOj2uEqIn5DpBhBOlPlAHXgwa9z0A&s=3fRgiLqNilQGn2SajWlJxQ8Yq8_jdFjihyfQhNbH-aQ&e=>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/bbc3a933/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 12 Oct 2018 09:56:19 +0000
From: James Dust <james.dust at charles-stanley.co.uk>
To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<B5861604FFBFF545BA7BDD7763E6C3FCBDCFD2EE at CSEXMBOX05.charles-stanley.co.uk>
Content-Type: text/plain; charset="us-ascii"
Morning all,
I have created a call handler on our unity server for a number range we no longer use.
Our staff have created an mp4 file, with the desired recording on it which I wish to upload to this call handler.
I've converted the file to both .mp3 and .wav, however when I upload the file I get an error message stating the format is oncorrect.
Could someone tell me what format the file should be in please?
My unity verison is: Cisco Unity Connection version: 11.5.1.15900-18
Consider the environment - Think before you print
The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.
You are advised that urgent, time-sensitive communications should not be sent by email. We hereby give you notice that a delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL http://www.charles-stanley.co.uk/contact-us/disclosure/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/2f953c61/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 12 Oct 2018 10:35:08 +0000
From: Gary Parker <G.J.Parker at lboro.ac.uk>
To: James Dust <james.dust at charles-stanley.co.uk>
Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID: <47D92FF7-3037-4E90-A9A0-AD50F08BAF6A at lboro.ac.uk>
Content-Type: text/plain; charset="utf-8"
> On 12 Oct 2018, at 10:56, James Dust <james.dust at charles-stanley.co.uk> wrote:
>
> I have created a call handler on our unity server for a number range we no longer use.
>
> Our staff have created an mp4 file, with the desired recording on it which I wish to upload to this call handler.
>
> I?ve converted the file to both .mp3 and .wav, however when I upload the file I get an error message stating the format is oncorrect.
>
> Could someone tell me what format the file should be in please?
Hi James, I found this article on using the free Audacity tool to convert very helpful:
http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html
Long story short, you need a mono, 8-bit, 8kHz, u-law WAV.
However, use Audiotext Manager and it does all the heavy lifting for you. Just drop any old wav file or MP3 and it converts it as it uploads. Definitely my recommended solution.
https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html
---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary at lboro.ac.uk o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/63c97db5/attachment-0001.sig>
------------------------------
Message: 15
Date: Fri, 12 Oct 2018 12:19:41 +0000
From: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
To: Lelio Fulgenzi <lelio at uoguelph.ca>
Cc: cisco-voip list <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] anonymous proximity issues?
Message-ID: <45EC9ABD-93FB-4644-A686-C889247E45F7 at cisco.com>
Content-Type: text/plain; charset="utf-8"
Being EDU I foresee an engineering student?s senior project to create a device to wash out the 20-22kHz ultrasound, making an invisible fence for proximity's ultrasound when used in open spaces.
Also, for all of your Proximity questions:
https://community.cisco.com/t5/mobile-applications-documents/troubleshooting-guide-cisco-proximity/ta-p/3148841#toc-hId--2135534734
-Ryan
On Oct 11, 2018, at 10:32 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
Hmmmm, I don?t remember seeing anything on the screen when I connected via proximity. Will have to check again. My head was likely looking down at my device.
The idea of macros is nice, but not sure it really helps secure the system while they actually want to use it.
It?s not ideal, but in EDUs, there?s very little segmentation when it comes to a student logging into wireless vs staff/faculty. Not to say all students are looking to cause trouble, but, well, you know.
And in today?s cubicle environment, those frequencies are reaching far outside the glass walls. But I?ll need to do more testing once the device is in place. Even a quick site survey might appease our concerns.
-sent from mobile device-
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
[University of Guelph Cornerstone with Improve Life tagline]
On Oct 11, 2018, at 9:50 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
It?s not PIN controlled, the idea is that if the device is in range of the ultrasound and on a network that has https connectivity to the codec then it can connect.
Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.
If you want your users to have control over toggling the feature take an example from https://github.com/CiscoDevNet/roomdevices-macros-samples and create a macro that works with in-room-controls to give your users a button to flip the config on/off.
-Ryan
On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
Unless I am completely mistaken, it seems that proximity participation in a t/p session enabled for proximity is completely anonymous without acknowledgement from the t/p operator side of things. At least one document says that if you are afraid of people outside your office participating, you should disable proximity on your device. Wait, what?
I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.
I?m thinking of enabling only proximity itself and not sharing, so at least webex users can select the endpoint. I mean, they may call a user?s endpoint, but in the end, they have to accept the call. No biggie there.
But it really is a shame that there was no acknowledgement or PIN displayed, like on an Apple TV when you want to join the session.
Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?
Lelio
---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook
<image001.png>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/fe76b853/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 12 Oct 2018 08:43:11 -0500
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
To: Gary Parker <G.J.Parker at lboro.ac.uk>
Cc: James Dust <james.dust at charles-stanley.co.uk>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<CACRCJOi5YGQ2T7+the0Bok5Cv6DyN-N9eC=fE-QDUMzb0NNtyw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
In addition to Audacity, which I use myself, try this site out:
http://g711.org/
On Fri, Oct 12, 2018 at 5:35 AM Gary Parker <G.J.Parker at lboro.ac.uk> wrote:
>
>
> > On 12 Oct 2018, at 10:56, James Dust <james.dust at charles-stanley.co.uk>
> wrote:
> >
> > I have created a call handler on our unity server for a number range we
> no longer use.
> >
> > Our staff have created an mp4 file, with the desired recording on it
> which I wish to upload to this call handler.
> >
> > I?ve converted the file to both .mp3 and .wav, however when I upload the
> file I get an error message stating the format is oncorrect.
> >
> > Could someone tell me what format the file should be in please?
>
> Hi James, I found this article on using the free Audacity tool to convert
> very helpful:
>
>
> http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html
>
> Long story short, you need a mono, 8-bit, 8kHz, u-law WAV.
>
> However, use Audiotext Manager and it does all the heavy lifting for you.
> Just drop any old wav file or MP3 and it converts it as it uploads.
> Definitely my recommended solution.
>
> https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html
>
> ---
> /-Gary Parker----------------------------------f--\
> | Unified Communications Service Manager |
> n Loughborough University, IT Services |
> | tel:+441509635635 sip:gary at lboro.ac.uk o
> | https://www.osx.ninja/pubkey.txt |
> \r----------------------------------------------d-/
>
> _______________________________________________
> 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/20181012/b09599c2/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 12 Oct 2018 13:50:46 +0000
From: Gary Parker <G.J.Parker at lboro.ac.uk>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: James Dust <james.dust at charles-stanley.co.uk>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID: <C8163CCA-9FA2-4C12-876A-88C14B3C9EBF at lboro.ac.uk>
Content-Type: text/plain; charset="utf-8"
> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>
> In addition to Audacity, which I use myself, try this site out: http://g711.org/
Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!
---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary at lboro.ac.uk o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/5ee6c368/attachment-0001.sig>
------------------------------
Message: 18
Date: Fri, 12 Oct 2018 08:53:23 -0500
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
To: Gary Parker <G.J.Parker at lboro.ac.uk>
Cc: James Dust <james.dust at charles-stanley.co.uk>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<CACRCJOiNrLQcGo=iHqDEHLqfgfUVN0DSY_=9DVvFFck2vngi9w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I agree. How awesome would it be if it did the conversion purely client
side?
On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <G.J.Parker at lboro.ac.uk> wrote:
>
>
> > On 12 Oct 2018, at 14:43, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
> >
> > In addition to Audacity, which I use myself, try this site out:
> http://g711.org/
>
> Neat idea, and well implemented, but obviously please be wary of sending
> your data to someone else?s site!
>
>
> ---
> /-Gary Parker----------------------------------f--\
> | Unified Communications Service Manager |
> n Loughborough University, IT Services |
> | tel:+441509635635 sip:gary at lboro.ac.uk o
> | https://www.osx.ninja/pubkey.txt |
> \r----------------------------------------------d-/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b293f61e/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 12 Oct 2018 14:06:10 +0000
From: James Dust <james.dust at charles-stanley.co.uk>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>, Gary Parker
<G.J.Parker at lboro.ac.uk>
Cc: Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<B5861604FFBFF545BA7BDD7763E6C3FCBDCFEC26 at CSEXMBOX05.charles-stanley.co.uk>
Content-Type: text/plain; charset="utf-8"
Thanks very much for your help gents ? this is working for me now,
One final thing, when I make a call I receive ?sorry? before the message plays.
Is there a way to remove this system default?
From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com]
Sent: 12 October 2018 14:53
To: Gary Parker
Cc: James Dust; Cisco VoIP Group
Subject: Re: [cisco-voip] Unity Call Handler recording upload
I agree. How awesome would it be if it did the conversion purely client side?
On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <G.J.Parker at lboro.ac.uk<mailto:G.J.Parker at lboro.ac.uk>> wrote:
> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
>
> In addition to Audacity, which I use myself, try this site out: http://g711.org/
Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!
---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary at lboro.ac.uk<mailto:sip%3Agary at lboro.ac.uk> o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/
Consider the environment - Think before you print
The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.
You are advised that urgent, time-sensitive communications should not be sent by email. We hereby give you notice that a delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL http://www.charles-stanley.co.uk/contact-us/disclosure/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/c7cbc63f/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 12 Oct 2018 09:07:31 -0500
From: Bill Talley <btalley at gmail.com>
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: G.J.Parker at lboro.ac.uk, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<CAM+6AtDDQKs0pFzeJoexmvoTOUBGJ9jqYzaWTyrup6PDb3OgDg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
(replying all this time doh)
Client side, as in using the built-in afconvert command in Mac OSX?
If you have a MacBook, keep reading, otherwise this may not interest you.
In addition to creating temporary prompt files from the command line on
your Mac, you can also convert incompatible prompt files quickly and easily
from the command line with the following command.
afconvert -d ?ulaw at 8000? -f ?WAVE? {source file name} {destination file
name}
For example, to convert HelpDesk.mp3 to the compatible uLaw format, the
following command would be executed from the directory containing
HelpDesk.mp3.
afconvert -d ?ulaw at 8000? -f ?WAVE? HelpDesk.mp3 HelpDesk.wav
On Fri, Oct 12, 2018 at 8:54 AM Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:
> I agree. How awesome would it be if it did the conversion purely client
> side?
>
> On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <G.J.Parker at lboro.ac.uk>
> wrote:
>
>>
>>
>> > On 12 Oct 2018, at 14:43, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>> >
>> > In addition to Audacity, which I use myself, try this site out:
>> http://g711.org/
>>
>> Neat idea, and well implemented, but obviously please be wary of sending
>> your data to someone else?s site!
>>
>>
>> ---
>> /-Gary Parker----------------------------------f--\
>> | Unified Communications Service Manager |
>> n Loughborough University, IT Services |
>> | tel:+441509635635 sip:gary at lboro.ac.uk o
>> | https://www.osx.ninja/pubkey.txt |
>> \r----------------------------------------------d-/
>>
>> _______________________________________________
> 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/20181012/9c096da5/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 12 Oct 2018 14:29:51 +0000
From: Myron Young <mdavid_young at hotmail.com>
To: James Dust <james.dust at charles-stanley.co.uk>
Cc: Anthony Holloway <avholloway+cisco-voip at gmail.com>, Gary Parker
<G.J.Parker at lboro.ac.uk>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<SN1PR12MB0189BC1722CC248A12ABBBE8E9E20 at SN1PR12MB0189.namprd12.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hey James,
Usually when you hear the ?sorry? then audio uploaded means it was uploaded to the recorded name and not actual greeting for the call handler. Make sure you have uploaded your audio file to the standard or closed greeting as needed for each call handler.
Sent from my iPhone
On Oct 12, 2018, at 8:06 AM, James Dust <james.dust at charles-stanley.co.uk<mailto:james.dust at charles-stanley.co.uk>> wrote:
Thanks very much for your help gents ? this is working for me now,
One final thing, when I make a call I receive ?sorry? before the message plays.
Is there a way to remove this system default?
From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com]
Sent: 12 October 2018 14:53
To: Gary Parker
Cc: James Dust; Cisco VoIP Group
Subject: Re: [cisco-voip] Unity Call Handler recording upload
I agree. How awesome would it be if it did the conversion purely client side?
On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <G.J.Parker at lboro.ac.uk<mailto:G.J.Parker at lboro.ac.uk>> wrote:
> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
>
> In addition to Audacity, which I use myself, try this site out: http://g711.org/
Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!
---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary at lboro.ac.uk<mailto:sip%3Agary at lboro.ac.uk> o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/
Consider the environment - Think before you print
The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.
You are advised that urgent, time-sensitive communications should not be sent by email. We hereby give you notice that a delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL http://www.charles-stanley.co.uk/contact-us/disclosure/
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/beb37e79/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 12 Oct 2018 14:52:47 +0000
From: James Dust <james.dust at charles-stanley.co.uk>
To: Myron Young <mdavid_young at hotmail.com>
Cc: Anthony Holloway <avholloway+cisco-voip at gmail.com>, Gary Parker
<G.J.Parker at lboro.ac.uk>, Cisco VoIP Group
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Message-ID:
<B5861604FFBFF545BA7BDD7763E6C3FCBDCFEE6D at CSEXMBOX05.charles-stanley.co.uk>
Content-Type: text/plain; charset="utf-8"
Thank you for your help,
Kind Regards
James Dust
ICT Network Infrastructure & Communications Engineer
[cid:image005.png at 01D17638.0229E040]
55 Bishopsgate, London EC2N 3AS
Telephone: 020 7149 6314
Website<http://www.charles-stanley.co.uk/> | LinkedIn<https://www.linkedin.com/company/charles-stanley> | Twitter<https://twitter.com/_CharlesStanley>
From: Myron Young [mailto:mdavid_young at hotmail.com]
Sent: 12 October 2018 15:30
To: James Dust
Cc: Anthony Holloway; Gary Parker; Cisco VoIP Group
Subject: Re: [cisco-voip] Unity Call Handler recording upload
Hey James,
Usually when you hear the ?sorry? then audio uploaded means it was uploaded to the recorded name and not actual greeting for the call handler. Make sure you have uploaded your audio file to the standard or closed greeting as needed for each call handler.
Sent from my iPhone
On Oct 12, 2018, at 8:06 AM, James Dust <james.dust at charles-stanley.co.uk<mailto:james.dust at charles-stanley.co.uk>> wrote:
Thanks very much for your help gents ? this is working for me now,
One final thing, when I make a call I receive ?sorry? before the message plays.
Is there a way to remove this system default?
From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com]
Sent: 12 October 2018 14:53
To: Gary Parker
Cc: James Dust; Cisco VoIP Group
Subject: Re: [cisco-voip] Unity Call Handler recording upload
I agree. How awesome would it be if it did the conversion purely client side?
On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <G.J.Parker at lboro.ac.uk<mailto:G.J.Parker at lboro.ac.uk>> wrote:
> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
>
> In addition to Audacity, which I use myself, try this site out: http://g711.org/
Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!
---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary at lboro.ac.uk<mailto:sip%3Agary at lboro.ac.uk> o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/
Consider the environment - Think before you print
The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.
You are advised that urgent, time-sensitive communications should not be sent by email. We hereby give you notice that a delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL http://www.charles-stanley.co.uk/contact-us/disclosure/
_______________________________________________
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
Consider the environment - Think before you print
The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.
You are advised that urgent, time-sensitive communications should not be sent by email. We hereby give you notice that a delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL http://www.charles-stanley.co.uk/contact-us/disclosure/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6097 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.png>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 180, Issue 11
*******************************************
| | Virus-free. www.avg.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181229/0a719067/attachment.html>
More information about the cisco-voip
mailing list