<html><head></head><body><div class="ydpbf28e7b0yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div><br></div><div><br></div>
</div><div id="ydp12a32461yahoo_quoted_7039162377" class="ydp12a32461yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, October 12, 2018, 6:02:26 PM GMT+2, <cisco-voip-request@puck.nether.net> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Send cisco-voip mailing list submissions to<br></div><div dir="ltr"> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr"><br></div><div dir="ltr">To subscribe or unsubscribe via the World Wide Web, visit<br></div><div dir="ltr"> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">or, via email, send a message with subject or body 'help' to<br></div><div dir="ltr"> <a href="mailto:cisco-voip-request@puck.nether.net" rel="nofollow" target="_blank">cisco-voip-request@puck.nether.net</a><br></div><div dir="ltr"><br></div><div dir="ltr">You can reach the person managing the list at<br></div><div dir="ltr"> <a href="mailto:cisco-voip-owner@puck.nether.net" rel="nofollow" target="_blank">cisco-voip-owner@puck.nether.net</a><br></div><div dir="ltr"><br></div><div dir="ltr">When replying, please edit your Subject line so it is more specific<br></div><div dir="ltr">than "Re: Contents of cisco-voip digest..."<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Today's Topics:<br></div><div dir="ltr"><br></div><div dir="ltr"> 1. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Anthony Holloway)<br></div><div dir="ltr"> 2. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Nick Barnett)<br></div><div dir="ltr"> 3. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Kent Roberts)<br></div><div dir="ltr"> 4. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Anthony Holloway)<br></div><div dir="ltr"> 5. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Kent Roberts)<br></div><div dir="ltr"> 6. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Kent Roberts)<br></div><div dir="ltr"> 7. Re: SIP OPTIONS pings are blocked on Cisco CUBE 3945E -<br></div><div dir="ltr"> Resource failure, dropping OPTIONS (Anthony Holloway)<br></div><div dir="ltr"> 8. Any Alertus integrations out there? Successful or otherwise?<br></div><div dir="ltr"> (Lelio Fulgenzi)<br></div><div dir="ltr"> 9. Re: anonymous proximity issues? (Ryan Ratliff (rratliff))<br></div><div dir="ltr"> 10. Re: [EXTERNAL] Re: 8832 Design Issue? (Ryan Ratliff (rratliff))<br></div><div dir="ltr"> 11. Re: anonymous proximity issues? (Lelio Fulgenzi)<br></div><div dir="ltr"> 12. Re: [EXTERNAL] Re: 8832 Design Issue? (Lelio Fulgenzi)<br></div><div dir="ltr"> 13. Unity Call Handler recording upload (James Dust)<br></div><div dir="ltr"> 14. Re: Unity Call Handler recording upload (Gary Parker)<br></div><div dir="ltr"> 15. Re: anonymous proximity issues? (Ryan Ratliff (rratliff))<br></div><div dir="ltr"> 16. Re: Unity Call Handler recording upload (Anthony Holloway)<br></div><div dir="ltr"> 17. Re: Unity Call Handler recording upload (Gary Parker)<br></div><div dir="ltr"> 18. Re: Unity Call Handler recording upload (Anthony Holloway)<br></div><div dir="ltr"> 19. Re: Unity Call Handler recording upload (James Dust)<br></div><div dir="ltr"> 20. Re: Unity Call Handler recording upload (Bill Talley)<br></div><div dir="ltr"> 21. Re: Unity Call Handler recording upload (Myron Young)<br></div><div dir="ltr"> 22. Re: Unity Call Handler recording upload (James Dust)<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">----------------------------------------------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 1<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 11:11:38 -0500<br></div><div dir="ltr">From: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">To: Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">Cc: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CACRCJOiND+<a href="mailto:8MGY-nuYisQCVU4Ltv1sSMubOP2o8A_4wKryZZRQ@mail.gmail.com" rel="nofollow" target="_blank">8MGY-nuYisQCVU4Ltv1sSMubOP2o8A_4wKryZZRQ@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">I feel obligated to reply, since I chimed in earlier....unfortunately, I<br></div><div dir="ltr">don't have any ideas for you. In fact, I have seen CUBE just ignore<br></div><div dir="ltr">incoming SIP messages before, both OPTIONS and INVITEs alike. Not many<br></div><div dir="ltr">occasions, just a few. I have never gotten resolution on it, it has either<br></div><div dir="ltr">fixed itself, or in one special case, still happens. It's my own, in<br></div><div dir="ltr">fact. It still randomly ignores inbound INVITES from my ITSP. Fixing it,<br></div><div dir="ltr">is on my to-do list, but... The cobbler's children are always the<br></div><div dir="ltr">worst-shod<br></div><div dir="ltr"><<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>.<br></div><div dir="ltr">The Calls Per Second on my CUBE is like 1.7, however, there are no other<br></div><div dir="ltr">calls being setup, torn down, sup service, etc, and CUBE still just ignores<br></div><div dir="ltr">its responsibility.<br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">> Hello<br></div><div dir="ltr">><br></div><div dir="ltr">> Do you have an idea how to get around this problem?<br></div><div dir="ltr">> Have you ever encountered such limitations in the process of processing<br></div><div dir="ltr">> OPTIONS packages?<br></div><div dir="ltr">><br></div><div dir="ltr">> Thanks<br></div><div dir="ltr">> Maciej.<br></div><div dir="ltr">><br></div><div dir="ltr">> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">><br></div><div dir="ltr">>> Hello<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Anthony, thanks for the hint, but you were right this is not the core of<br></div><div dir="ltr">>> the issue.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> I made some test via sipp with following results<br></div><div dir="ltr">>> 1)<br></div><div dir="ltr">>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>> Result: All OPTIONS were replied<br></div><div dir="ltr">>><br></div><div dir="ltr">>> 2)<br></div><div dir="ltr">>> Test: shortly after completing the above test I made another test: Send<br></div><div dir="ltr">>> 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> 3)<br></div><div dir="ltr">>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>> Result: All OPTIONS were replied<br></div><div dir="ltr">>><br></div><div dir="ltr">>> So it seems Cisco records the Call-ID and From-tag somewhere in memory<br></div><div dir="ltr">>> and drops subsequent OPTIONS with the same Call-ID and different From-tag<br></div><div dir="ltr">>> that come from the same endpoint for some time.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> I have similar situation here.<br></div><div dir="ltr">>> The customer we are trying to connect sends several OPTIONS within<br></div><div dir="ltr">>> miliseconds.<br></div><div dir="ltr">>> First OPTIONS is replied properly, but subsequent packets with the same<br></div><div dir="ltr">>> Call-ID and different From-tag dropped.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Is there any solution for this.<br></div><div dir="ltr">>> Our customer is very reluctant to proceed with any changes (another open<br></div><div dir="ltr">>> source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Thanks<br></div><div dir="ltr">>> Maciej.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">>> napisa?(a):<br></div><div dir="ltr">>><br></div><div dir="ltr">>>> I hope you saw that I wrote "Pseudo Config" and don't just try to copy<br></div><div dir="ltr">>>> and paste that. I'm also not very convinced that this is the core of your<br></div><div dir="ltr">>>> issue, but you're more than welcome to give it a try.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> You said the first OPTIONS does respond, so I'm guessing it's not going<br></div><div dir="ltr">>>> to be a binding error. In fact, if it was a binding error, OPTIONS would<br></div><div dir="ltr">>>> still respond, it would just have wrong IP info in the headers.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Anyway, good luck with that test.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>> wrote:<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Many thanks<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <<br></div><div dir="ltr">>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>>> OPTIONS does not have to match a dial peer to work. However, if you<br></div><div dir="ltr">>>>>> are going to match a dial peer at all, it would likely be for the express<br></div><div dir="ltr">>>>>> purpose of replying from the correct interface, if you have more than one<br></div><div dir="ltr">>>>>> potential interfaces, and you for some reason cannot bind globally. Thus<br></div><div dir="ltr">>>>>> using the correct bind statement on a dial-peer for OPTIONS reply, would be<br></div><div dir="ltr">>>>>> necessary. In which case, you would need to match an incoming call leg<br></div><div dir="ltr">>>>>> dial peer by the SIP Via header alone, and not, say for example, incoming<br></div><div dir="ltr">>>>>> called number.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Example Pseudo Configuration:<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> voice class sip uri 100<br></div><div dir="ltr">>>>>> host ipv4:10.1.1.1<br></div><div dir="ltr">>>>>> !<br></div><div dir="ltr">>>>>> dial-peer voice 100 voip<br></div><div dir="ltr">>>>>> incoming uri via 100<br></div><div dir="ltr">>>>>> bind media interface g0/1<br></div><div dir="ltr">>>>>> bind control interface g0/1<br></div><div dir="ltr">>>>>> !<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>> wrote:<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>>> Thanks for prompt answer.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> No, i am not using CCP.<br></div><div dir="ltr">>>>>>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric<br></div><div dir="ltr">>>>>>> calling number: *stringhere*<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA<br></div><div dir="ltr">>>>>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match<br></div><div dir="ltr">>>>>>> incoming dialpeer for Calling number: : *stringhere*<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> input arg error<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match<br></div><div dir="ltr">>>>>>> found for P-Called-Party-ID<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> input argument error<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition<br></div><div dir="ltr">>>>>>> tag absent in Require/Supported header<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media<br></div><div dir="ltr">>>>>>> Antitrombone disabled<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the<br></div><div dir="ltr">>>>>>> configured mode as FLOW-THROUGH<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder<br></div><div dir="ltr">>>>>>> high-density disabled<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode<br></div><div dir="ltr">>>>>>> set to FLOW_THROUGH<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer<br></div><div dir="ltr">>>>>>> leg - using RTP Supported Codecs<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 18<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 0<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 8<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 9<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 4<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 2<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 15<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>> Codecs supported by GW 255<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:<br></div><div dir="ltr">>>>>>> MF: Not a Forked SIP leg..<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp<br></div><div dir="ltr">>>>>>> configure for this leg.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:<br></div><div dir="ltr">>>>>>> peer_callID=0<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> MF: *Dial-peer is absent*..<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state<br></div><div dir="ltr">>>>>>> = 0 & New state = -1<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:<br></div><div dir="ltr">>>>>>> MF: Anchor leg config reset done...<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> OPTIONS looks like following:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> OPTIONS sip:domain.name.here:5060 SIP/2.0<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> From: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> To: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> I do not have any script in use there, the configuration in pretty<br></div><div dir="ltr">>>>>>> basic.<br></div><div dir="ltr">>>>>>> What i have found is that second OPTIONS (the one that is<br></div><div dir="ltr">>>>>>> left/dropped without OK) also generates following output:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:<br></div><div dir="ltr">>>>>>> Checking Invite Dialog<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:<br></div><div dir="ltr">>>>>>> *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>> //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying<br></div><div dir="ltr">>>>>>> with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>> //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> old_from: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> old_to: <sip:*stringhere*@domain.name.here>;tag=D7E844-1438<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> new_from: <sip:*stringhere*@domain.name.here>;tag=6c7f09452671<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> new_to: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> ....<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Freeing NULL pointer!<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Could you please point me where i can find some information how to<br></div><div dir="ltr">>>>>>> create such dial-peer for OPTIONS or give me a brief example of this<br></div><div dir="ltr">>>>>>> configuration please.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Thanks<br></div><div dir="ltr">>>>>>> Maciej.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">>>>>>> napisa?(a):<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>>> Are you using Customer Call Back? Which dial peer is the options<br></div><div dir="ltr">>>>>>>> ping hitting? Does that dial peer have the CCB script on it? If so... maybe<br></div><div dir="ltr">>>>>>>> make another dial peer for options pings that does not have the script<br></div><div dir="ltr">>>>>>>> enabled. This is just a hunch...<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>>> wrote:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>>> Hi<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>>>>>>>> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only<br></div><div dir="ltr">>>>>>>>> to the first OPTIONS packet that is received from the endpoint.<br></div><div dir="ltr">>>>>>>>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694907: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694908: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694909: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State<br></div><div dir="ltr">>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694911: *Could not add ccb to table*.<br></div><div dir="ltr">>>>>>>>> ccb=0x258D7210<br></div><div dir="ltr">>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694912: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694913: *Resource failure, dropping<br></div><div dir="ltr">>>>>>>>> OPTIONS*<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> The true is that Cisco receives quite significant amount of SIP<br></div><div dir="ltr">>>>>>>>> OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within<br></div><div dir="ltr">>>>>>>>> miliseconds.<br></div><div dir="ltr">>>>>>>>> The after-effect i want to achieve is a response for each incoming<br></div><div dir="ltr">>>>>>>>> OPTIONS<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Example of a successful response:<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625106: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625107: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625108: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State<br></div><div dir="ltr">>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625109: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to<br></div><div dir="ltr">>>>>>>>> table. ccb=0x258B1110<br></div><div dir="ltr">>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance<br></div><div dir="ltr">>>>>>>>> 1<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625110: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:<br></div><div dir="ltr">>>>>>>>> Adding call id 23DA9 to table<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625111: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event:<br></div><div dir="ltr">>>>>>>>> ccsip_spi_get_msg_type returned: 3 for event 38<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625112: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created<br></div><div dir="ltr">>>>>>>>> msg=0x203FFDA4 with refCount = 1<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625113: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:<br></div><div dir="ltr">>>>>>>>> Associated container=0x2673A528 to Options Response<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625114: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:<br></div><div dir="ltr">>>>>>>>> sipSPIAppHandleContainerBody len 164<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625115: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:<br></div><div dir="ltr">>>>>>>>> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,<br></div><div dir="ltr">>>>>>>>> is_req=0, transport=1, switch=0, callBack=0x4F48054<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625116: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP<br></div><div dir="ltr">>>>>>>>> extension config:1, check sys cfg:1<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625117: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable<br></div><div dir="ltr">>>>>>>>> for sending msg immediately<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625118: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to<br></div><div dir="ltr">>>>>>>>> send resp=0x203FFDA4 to default port=5060<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625119: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:<br></div><div dir="ltr">>>>>>>>> connection required for raddr:11.11.11.11, rport:5060 with laddr:<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625120: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceGetConnectionId: Registering<br></div><div dir="ltr">>>>>>>>> gcb=0x258B1110 with connection=0x2426673C context list<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625121: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection<br></div><div dir="ltr">>>>>>>>> obtained...sending msg=0x203FFDA4<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625122: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send<br></div><div dir="ltr">>>>>>>>> for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for<br></div><div dir="ltr">>>>>>>>> UDP<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>> //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Maciej<br></div><div dir="ltr">>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/8957f314/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/8957f314/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 2<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 13:36:58 -0500<br></div><div dir="ltr">From: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">Cc: <a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CAPtKLNC+edyhxWfd5VaLPFWAPWufyX=<a href="mailto:65VUC5LXuM4k7h3jrjw@mail.gmail.com" rel="nofollow" target="_blank">65VUC5LXuM4k7h3jrjw@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">I don?t know what the problem is either. Maybe if you grab ccapi inout<br></div><div dir="ltr">debugs at the same time, your voice service voip section (at least, whole<br></div><div dir="ltr">config would be better), sh ver, and show run | sec voice. Maybe even do a<br></div><div dir="ltr">debug ccsip all if you have the ability to do that and NOT crash your CUBE.<br></div><div dir="ltr">Obviously don?t debug ccsip all without thinking about what that will do.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Even with all of that, I?m not sure I?ll have an answer, but I?ll look.<br></div><div dir="ltr">I?ve had similar issues with my CUBEs and it was due to binding issues and<br></div><div dir="ltr">another time it was a straight up bug and I had to bounce the box (which<br></div><div dir="ltr">?fixed? it). I don?t know why your initial debug was showing ?could not<br></div><div dir="ltr">add ccb to table? and I?m not even sure which CCB it?s talking about. My<br></div><div dir="ltr">thoughts were that is customer callback? but I?m probably wrong on that one.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Nick<br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <<br></div><div dir="ltr">avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">> I feel obligated to reply, since I chimed in earlier....unfortunately, I<br></div><div dir="ltr">> don't have any ideas for you. In fact, I have seen CUBE just ignore<br></div><div dir="ltr">> incoming SIP messages before, both OPTIONS and INVITEs alike. Not many<br></div><div dir="ltr">> occasions, just a few. I have never gotten resolution on it, it has either<br></div><div dir="ltr">> fixed itself, or in one special case, still happens. It's my own, in<br></div><div dir="ltr">> fact. It still randomly ignores inbound INVITES from my ITSP. Fixing it,<br></div><div dir="ltr">> is on my to-do list, but... The cobbler's children are always the<br></div><div dir="ltr">> worst-shod<br></div><div dir="ltr">> <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>.<br></div><div dir="ltr">> The Calls Per Second on my CUBE is like 1.7, however, there are no other<br></div><div dir="ltr">> calls being setup, torn down, sup service, etc, and CUBE still just ignores<br></div><div dir="ltr">> its responsibility.<br></div><div dir="ltr">><br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">>> Hello<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Do you have an idea how to get around this problem?<br></div><div dir="ltr">>> Have you ever encountered such limitations in the process of processing<br></div><div dir="ltr">>> OPTIONS packages?<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Thanks<br></div><div dir="ltr">>> Maciej.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>><br></div><div dir="ltr">>>> Hello<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Anthony, thanks for the hint, but you were right this is not the core of<br></div><div dir="ltr">>>> the issue.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> I made some test via sipp with following results<br></div><div dir="ltr">>>> 1)<br></div><div dir="ltr">>>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> 2)<br></div><div dir="ltr">>>> Test: shortly after completing the above test I made another test: Send<br></div><div dir="ltr">>>> 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> 3)<br></div><div dir="ltr">>>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> So it seems Cisco records the Call-ID and From-tag somewhere in memory<br></div><div dir="ltr">>>> and drops subsequent OPTIONS with the same Call-ID and different From-tag<br></div><div dir="ltr">>>> that come from the same endpoint for some time.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> I have similar situation here.<br></div><div dir="ltr">>>> The customer we are trying to connect sends several OPTIONS within<br></div><div dir="ltr">>>> miliseconds.<br></div><div dir="ltr">>>> First OPTIONS is replied properly, but subsequent packets with the same<br></div><div dir="ltr">>>> Call-ID and different From-tag dropped.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Is there any solution for this.<br></div><div dir="ltr">>>> Our customer is very reluctant to proceed with any changes (another open<br></div><div dir="ltr">>>> source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Thanks<br></div><div dir="ltr">>>> Maciej.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <<br></div><div dir="ltr">>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>>> I hope you saw that I wrote "Pseudo Config" and don't just try to copy<br></div><div dir="ltr">>>>> and paste that. I'm also not very convinced that this is the core of your<br></div><div dir="ltr">>>>> issue, but you're more than welcome to give it a try.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> You said the first OPTIONS does respond, so I'm guessing it's not going<br></div><div dir="ltr">>>>> to be a binding error. In fact, if it was a binding error, OPTIONS would<br></div><div dir="ltr">>>>> still respond, it would just have wrong IP info in the headers.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Anyway, good luck with that test.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>> wrote:<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Many thanks<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <<br></div><div dir="ltr">>>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>>> OPTIONS does not have to match a dial peer to work. However, if you<br></div><div dir="ltr">>>>>>> are going to match a dial peer at all, it would likely be for the express<br></div><div dir="ltr">>>>>>> purpose of replying from the correct interface, if you have more than one<br></div><div dir="ltr">>>>>>> potential interfaces, and you for some reason cannot bind globally. Thus<br></div><div dir="ltr">>>>>>> using the correct bind statement on a dial-peer for OPTIONS reply, would be<br></div><div dir="ltr">>>>>>> necessary. In which case, you would need to match an incoming call leg<br></div><div dir="ltr">>>>>>> dial peer by the SIP Via header alone, and not, say for example, incoming<br></div><div dir="ltr">>>>>>> called number.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Example Pseudo Configuration:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> voice class sip uri 100<br></div><div dir="ltr">>>>>>> host ipv4:10.1.1.1<br></div><div dir="ltr">>>>>>> !<br></div><div dir="ltr">>>>>>> dial-peer voice 100 voip<br></div><div dir="ltr">>>>>>> incoming uri via 100<br></div><div dir="ltr">>>>>>> bind media interface g0/1<br></div><div dir="ltr">>>>>>> bind control interface g0/1<br></div><div dir="ltr">>>>>>> !<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>> wrote:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>>> Thanks for prompt answer.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> No, i am not using CCP.<br></div><div dir="ltr">>>>>>>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric<br></div><div dir="ltr">>>>>>>> calling number: *stringhere*<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA<br></div><div dir="ltr">>>>>>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match<br></div><div dir="ltr">>>>>>>> incoming dialpeer for Calling number: : *stringhere*<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> input arg error<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match<br></div><div dir="ltr">>>>>>>> found for P-Called-Party-ID<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> input argument error<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition<br></div><div dir="ltr">>>>>>>> tag absent in Require/Supported header<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media<br></div><div dir="ltr">>>>>>>> Antitrombone disabled<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the<br></div><div dir="ltr">>>>>>>> configured mode as FLOW-THROUGH<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder<br></div><div dir="ltr">>>>>>>> high-density disabled<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode<br></div><div dir="ltr">>>>>>>> set to FLOW_THROUGH<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer<br></div><div dir="ltr">>>>>>>> leg - using RTP Supported Codecs<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 18<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 0<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 8<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 9<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 4<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 2<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 15<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>> Codecs supported by GW 255<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:<br></div><div dir="ltr">>>>>>>> MF: Not a Forked SIP leg..<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp<br></div><div dir="ltr">>>>>>>> configure for this leg.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:<br></div><div dir="ltr">>>>>>>> peer_callID=0<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> MF: *Dial-peer is absent*..<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state<br></div><div dir="ltr">>>>>>>> = 0 & New state = -1<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:<br></div><div dir="ltr">>>>>>>> MF: Anchor leg config reset done...<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> OPTIONS looks like following:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> OPTIONS sip:domain.name.here:5060 SIP/2.0<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> From: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> To: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> I do not have any script in use there, the configuration in pretty<br></div><div dir="ltr">>>>>>>> basic.<br></div><div dir="ltr">>>>>>>> What i have found is that second OPTIONS (the one that is<br></div><div dir="ltr">>>>>>>> left/dropped without OK) also generates following output:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:<br></div><div dir="ltr">>>>>>>> Checking Invite Dialog<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:<br></div><div dir="ltr">>>>>>>> *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>> //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying<br></div><div dir="ltr">>>>>>>> with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>> //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> old_from: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> old_to: <sip:*stringhere*@domain.name.here>;tag=D7E844-1438<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> new_from: <sip:*stringhere*@domain.name.here>;tag=6c7f09452671<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> new_to: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> ....<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Freeing NULL pointer!<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Could you please point me where i can find some information how to<br></div><div dir="ltr">>>>>>>> create such dial-peer for OPTIONS or give me a brief example of this<br></div><div dir="ltr">>>>>>>> configuration please.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Thanks<br></div><div dir="ltr">>>>>>>> Maciej.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">>>>>>>> napisa?(a):<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>>> Are you using Customer Call Back? Which dial peer is the options<br></div><div dir="ltr">>>>>>>>> ping hitting? Does that dial peer have the CCB script on it? If so... maybe<br></div><div dir="ltr">>>>>>>>> make another dial peer for options pings that does not have the script<br></div><div dir="ltr">>>>>>>>> enabled. This is just a hunch...<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>>>> wrote:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Hi<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>>>>>>>>> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only<br></div><div dir="ltr">>>>>>>>>> to the first OPTIONS packet that is received from the endpoint.<br></div><div dir="ltr">>>>>>>>>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694907: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694908: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694909: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State<br></div><div dir="ltr">>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694911: *Could not add ccb to table*.<br></div><div dir="ltr">>>>>>>>>> ccb=0x258D7210<br></div><div dir="ltr">>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694912: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694913: *Resource failure, dropping<br></div><div dir="ltr">>>>>>>>>> OPTIONS*<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> The true is that Cisco receives quite significant amount of SIP<br></div><div dir="ltr">>>>>>>>>> OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within<br></div><div dir="ltr">>>>>>>>>> miliseconds.<br></div><div dir="ltr">>>>>>>>>> The after-effect i want to achieve is a response for each incoming<br></div><div dir="ltr">>>>>>>>>> OPTIONS<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Example of a successful response:<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625106: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625107: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625108: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State<br></div><div dir="ltr">>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625109: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to<br></div><div dir="ltr">>>>>>>>>> table. ccb=0x258B1110<br></div><div dir="ltr">>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance<br></div><div dir="ltr">>>>>>>>>> 1<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625110: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:<br></div><div dir="ltr">>>>>>>>>> Adding call id 23DA9 to table<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625111: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event:<br></div><div dir="ltr">>>>>>>>>> ccsip_spi_get_msg_type returned: 3 for event 38<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625112: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created<br></div><div dir="ltr">>>>>>>>>> msg=0x203FFDA4 with refCount = 1<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625113: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:<br></div><div dir="ltr">>>>>>>>>> Associated container=0x2673A528 to Options Response<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625114: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:<br></div><div dir="ltr">>>>>>>>>> sipSPIAppHandleContainerBody len 164<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625115: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:<br></div><div dir="ltr">>>>>>>>>> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,<br></div><div dir="ltr">>>>>>>>>> is_req=0, transport=1, switch=0, callBack=0x4F48054<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625116: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP<br></div><div dir="ltr">>>>>>>>>> extension config:1, check sys cfg:1<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625117: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable<br></div><div dir="ltr">>>>>>>>>> for sending msg immediately<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625118: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to<br></div><div dir="ltr">>>>>>>>>> send resp=0x203FFDA4 to default port=5060<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625119: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:<br></div><div dir="ltr">>>>>>>>>> connection required for raddr:11.11.11.11, rport:5060 with laddr:<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625120: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceGetConnectionId: Registering<br></div><div dir="ltr">>>>>>>>>> gcb=0x258B1110 with connection=0x2426673C context list<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625121: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection<br></div><div dir="ltr">>>>>>>>>> obtained...sending msg=0x203FFDA4<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625122: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send<br></div><div dir="ltr">>>>>>>>>> for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for<br></div><div dir="ltr">>>>>>>>>> UDP<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>> //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Maciej<br></div><div dir="ltr">>>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/9b310fc1/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/9b310fc1/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 3<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 14:32:20 -0600<br></div><div dir="ltr">From: Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>><br></div><div dir="ltr">To: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">Cc: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>>,<br></div><div dir="ltr"> "<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID: <<a href="mailto:AD10D715-86F7-48E9-B5B1-BB86E5714F4E@fredf.org" rel="nofollow" target="_blank">AD10D715-86F7-48E9-B5B1-BB86E5714F4E@fredf.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Here is what I use:<br></div><div dir="ltr"><br></div><div dir="ltr">voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2<br></div><div dir="ltr"><br></div><div dir="ltr">Sh dial-peer voice sum the Keepalive line will show busyout or active.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On Oct 11, 2018, at 12:36 PM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>> wrote:<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> Nick<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">> 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 <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>. 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">> Hello<br></div><div dir="ltr">> <br></div><div dir="ltr">> Do you have an idea how to get around this problem?<br></div><div dir="ltr">> Have you ever encountered such limitations in the process of processing OPTIONS packages? <br></div><div dir="ltr">> <br></div><div dir="ltr">> Thanks<br></div><div dir="ltr">> Maciej.<br></div><div dir="ltr">> <br></div><div dir="ltr">> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">> Hello<br></div><div dir="ltr">> <br></div><div dir="ltr">> Anthony, thanks for the hint, but you were right this is not the core of the issue.<br></div><div dir="ltr">> <br></div><div dir="ltr">> I made some test via sipp with following results<br></div><div dir="ltr">> 1) <br></div><div dir="ltr">> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">> Result: All OPTIONS were replied<br></div><div dir="ltr">> <br></div><div dir="ltr">> 2) <br></div><div dir="ltr">> Test: shortly after completing the above test I made another test: Send 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">> <br></div><div dir="ltr">> 3) <br></div><div dir="ltr">> Test: Test 2 was re-run after a while<br></div><div dir="ltr">> Result: All OPTIONS were replied<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> I have similar situation here.<br></div><div dir="ltr">> The customer we are trying to connect sends several OPTIONS within miliseconds.<br></div><div dir="ltr">> First OPTIONS is replied properly, but subsequent packets with the same Call-ID and different From-tag dropped.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Is there any solution for this.<br></div><div dir="ltr">> Our customer is very reluctant to proceed with any changes (another open source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">> <br></div><div dir="ltr">> Thanks<br></div><div dir="ltr">> Maciej.<br></div><div dir="ltr">> <br></div><div dir="ltr">> wt., 9 pa? 2018 o 23:45 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Anyway, good luck with that test.<br></div><div dir="ltr">> <br></div><div dir="ltr">> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Many thanks<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> wt., 9 pa? 2018 o 20:58 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Example Pseudo Configuration:<br></div><div dir="ltr">> <br></div><div dir="ltr">> voice class sip uri 100<br></div><div dir="ltr">> host ipv4:10.1.1.1<br></div><div dir="ltr">> !<br></div><div dir="ltr">> dial-peer voice 100 voip<br></div><div dir="ltr">> incoming uri via 100<br></div><div dir="ltr">> bind media interface g0/1<br></div><div dir="ltr">> bind control interface g0/1<br></div><div dir="ltr">> !<br></div><div dir="ltr">> <br></div><div dir="ltr">> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">> Thanks for prompt answer.<br></div><div dir="ltr">> <br></div><div dir="ltr">> No, i am not using CCP.<br></div><div dir="ltr">> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">> <br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric calling number: stringhere<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA URL:sip:10.10.10.10:5060 <<a href="http://10.10.10.10:5060/" rel="nofollow" target="_blank">http://10.10.10.10:5060/</a>>, Host:100.64.4.31<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match incoming dialpeer for Calling number: : stringhere<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId: <br></div><div dir="ltr">> input arg error<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match found for P-Called-Party-ID<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo: <br></div><div dir="ltr">> input argument error<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition tag absent in Require/Supported header<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media Antitrombone disabled<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the configured mode as FLOW-THROUGH<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder high-density disabled<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode set to FLOW_THROUGH<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer leg - using RTP Supported Codecs<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 18<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 0<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 8<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 9<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 4<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 2<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 15<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 255<br></div><div dir="ltr">> 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..<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp configure for this leg.<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall: peer_callID=0<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config: <br></div><div dir="ltr">> MF: Dial-peer is absent..<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state = 0 & New state = -1<br></div><div dir="ltr">> 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...<br></div><div dir="ltr">> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config: <br></div><div dir="ltr">> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">> <br></div><div dir="ltr">> OPTIONS looks like following:<br></div><div dir="ltr">> OPTIONS sip:domain.name.here:5060 SIP/2.0<br></div><div dir="ltr">> From: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">> To: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> I do not have any script in use there, the configuration in pretty basic.<br></div><div dir="ltr">> What i have found is that second OPTIONS (the one that is left/dropped without OK) also generates following output:<br></div><div dir="ltr">> Oct 9 17:50:38.070: //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor: Checking Invite Dialog<br></div><div dir="ltr">> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable: *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">> <br></div><div dir="ltr">> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest: <br></div><div dir="ltr">> <br></div><div dir="ltr">> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">> old_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">> old_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=D7E844-1438<br></div><div dir="ltr">> new_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=6c7f09452671<br></div><div dir="ltr">> new_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">> ....<br></div><div dir="ltr">> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free: <br></div><div dir="ltr">> Freeing NULL pointer!<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Thanks<br></div><div dir="ltr">> Maciej.<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a> <mailto:<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">> 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...<br></div><div dir="ltr">> <br></div><div dir="ltr">> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">> Hi<br></div><div dir="ltr">> <br></div><div dir="ltr">> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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)<br></div><div dir="ltr">> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194: //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">> Oct 9 12:52:06 10.10.10.10 8694911: Could not add ccb to table. ccb=0x258D7210 key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">> 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:<br></div><div dir="ltr">> Oct 9 12:52:06 10.10.10.10 8694913: Resource failure, dropping OPTIONS<br></div><div dir="ltr">> <br></div><div dir="ltr">> The true is that Cisco receives quite significant amount of SIP OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within miliseconds.<br></div><div dir="ltr">> The after-effect i want to achieve is a response for each incoming OPTIONS<br></div><div dir="ltr">> <br></div><div dir="ltr">> Example of a successful response:<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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)<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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:<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> 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<br></div><div dir="ltr">> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569: //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">> <br></div><div dir="ltr">> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Maciej<br></div><div dir="ltr">> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/2daad8af/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/2daad8af/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 4<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 15:42:19 -0500<br></div><div dir="ltr">From: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">To: Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>><br></div><div dir="ltr">Cc: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:CACRCJOjZSesWcyxATgyTOYNXFpmzy0mXKRaq3OjysVeByRAQ0w@mail.gmail.com" rel="nofollow" target="_blank">CACRCJOjZSesWcyxATgyTOYNXFpmzy0mXKRaq3OjysVeByRAQ0w@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Kent,<br></div><div dir="ltr"><br></div><div dir="ltr">I'm not sure why you sent that. The problem is not with sending OPTION<br></div><div dir="ltr">Ping, it's with responding to received OPTION Ping.<br></div><div dir="ltr"><br></div><div dir="ltr">*"The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only to the<br></div><div dir="ltr">first OPTIONS packet that is received from the endpoint. The rest of<br></div><div dir="ltr">OPTIONs are dropped with following debug output"*<br></div><div dir="ltr"><br></div><div dir="ltr">But since you brought it up... The default for that command is:<br></div><div dir="ltr"><br></div><div dir="ltr">voice class sip options-keepalive up-interval 60 down-interval 30 retry 5<br></div><div dir="ltr"><br></div><div dir="ltr">What is your reason for changing it from the default? The rule of thumb is<br></div><div dir="ltr">"use the defaults, unless you have a reason not to"<br></div><div dir="ltr"><br></div><div dir="ltr">I see the obvious answer here: it pings less often; however, it's the *why*<br></div><div dir="ltr">which I am interested in.<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks for sharing what you do.<br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">> Here is what I use:<br></div><div dir="ltr">><br></div><div dir="ltr">> voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2<br></div><div dir="ltr">><br></div><div dir="ltr">> Sh dial-peer voice sum the Keepalive line will show busyout or active.<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> On Oct 11, 2018, at 12:36 PM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> I don?t know what the problem is either. Maybe if you grab ccapi inout<br></div><div dir="ltr">> debugs at the same time, your voice service voip section (at least, whole<br></div><div dir="ltr">> config would be better), sh ver, and show run | sec voice. Maybe even do a<br></div><div dir="ltr">> debug ccsip all if you have the ability to do that and NOT crash your CUBE.<br></div><div dir="ltr">> Obviously don?t debug ccsip all without thinking about what that will do.<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> Even with all of that, I?m not sure I?ll have an answer, but I?ll look.<br></div><div dir="ltr">> I?ve had similar issues with my CUBEs and it was due to binding issues and<br></div><div dir="ltr">> another time it was a straight up bug and I had to bounce the box (which<br></div><div dir="ltr">> ?fixed? it). I don?t know why your initial debug was showing ?could not<br></div><div dir="ltr">> add ccb to table? and I?m not even sure which CCB it?s talking about. My<br></div><div dir="ltr">> thoughts were that is customer callback? but I?m probably wrong on that one.<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> Nick<br></div><div dir="ltr">><br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <<br></div><div dir="ltr">> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">>> I feel obligated to reply, since I chimed in earlier....unfortunately, I<br></div><div dir="ltr">>> don't have any ideas for you. In fact, I have seen CUBE just ignore<br></div><div dir="ltr">>> incoming SIP messages before, both OPTIONS and INVITEs alike. Not many<br></div><div dir="ltr">>> occasions, just a few. I have never gotten resolution on it, it has either<br></div><div dir="ltr">>> fixed itself, or in one special case, still happens. It's my own, in<br></div><div dir="ltr">>> fact. It still randomly ignores inbound INVITES from my ITSP. Fixing it,<br></div><div dir="ltr">>> is on my to-do list, but... The cobbler's children are always the<br></div><div dir="ltr">>> worst-shod<br></div><div dir="ltr">>> <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>.<br></div><div dir="ltr">>> The Calls Per Second on my CUBE is like 1.7, however, there are no other<br></div><div dir="ltr">>> calls being setup, torn down, sup service, etc, and CUBE still just ignores<br></div><div dir="ltr">>> its responsibility.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>> wrote:<br></div><div dir="ltr">>><br></div><div dir="ltr">>>> Hello<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Do you have an idea how to get around this problem?<br></div><div dir="ltr">>>> Have you ever encountered such limitations in the process of processing<br></div><div dir="ltr">>>> OPTIONS packages?<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Thanks<br></div><div dir="ltr">>>> Maciej.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>> napisa?(a):<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>>> Hello<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Anthony, thanks for the hint, but you were right this is not the core<br></div><div dir="ltr">>>>> of the issue.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> I made some test via sipp with following results<br></div><div dir="ltr">>>>> 1)<br></div><div dir="ltr">>>>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> 2)<br></div><div dir="ltr">>>>> Test: shortly after completing the above test I made another test: Send<br></div><div dir="ltr">>>>> 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>>>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> 3)<br></div><div dir="ltr">>>>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> So it seems Cisco records the Call-ID and From-tag somewhere in memory<br></div><div dir="ltr">>>>> and drops subsequent OPTIONS with the same Call-ID and different From-tag<br></div><div dir="ltr">>>>> that come from the same endpoint for some time.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> I have similar situation here.<br></div><div dir="ltr">>>>> The customer we are trying to connect sends several OPTIONS within<br></div><div dir="ltr">>>>> miliseconds.<br></div><div dir="ltr">>>>> First OPTIONS is replied properly, but subsequent packets with the same<br></div><div dir="ltr">>>>> Call-ID and different From-tag dropped.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Is there any solution for this.<br></div><div dir="ltr">>>>> Our customer is very reluctant to proceed with any changes (another<br></div><div dir="ltr">>>>> open source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Thanks<br></div><div dir="ltr">>>>> Maciej.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <<br></div><div dir="ltr">>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>>> I hope you saw that I wrote "Pseudo Config" and don't just try to copy<br></div><div dir="ltr">>>>>> and paste that. I'm also not very convinced that this is the core of your<br></div><div dir="ltr">>>>>> issue, but you're more than welcome to give it a try.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> You said the first OPTIONS does respond, so I'm guessing it's not<br></div><div dir="ltr">>>>>> going to be a binding error. In fact, if it was a binding error, OPTIONS<br></div><div dir="ltr">>>>>> would still respond, it would just have wrong IP info in the headers.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Anyway, good luck with that test.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>> wrote:<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Many thanks<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <<br></div><div dir="ltr">>>>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>>> OPTIONS does not have to match a dial peer to work. However, if you<br></div><div dir="ltr">>>>>>>> are going to match a dial peer at all, it would likely be for the express<br></div><div dir="ltr">>>>>>>> purpose of replying from the correct interface, if you have more than one<br></div><div dir="ltr">>>>>>>> potential interfaces, and you for some reason cannot bind globally. Thus<br></div><div dir="ltr">>>>>>>> using the correct bind statement on a dial-peer for OPTIONS reply, would be<br></div><div dir="ltr">>>>>>>> necessary. In which case, you would need to match an incoming call leg<br></div><div dir="ltr">>>>>>>> dial peer by the SIP Via header alone, and not, say for example, incoming<br></div><div dir="ltr">>>>>>>> called number.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Example Pseudo Configuration:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> voice class sip uri 100<br></div><div dir="ltr">>>>>>>> host ipv4:10.1.1.1<br></div><div dir="ltr">>>>>>>> !<br></div><div dir="ltr">>>>>>>> dial-peer voice 100 voip<br></div><div dir="ltr">>>>>>>> incoming uri via 100<br></div><div dir="ltr">>>>>>>> bind media interface g0/1<br></div><div dir="ltr">>>>>>>> bind control interface g0/1<br></div><div dir="ltr">>>>>>>> !<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>>> wrote:<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>>> Thanks for prompt answer.<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> No, i am not using CCP.<br></div><div dir="ltr">>>>>>>>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric<br></div><div dir="ltr">>>>>>>>> calling number: *stringhere*<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA<br></div><div dir="ltr">>>>>>>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match<br></div><div dir="ltr">>>>>>>>> incoming dialpeer for Calling number: : *stringhere*<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:<br></div><div dir="ltr">>>>>>>>> input arg error<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match<br></div><div dir="ltr">>>>>>>>> found for P-Called-Party-ID<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:<br></div><div dir="ltr">>>>>>>>> input argument error<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition<br></div><div dir="ltr">>>>>>>>> tag absent in Require/Supported header<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media<br></div><div dir="ltr">>>>>>>>> Antitrombone disabled<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the<br></div><div dir="ltr">>>>>>>>> configured mode as FLOW-THROUGH<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder<br></div><div dir="ltr">>>>>>>>> high-density disabled<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode<br></div><div dir="ltr">>>>>>>>> set to FLOW_THROUGH<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer<br></div><div dir="ltr">>>>>>>>> leg - using RTP Supported Codecs<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 18<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 0<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 8<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 9<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 4<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 2<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 15<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>> Codecs supported by GW 255<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:<br></div><div dir="ltr">>>>>>>>> MF: Not a Forked SIP leg..<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp<br></div><div dir="ltr">>>>>>>>> configure for this leg.<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:<br></div><div dir="ltr">>>>>>>>> peer_callID=0<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> MF: *Dial-peer is absent*..<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state<br></div><div dir="ltr">>>>>>>>> = 0 & New state = -1<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:<br></div><div dir="ltr">>>>>>>>> MF: Anchor leg config reset done...<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> OPTIONS looks like following:<br></div><div dir="ltr">>>>>>>>> OPTIONS sip:domain.name.here:5060 SIP/2.0<br></div><div dir="ltr">>>>>>>>> From: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>>> To: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> I do not have any script in use there, the configuration in pretty<br></div><div dir="ltr">>>>>>>>> basic.<br></div><div dir="ltr">>>>>>>>> What i have found is that second OPTIONS (the one that is<br></div><div dir="ltr">>>>>>>>> left/dropped without OK) also generates following output:<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:<br></div><div dir="ltr">>>>>>>>> Checking Invite Dialog<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:<br></div><div dir="ltr">>>>>>>>> *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>> //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying<br></div><div dir="ltr">>>>>>>>> with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>> //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>>>>>>>> old_from: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>>> old_to: <sip:*stringhere*@domain.name.here>;tag=D7E844-1438<br></div><div dir="ltr">>>>>>>>> new_from: <sip:*stringhere*@domain.name.here>;tag=6c7f09452671<br></div><div dir="ltr">>>>>>>>> new_to: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>>> ....<br></div><div dir="ltr">>>>>>>>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Freeing NULL pointer!<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Could you please point me where i can find some information how to<br></div><div dir="ltr">>>>>>>>> create such dial-peer for OPTIONS or give me a brief example of this<br></div><div dir="ltr">>>>>>>>> configuration please.<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Thanks<br></div><div dir="ltr">>>>>>>>> Maciej.<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">>>>>>>>> napisa?(a):<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Are you using Customer Call Back? Which dial peer is the options<br></div><div dir="ltr">>>>>>>>>> ping hitting? Does that dial peer have the CCB script on it? If so... maybe<br></div><div dir="ltr">>>>>>>>>> make another dial peer for options pings that does not have the script<br></div><div dir="ltr">>>>>>>>>> enabled. This is just a hunch...<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>>>>> wrote:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Hi<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>>>>>>>>>> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only<br></div><div dir="ltr">>>>>>>>>>> to the first OPTIONS packet that is received from the endpoint.<br></div><div dir="ltr">>>>>>>>>>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694907: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694908: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694909: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State<br></div><div dir="ltr">>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694911: *Could not add ccb to<br></div><div dir="ltr">>>>>>>>>>> table*. ccb=0x258D7210<br></div><div dir="ltr">>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694912: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694913: *Resource failure,<br></div><div dir="ltr">>>>>>>>>>> dropping OPTIONS*<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> The true is that Cisco receives quite significant amount of SIP<br></div><div dir="ltr">>>>>>>>>>> OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within<br></div><div dir="ltr">>>>>>>>>>> miliseconds.<br></div><div dir="ltr">>>>>>>>>>> The after-effect i want to achieve is a response for each<br></div><div dir="ltr">>>>>>>>>>> incoming OPTIONS<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Example of a successful response:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625106: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625107: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625108: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State<br></div><div dir="ltr">>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625109: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to<br></div><div dir="ltr">>>>>>>>>>> table. ccb=0x258B1110<br></div><div dir="ltr">>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance<br></div><div dir="ltr">>>>>>>>>>> 1<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625110: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:<br></div><div dir="ltr">>>>>>>>>>> Adding call id 23DA9 to table<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625111: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event:<br></div><div dir="ltr">>>>>>>>>>> ccsip_spi_get_msg_type returned: 3 for event 38<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625112: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created<br></div><div dir="ltr">>>>>>>>>>> msg=0x203FFDA4 with refCount = 1<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625113: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:<br></div><div dir="ltr">>>>>>>>>>> Associated container=0x2673A528 to Options Response<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625114: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:<br></div><div dir="ltr">>>>>>>>>>> sipSPIAppHandleContainerBody len 164<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625115: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:<br></div><div dir="ltr">>>>>>>>>>> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,<br></div><div dir="ltr">>>>>>>>>>> is_req=0, transport=1, switch=0, callBack=0x4F48054<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625116: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP<br></div><div dir="ltr">>>>>>>>>>> extension config:1, check sys cfg:1<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625117: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable<br></div><div dir="ltr">>>>>>>>>>> for sending msg immediately<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625118: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to<br></div><div dir="ltr">>>>>>>>>>> send resp=0x203FFDA4 to default port=5060<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625119: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:<br></div><div dir="ltr">>>>>>>>>>> connection required for raddr:11.11.11.11, rport:5060 with laddr:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625120: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceGetConnectionId: Registering<br></div><div dir="ltr">>>>>>>>>>> gcb=0x258B1110 with connection=0x2426673C context list<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625121: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection<br></div><div dir="ltr">>>>>>>>>>> obtained...sending msg=0x203FFDA4<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625122: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send<br></div><div dir="ltr">>>>>>>>>>> for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for<br></div><div dir="ltr">>>>>>>>>>> UDP<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>> //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Maciej<br></div><div dir="ltr">>>>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/1c3183cf/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/1c3183cf/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 5<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 14:57:21 -0600<br></div><div dir="ltr">From: Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">Cc: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>,<br></div><div dir="ltr"> "<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID: <<a href="mailto:B0B6FDD5-F300-4809-B49F-0A728FF51258@fredf.org" rel="nofollow" target="_blank">B0B6FDD5-F300-4809-B49F-0A728FF51258@fredf.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">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!!!<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">> <br></div><div dir="ltr">> Kent,<br></div><div dir="ltr">> <br></div><div dir="ltr">> I'm not sure why you sent that. The problem is not with sending OPTION Ping, it's with responding to received OPTION Ping.<br></div><div dir="ltr">> <br></div><div dir="ltr">> "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"<br></div><div dir="ltr">> <br></div><div dir="ltr">> But since you brought it up... The default for that command is:<br></div><div dir="ltr">> <br></div><div dir="ltr">> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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"<br></div><div dir="ltr">> <br></div><div dir="ltr">> I see the obvious answer here: it pings less often; however, it's the why which I am interested in.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Thanks for sharing what you do.<br></div><div dir="ltr">> <br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a> <mailto:<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>>> wrote:<br></div><div dir="ltr">> Here is what I use:<br></div><div dir="ltr">> <br></div><div dir="ltr">> voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2<br></div><div dir="ltr">> <br></div><div dir="ltr">> Sh dial-peer voice sum the Keepalive line will show busyout or active.<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">>> On Oct 11, 2018, at 12:36 PM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a> <mailto:<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Nick<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> 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 <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>. 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> Hello<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Do you have an idea how to get around this problem?<br></div><div dir="ltr">>> Have you ever encountered such limitations in the process of processing OPTIONS packages? <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Thanks<br></div><div dir="ltr">>> Maciej.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>> Hello<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Anthony, thanks for the hint, but you were right this is not the core of the issue.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I made some test via sipp with following results<br></div><div dir="ltr">>> 1) <br></div><div dir="ltr">>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>> Result: All OPTIONS were replied<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 2) <br></div><div dir="ltr">>> Test: shortly after completing the above test I made another test: Send 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 3) <br></div><div dir="ltr">>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>> Result: All OPTIONS were replied<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I have similar situation here.<br></div><div dir="ltr">>> The customer we are trying to connect sends several OPTIONS within miliseconds.<br></div><div dir="ltr">>> First OPTIONS is replied properly, but subsequent packets with the same Call-ID and different From-tag dropped.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Is there any solution for this.<br></div><div dir="ltr">>> Our customer is very reluctant to proceed with any changes (another open source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Thanks<br></div><div dir="ltr">>> Maciej.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Anyway, good luck with that test.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Many thanks<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Example Pseudo Configuration:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> voice class sip uri 100<br></div><div dir="ltr">>> host ipv4:10.1.1.1<br></div><div dir="ltr">>> !<br></div><div dir="ltr">>> dial-peer voice 100 voip<br></div><div dir="ltr">>> incoming uri via 100<br></div><div dir="ltr">>> bind media interface g0/1<br></div><div dir="ltr">>> bind control interface g0/1<br></div><div dir="ltr">>> !<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> Thanks for prompt answer.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> No, i am not using CCP.<br></div><div dir="ltr">>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric calling number: stringhere<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA URL:sip:10.10.10.10:5060 <<a href="http://10.10.10.10:5060/" rel="nofollow" target="_blank">http://10.10.10.10:5060/</a>>, Host:100.64.4.31<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match incoming dialpeer for Calling number: : stringhere<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId: <br></div><div dir="ltr">>> input arg error<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match found for P-Called-Party-ID<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo: <br></div><div dir="ltr">>> input argument error<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition tag absent in Require/Supported header<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media Antitrombone disabled<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the configured mode as FLOW-THROUGH<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder high-density disabled<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode set to FLOW_THROUGH<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer leg - using RTP Supported Codecs<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 18<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 0<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 8<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 9<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 4<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 2<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 15<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 255<br></div><div dir="ltr">>> 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..<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp configure for this leg.<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall: peer_callID=0<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config: <br></div><div dir="ltr">>> MF: Dial-peer is absent..<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state = 0 & New state = -1<br></div><div dir="ltr">>> 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...<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config: <br></div><div dir="ltr">>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> OPTIONS looks like following:<br></div><div dir="ltr">>> OPTIONS sip:domain.name.here:5060 <> SIP/2.0<br></div><div dir="ltr">>> From: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">>> To: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I do not have any script in use there, the configuration in pretty basic.<br></div><div dir="ltr">>> What i have found is that second OPTIONS (the one that is left/dropped without OK) also generates following output:<br></div><div dir="ltr">>> Oct 9 17:50:38.070: //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor: Checking Invite Dialog<br></div><div dir="ltr">>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable: *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest: <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>> old_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">>> old_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=D7E844-1438<br></div><div dir="ltr">>> new_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=6c7f09452671<br></div><div dir="ltr">>> new_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">>> ....<br></div><div dir="ltr">>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free: <br></div><div dir="ltr">>> Freeing NULL pointer!<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Thanks<br></div><div dir="ltr">>> Maciej.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a> <mailto:<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>> 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...<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> Hi<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>> 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.<br></div><div dir="ltr">>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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)<br></div><div dir="ltr">>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194: //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>> Oct 9 12:52:06 10.10.10.10 8694911: Could not add ccb to table. ccb=0x258D7210 key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>> 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:<br></div><div dir="ltr">>> Oct 9 12:52:06 10.10.10.10 8694913: Resource failure, dropping OPTIONS<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> The true is that Cisco receives quite significant amount of SIP OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within miliseconds.<br></div><div dir="ltr">>> The after-effect i want to achieve is a response for each incoming OPTIONS<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Example of a successful response:<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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)<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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:<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> 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<br></div><div dir="ltr">>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569: //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Maciej<br></div><div dir="ltr">>> _______________________________________________<br></div><div dir="ltr">>> cisco-voip mailing list<br></div><div dir="ltr">>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">>> _______________________________________________<br></div><div dir="ltr">>> cisco-voip mailing list<br></div><div dir="ltr">>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">>> _______________________________________________<br></div><div dir="ltr">>> cisco-voip mailing list<br></div><div dir="ltr">>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">> <br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/26a22d8c/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/26a22d8c/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 6<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 14:59:30 -0600<br></div><div dir="ltr">From: Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">Cc: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>,<br></div><div dir="ltr"> "<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID: <<a href="mailto:B54D9D13-9174-4719-9AED-52E4C4527538@fredf.org" rel="nofollow" target="_blank">B54D9D13-9174-4719-9AED-52E4C4527538@fredf.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Should also throw out that, one of the carriers, didn?t care about options as long as there was something hitting it. <br></div><div dir="ltr"><br></div><div dir="ltr">> On Oct 11, 2018, at 2:57 PM, Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>> wrote:<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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!!!<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">>> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Kent,<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I'm not sure why you sent that. The problem is not with sending OPTION Ping, it's with responding to received OPTION Ping.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> "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"<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> But since you brought it up... The default for that command is:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> 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"<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> I see the obvious answer here: it pings less often; however, it's the why which I am interested in.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Thanks for sharing what you do.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a> <mailto:<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>>> wrote:<br></div><div dir="ltr">>> Here is what I use:<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Sh dial-peer voice sum the Keepalive line will show busyout or active.<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>> <br></div><div dir="ltr">>>> On Oct 11, 2018, at 12:36 PM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a> <mailto:<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Nick<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> 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 <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>. 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> Hello<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Do you have an idea how to get around this problem?<br></div><div dir="ltr">>>> Have you ever encountered such limitations in the process of processing OPTIONS packages? <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Thanks<br></div><div dir="ltr">>>> Maciej.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>>> Hello<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Anthony, thanks for the hint, but you were right this is not the core of the issue.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> I made some test via sipp with following results<br></div><div dir="ltr">>>> 1) <br></div><div dir="ltr">>>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 2) <br></div><div dir="ltr">>>> Test: shortly after completing the above test I made another test: Send 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 3) <br></div><div dir="ltr">>>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> I have similar situation here.<br></div><div dir="ltr">>>> The customer we are trying to connect sends several OPTIONS within miliseconds.<br></div><div dir="ltr">>>> First OPTIONS is replied properly, but subsequent packets with the same Call-ID and different From-tag dropped.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Is there any solution for this.<br></div><div dir="ltr">>>> Our customer is very reluctant to proceed with any changes (another open source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Thanks<br></div><div dir="ltr">>>> Maciej.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Anyway, good luck with that test.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Many thanks<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a> <mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Example Pseudo Configuration:<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> voice class sip uri 100<br></div><div dir="ltr">>>> host ipv4:10.1.1.1<br></div><div dir="ltr">>>> !<br></div><div dir="ltr">>>> dial-peer voice 100 voip<br></div><div dir="ltr">>>> incoming uri via 100<br></div><div dir="ltr">>>> bind media interface g0/1<br></div><div dir="ltr">>>> bind control interface g0/1<br></div><div dir="ltr">>>> !<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> Thanks for prompt answer.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> No, i am not using CCP.<br></div><div dir="ltr">>>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric calling number: stringhere<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA URL:sip:10.10.10.10:5060 <<a href="http://10.10.10.10:5060/" rel="nofollow" target="_blank">http://10.10.10.10:5060/</a>>, Host:100.64.4.31<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match incoming dialpeer for Calling number: : stringhere<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId: <br></div><div dir="ltr">>>> input arg error<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match found for P-Called-Party-ID<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo: <br></div><div dir="ltr">>>> input argument error<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition tag absent in Require/Supported header<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media Antitrombone disabled<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the configured mode as FLOW-THROUGH<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder high-density disabled<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode set to FLOW_THROUGH<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer leg - using RTP Supported Codecs<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 18<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 0<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 8<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 9<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 4<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 2<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 15<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred Codecs supported by GW 255<br></div><div dir="ltr">>>> 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..<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp configure for this leg.<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall: peer_callID=0<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config: <br></div><div dir="ltr">>>> MF: Dial-peer is absent..<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state = 0 & New state = -1<br></div><div dir="ltr">>>> 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...<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config: <br></div><div dir="ltr">>>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> OPTIONS looks like following:<br></div><div dir="ltr">>>> OPTIONS sip:domain.name.here:5060 <> SIP/2.0<br></div><div dir="ltr">>>> From: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">>>> To: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> I do not have any script in use there, the configuration in pretty basic.<br></div><div dir="ltr">>>> What i have found is that second OPTIONS (the one that is left/dropped without OK) also generates following output:<br></div><div dir="ltr">>>> Oct 9 17:50:38.070: //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor: Checking Invite Dialog<br></div><div dir="ltr">>>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable: *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Oct 9 17:50:38.070: //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest: <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>>> old_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=4a6000292f6a<br></div><div dir="ltr">>>> old_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=D7E844-1438<br></div><div dir="ltr">>>> new_from: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>>;tag=6c7f09452671<br></div><div dir="ltr">>>> new_to: <sip:<a href="mailto:stringhere@domain.name.here" rel="nofollow" target="_blank">stringhere@domain.name.here</a>><br></div><div dir="ltr">>>> ....<br></div><div dir="ltr">>>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free: <br></div><div dir="ltr">>>> Freeing NULL pointer!<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Thanks<br></div><div dir="ltr">>>> Maciej.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a> <mailto:<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>> napisa?(a):<br></div><div dir="ltr">>>> 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...<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a> <mailto:<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>>> wrote:<br></div><div dir="ltr">>>> Hi<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>>> 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.<br></div><div dir="ltr">>>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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)<br></div><div dir="ltr">>>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194: //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>>> Oct 9 12:52:06 10.10.10.10 8694911: Could not add ccb to table. ccb=0x258D7210 key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>>> 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:<br></div><div dir="ltr">>>> Oct 9 12:52:06 10.10.10.10 8694913: Resource failure, dropping OPTIONS<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> The true is that Cisco receives quite significant amount of SIP OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within miliseconds.<br></div><div dir="ltr">>>> The after-effect i want to achieve is a response for each incoming OPTIONS<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Example of a successful response:<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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)<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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:<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569: //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>>> <br></div><div dir="ltr">>>> Maciej<br></div><div dir="ltr">>>> _______________________________________________<br></div><div dir="ltr">>>> cisco-voip mailing list<br></div><div dir="ltr">>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">>>> _______________________________________________<br></div><div dir="ltr">>>> cisco-voip mailing list<br></div><div dir="ltr">>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">>>> _______________________________________________<br></div><div dir="ltr">>>> cisco-voip mailing list<br></div><div dir="ltr">>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip " rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip </a><<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>><br></div><div dir="ltr">>> <br></div><div dir="ltr">> <br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/3e038dfa/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/3e038dfa/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 7<br></div><div dir="ltr">Date: Thu, 11 Oct 2018 16:52:01 -0500<br></div><div dir="ltr">From: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">To: Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>><br></div><div dir="ltr">Cc: Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE<br></div><div dir="ltr"> 3945E - Resource failure, dropping OPTIONS<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CACRCJOhgg1wnjjt=<a href="mailto:WytuAKpTcGX9yD98aEOahAG7tJfRyYCCmg@mail.gmail.com" rel="nofollow" target="_blank">WytuAKpTcGX9yD98aEOahAG7tJfRyYCCmg@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Fair enough. We're not always paid to perform the second O in PPDIOO.<br></div><div dir="ltr">Your answer is better than "I don't know" ;) Again, thanks for sharing<br></div><div dir="ltr">your experiences.<br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Oct 11, 2018 at 3:57 PM Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">> Oh sorry, I didn?t catch that on the receiving part. Well, I probably<br></div><div dir="ltr">> should re-look at some of the commands, but we were one of the first<br></div><div dir="ltr">> adopters of SIP and not all the defaults that exist today, existed back<br></div><div dir="ltr">> then. Some of it got left in cause it works with the carrier. :)<br></div><div dir="ltr">> Some of it was also trial and error with the carrier, and well when it<br></div><div dir="ltr">> starts working sometimes things don?t get revisited?. Hows that for an<br></div><div dir="ltr">> answer!!!<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <<br></div><div dir="ltr">> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> Kent,<br></div><div dir="ltr">><br></div><div dir="ltr">> I'm not sure why you sent that. The problem is not with sending OPTION<br></div><div dir="ltr">> Ping, it's with responding to received OPTION Ping.<br></div><div dir="ltr">><br></div><div dir="ltr">> *"The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only to the<br></div><div dir="ltr">> first OPTIONS packet that is received from the endpoint. The rest of<br></div><div dir="ltr">> OPTIONs are dropped with following debug output"*<br></div><div dir="ltr">><br></div><div dir="ltr">> But since you brought it up... The default for that command is:<br></div><div dir="ltr">><br></div><div dir="ltr">> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5<br></div><div dir="ltr">><br></div><div dir="ltr">> What is your reason for changing it from the default? The rule of thumb<br></div><div dir="ltr">> is "use the defaults, unless you have a reason not to"<br></div><div dir="ltr">><br></div><div dir="ltr">> I see the obvious answer here: it pings less often; however, it's the<br></div><div dir="ltr">> *why* which I am interested in.<br></div><div dir="ltr">><br></div><div dir="ltr">> Thanks for sharing what you do.<br></div><div dir="ltr">><br></div><div dir="ltr">> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts <<a href="mailto:kent@fredf.org" rel="nofollow" target="_blank">kent@fredf.org</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">>> Here is what I use:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Sh dial-peer voice sum the Keepalive line will show busyout or active.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> On Oct 11, 2018, at 12:36 PM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">>> wrote:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> I don?t know what the problem is either. Maybe if you grab ccapi inout<br></div><div dir="ltr">>> debugs at the same time, your voice service voip section (at least, whole<br></div><div dir="ltr">>> config would be better), sh ver, and show run | sec voice. Maybe even do a<br></div><div dir="ltr">>> debug ccsip all if you have the ability to do that and NOT crash your CUBE.<br></div><div dir="ltr">>> Obviously don?t debug ccsip all without thinking about what that will do.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Even with all of that, I?m not sure I?ll have an answer, but I?ll look.<br></div><div dir="ltr">>> I?ve had similar issues with my CUBEs and it was due to binding issues and<br></div><div dir="ltr">>> another time it was a straight up bug and I had to bounce the box (which<br></div><div dir="ltr">>> ?fixed? it). I don?t know why your initial debug was showing ?could not<br></div><div dir="ltr">>> add ccb to table? and I?m not even sure which CCB it?s talking about. My<br></div><div dir="ltr">>> thoughts were that is customer callback? but I?m probably wrong on that one.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Nick<br></div><div dir="ltr">>><br></div><div dir="ltr">>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <<br></div><div dir="ltr">>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">>><br></div><div dir="ltr">>>> I feel obligated to reply, since I chimed in earlier....unfortunately, I<br></div><div dir="ltr">>>> don't have any ideas for you. In fact, I have seen CUBE just ignore<br></div><div dir="ltr">>>> incoming SIP messages before, both OPTIONS and INVITEs alike. Not many<br></div><div dir="ltr">>>> occasions, just a few. I have never gotten resolution on it, it has either<br></div><div dir="ltr">>>> fixed itself, or in one special case, still happens. It's my own, in<br></div><div dir="ltr">>>> fact. It still randomly ignores inbound INVITES from my ITSP. Fixing it,<br></div><div dir="ltr">>>> is on my to-do list, but... The cobbler's children are always the<br></div><div dir="ltr">>>> worst-shod<br></div><div dir="ltr">>>> <<a href="https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv" rel="nofollow" target="_blank">https://english.stackexchange.com/questions/46681/a-saying-indicating-how-some-professionals-dont-apply-their-skills-for-themselv</a>>.<br></div><div dir="ltr">>>> The Calls Per Second on my CUBE is like 1.7, however, there are no other<br></div><div dir="ltr">>>> calls being setup, torn down, sup service, etc, and CUBE still just ignores<br></div><div dir="ltr">>>> its responsibility.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>> wrote:<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>>> Hello<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Do you have an idea how to get around this problem?<br></div><div dir="ltr">>>>> Have you ever encountered such limitations in the process of processing<br></div><div dir="ltr">>>>> OPTIONS packages?<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> Thanks<br></div><div dir="ltr">>>>> Maciej.<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>> ?r., 10 pa? 2018 o 09:13 Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>> napisa?(a):<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>>> Hello<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Anthony, thanks for the hint, but you were right this is not the core<br></div><div dir="ltr">>>>>> of the issue.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> I made some test via sipp with following results<br></div><div dir="ltr">>>>>> 1)<br></div><div dir="ltr">>>>>> Test: Send 15xOPTIONS with the same Call-ID and From-tag<br></div><div dir="ltr">>>>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> 2)<br></div><div dir="ltr">>>>>> Test: shortly after completing the above test I made another test:<br></div><div dir="ltr">>>>>> Send 15xOPTIONS with the same Call-ID as previously but different From-tag.<br></div><div dir="ltr">>>>>> Result: None of the OPTIONS we?re replied.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> 3)<br></div><div dir="ltr">>>>>> Test: Test 2 was re-run after a while<br></div><div dir="ltr">>>>>> Result: All OPTIONS were replied<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> So it seems Cisco records the Call-ID and From-tag somewhere in memory<br></div><div dir="ltr">>>>>> and drops subsequent OPTIONS with the same Call-ID and different From-tag<br></div><div dir="ltr">>>>>> that come from the same endpoint for some time.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> I have similar situation here.<br></div><div dir="ltr">>>>>> The customer we are trying to connect sends several OPTIONS within<br></div><div dir="ltr">>>>>> miliseconds.<br></div><div dir="ltr">>>>>> First OPTIONS is replied properly, but subsequent packets with the<br></div><div dir="ltr">>>>>> same Call-ID and different From-tag dropped.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Is there any solution for this.<br></div><div dir="ltr">>>>>> Our customer is very reluctant to proceed with any changes (another<br></div><div dir="ltr">>>>>> open source SIP proxies replies all the OPTIONS).<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> Thanks<br></div><div dir="ltr">>>>>> Maciej.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> wt., 9 pa? 2018 o 23:45 Anthony Holloway <<br></div><div dir="ltr">>>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>>> I hope you saw that I wrote "Pseudo Config" and don't just try to<br></div><div dir="ltr">>>>>>> copy and paste that. I'm also not very convinced that this is the core of<br></div><div dir="ltr">>>>>>> your issue, but you're more than welcome to give it a try.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> You said the first OPTIONS does respond, so I'm guessing it's not<br></div><div dir="ltr">>>>>>> going to be a binding error. In fact, if it was a binding error, OPTIONS<br></div><div dir="ltr">>>>>>> would still respond, it would just have wrong IP info in the headers.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> Anyway, good luck with that test.<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>> On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>> wrote:<br></div><div dir="ltr">>>>>>><br></div><div dir="ltr">>>>>>>> Thanks, i am about to modify the config to check.<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> Many thanks<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>> wt., 9 pa? 2018 o 20:58 Anthony Holloway <<br></div><div dir="ltr">>>>>>>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> napisa?(a):<br></div><div dir="ltr">>>>>>>><br></div><div dir="ltr">>>>>>>>> OPTIONS does not have to match a dial peer to work. However, if<br></div><div dir="ltr">>>>>>>>> you are going to match a dial peer at all, it would likely be for the<br></div><div dir="ltr">>>>>>>>> express purpose of replying from the correct interface, if you have more<br></div><div dir="ltr">>>>>>>>> than one potential interfaces, and you for some reason cannot bind<br></div><div dir="ltr">>>>>>>>> globally. Thus using the correct bind statement on a dial-peer for OPTIONS<br></div><div dir="ltr">>>>>>>>> reply, would be necessary. In which case, you would need to match an<br></div><div dir="ltr">>>>>>>>> incoming call leg dial peer by the SIP Via header alone, and not, say for<br></div><div dir="ltr">>>>>>>>> example, incoming called number.<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> Example Pseudo Configuration:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> voice class sip uri 100<br></div><div dir="ltr">>>>>>>>> host ipv4:10.1.1.1<br></div><div dir="ltr">>>>>>>>> !<br></div><div dir="ltr">>>>>>>>> dial-peer voice 100 voip<br></div><div dir="ltr">>>>>>>>> incoming uri via 100<br></div><div dir="ltr">>>>>>>>> bind media interface g0/1<br></div><div dir="ltr">>>>>>>>> bind control interface g0/1<br></div><div dir="ltr">>>>>>>>> !<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica <<a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>><br></div><div dir="ltr">>>>>>>>> wrote:<br></div><div dir="ltr">>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Thanks for prompt answer.<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> No, i am not using CCP.<br></div><div dir="ltr">>>>>>>>>> As i see OPTIONS ping does not match with any dialpeer<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric<br></div><div dir="ltr">>>>>>>>>> calling number: *stringhere*<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA<br></div><div dir="ltr">>>>>>>>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match<br></div><div dir="ltr">>>>>>>>>> incoming dialpeer for Calling number: : *stringhere*<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:<br></div><div dir="ltr">>>>>>>>>> input arg error<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match<br></div><div dir="ltr">>>>>>>>>> found for P-Called-Party-ID<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:<br></div><div dir="ltr">>>>>>>>>> input argument error<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition<br></div><div dir="ltr">>>>>>>>>> tag absent in Require/Supported header<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media<br></div><div dir="ltr">>>>>>>>>> Antitrombone disabled<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the<br></div><div dir="ltr">>>>>>>>>> configured mode as FLOW-THROUGH<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder<br></div><div dir="ltr">>>>>>>>>> high-density disabled<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode<br></div><div dir="ltr">>>>>>>>>> set to FLOW_THROUGH<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer<br></div><div dir="ltr">>>>>>>>>> leg - using RTP Supported Codecs<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 18<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 0<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 8<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 9<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 4<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 2<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 15<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred<br></div><div dir="ltr">>>>>>>>>> Codecs supported by GW 255<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:<br></div><div dir="ltr">>>>>>>>>> MF: Not a Forked SIP leg..<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp<br></div><div dir="ltr">>>>>>>>>> configure for this leg.<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:<br></div><div dir="ltr">>>>>>>>>> peer_callID=0<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> MF: *Dial-peer is absent*..<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state<br></div><div dir="ltr">>>>>>>>>> = 0 & New state = -1<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:<br></div><div dir="ltr">>>>>>>>>> MF: Anchor leg config reset done...<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068:<br></div><div dir="ltr">>>>>>>>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> MF:video profile Dial-peer is absent..<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> OPTIONS looks like following:<br></div><div dir="ltr">>>>>>>>>> OPTIONS sip:domain.name.here:5060 SIP/2.0<br></div><div dir="ltr">>>>>>>>>> From: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>>>> To: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> I do not have any script in use there, the configuration in pretty<br></div><div dir="ltr">>>>>>>>>> basic.<br></div><div dir="ltr">>>>>>>>>> What i have found is that second OPTIONS (the one that is<br></div><div dir="ltr">>>>>>>>>> left/dropped without OK) also generates following output:<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:<br></div><div dir="ltr">>>>>>>>>> Checking Invite Dialog<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>>> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:<br></div><div dir="ltr">>>>>>>>>> *****CCB found in UAS Request table. ccb=0x2766B958<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>>> //3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying<br></div><div dir="ltr">>>>>>>>>> with child CCB 0x0 index 0 curr_child 0<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:38.070:<br></div><div dir="ltr">>>>>>>>>> //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL<br></div><div dir="ltr">>>>>>>>>> old_from: <sip:*stringhere*@domain.name.here>;tag=4a6000292f6a<br></div><div dir="ltr">>>>>>>>>> old_to: <sip:*stringhere*@domain.name.here>;tag=D7E844-1438<br></div><div dir="ltr">>>>>>>>>> new_from: <sip:*stringhere*@domain.name.here>;tag=6c7f09452671<br></div><div dir="ltr">>>>>>>>>> new_to: <sip:*stringhere*@domain.name.here><br></div><div dir="ltr">>>>>>>>>> ....<br></div><div dir="ltr">>>>>>>>>> Oct 9 17:50:04.068: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Freeing NULL pointer!<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Could you please point me where i can find some information how to<br></div><div dir="ltr">>>>>>>>>> create such dial-peer for OPTIONS or give me a brief example of this<br></div><div dir="ltr">>>>>>>>>> configuration please.<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> Thanks<br></div><div dir="ltr">>>>>>>>>> Maciej.<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>> wt., 9 pa? 2018 o 16:39 Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" rel="nofollow" target="_blank">nicksbarnett@gmail.com</a>><br></div><div dir="ltr">>>>>>>>>> napisa?(a):<br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> Are you using Customer Call Back? Which dial peer is the options<br></div><div dir="ltr">>>>>>>>>>> ping hitting? Does that dial peer have the CCB script on it? If so... maybe<br></div><div dir="ltr">>>>>>>>>>> make another dial peer for options pings that does not have the script<br></div><div dir="ltr">>>>>>>>>>> enabled. This is just a hunch...<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica <<br></div><div dir="ltr">>>>>>>>>>> <a href="mailto:mbgatherer@gmail.com" rel="nofollow" target="_blank">mbgatherer@gmail.com</a>> wrote:<br></div><div dir="ltr">>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> Hi<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> I have really strange problem with SIP OPTIONS pings.<br></div><div dir="ltr">>>>>>>>>>>> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds<br></div><div dir="ltr">>>>>>>>>>>> only to the first OPTIONS packet that is received from the endpoint.<br></div><div dir="ltr">>>>>>>>>>>> The rest of OPTIONs are dropped with following debug output:<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694907: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694908: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694909: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State<br></div><div dir="ltr">>>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694910: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694911: *Could not add ccb to<br></div><div dir="ltr">>>>>>>>>>>> table*. ccb=0x258D7210<br></div><div dir="ltr">>>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694912: Oct 9 10:55:58.194:<br></div><div dir="ltr">>>>>>>>>>>> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 12:52:06 10.10.10.10 8694913: *Resource failure,<br></div><div dir="ltr">>>>>>>>>>>> dropping OPTIONS*<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> The true is that Cisco receives quite significant amount of SIP<br></div><div dir="ltr">>>>>>>>>>>> OPTIONs from the endpoint in short time, like 10 OPTIONS packeges within<br></div><div dir="ltr">>>>>>>>>>>> miliseconds.<br></div><div dir="ltr">>>>>>>>>>>> The after-effect i want to achieve is a response for each<br></div><div dir="ltr">>>>>>>>>>>> incoming OPTIONS<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> Example of a successful response:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625106: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :<br></div><div dir="ltr">>>>>>>>>>>> SIPSPI_EV_CC_OPTIONS_RESP<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625107: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:<br></div><div dir="ltr">>>>>>>>>>>> ccsip_api_options_ind returned: SIP_SUCCESS<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625108: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State<br></div><div dir="ltr">>>>>>>>>>>> change from (STATE_IDLE, SUBSTATE_NONE) to (SIP_STATE_OPTIONS_WAIT,<br></div><div dir="ltr">>>>>>>>>>>> SUBSTATE_NONE)<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625109: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to<br></div><div dir="ltr">>>>>>>>>>>> table. ccb=0x258B1110<br></div><div dir="ltr">>>>>>>>>>>> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance<br></div><div dir="ltr">>>>>>>>>>>> 1<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625110: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:<br></div><div dir="ltr">>>>>>>>>>>> Adding call id 23DA9 to table<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625111: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event:<br></div><div dir="ltr">>>>>>>>>>>> ccsip_spi_get_msg_type returned: 3 for event 38<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625112: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created<br></div><div dir="ltr">>>>>>>>>>>> msg=0x203FFDA4 with refCount = 1<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625113: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:<br></div><div dir="ltr">>>>>>>>>>>> Associated container=0x2673A528 to Options Response<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625114: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:<br></div><div dir="ltr">>>>>>>>>>>> sipSPIAppHandleContainerBody len 164<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625115: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:<br></div><div dir="ltr">>>>>>>>>>>> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,<br></div><div dir="ltr">>>>>>>>>>>> is_req=0, transport=1, switch=0, callBack=0x4F48054<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625116: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP<br></div><div dir="ltr">>>>>>>>>>>> extension config:1, check sys cfg:1<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625117: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable<br></div><div dir="ltr">>>>>>>>>>>> for sending msg immediately<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625118: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to<br></div><div dir="ltr">>>>>>>>>>>> send resp=0x203FFDA4 to default port=5060<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625119: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:<br></div><div dir="ltr">>>>>>>>>>>> connection required for raddr:11.11.11.11, rport:5060 with laddr:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625120: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceGetConnectionId: Registering<br></div><div dir="ltr">>>>>>>>>>>> gcb=0x258B1110 with connection=0x2426673C context list<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625121: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection<br></div><div dir="ltr">>>>>>>>>>>> obtained...sending msg=0x203FFDA4<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625122: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send<br></div><div dir="ltr">>>>>>>>>>>> for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for<br></div><div dir="ltr">>>>>>>>>>>> UDP<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625123: Oct 9 09:34:28.569:<br></div><div dir="ltr">>>>>>>>>>>> //146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625124: Sent:<br></div><div dir="ltr">>>>>>>>>>>> Oct 9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> Could someone help me with this? I really appreciate your advice.<br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>>> Maciej<br></div><div dir="ltr">>>>>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>>>>><br></div><div dir="ltr">>>>>>>>>>> _______________________________________________<br></div><div dir="ltr">>>>>>>>>> cisco-voip mailing list<br></div><div dir="ltr">>>>>>>>>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>>>>>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>>>>>>>>><br></div><div dir="ltr">>>>>>>>> _______________________________________________<br></div><div dir="ltr">>> cisco-voip mailing list<br></div><div dir="ltr">>> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/ada74916/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181011/ada74916/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 8<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 00:12:03 +0000<br></div><div dir="ltr">From: Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr">To: cisco-voip voyp list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: [cisco-voip] Any Alertus integrations out there? Successful<br></div><div dir="ltr"> or otherwise?<br></div><div dir="ltr">Message-ID: <<a href="mailto:D72F646B-BDC7-4426-AC3B-47E24E1CBF5B@uoguelph.ca" rel="nofollow" target="_blank">D72F646B-BDC7-4426-AC3B-47E24E1CBF5B@uoguelph.ca</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Wondering if anyone out there has attempted or completed an Alertus integration.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Feel free to respond off-line.<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio<br></div><div dir="ltr"><br></div><div dir="ltr">-sent from mobile device-<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0><br></div><div dir="ltr">519-824-4120 Ext. 56354<tel:519-824-4120;56354> | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr">[University of Guelph Cornerstone with Improve Life tagline]<br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/dfb66122/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/dfb66122/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 9<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 01:50:33 +0000<br></div><div dir="ltr">From: "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>><br></div><div dir="ltr">To: Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr">Cc: cisco-voip list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] anonymous proximity issues?<br></div><div dir="ltr">Message-ID: <<a href="mailto:2B433CEA-36CA-407E-975C-78B28DBAB0EF@cisco.com" rel="nofollow" target="_blank">2B433CEA-36CA-407E-975C-78B28DBAB0EF@cisco.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.<br></div><div dir="ltr"><br></div><div dir="ltr">If you want your users to have control over toggling the feature take an example from <a href="https://github.com/CiscoDevNet/roomdevices-macros-samples " rel="nofollow" target="_blank">https://github.com/CiscoDevNet/roomdevices-macros-samples </a>and create a macro that works with in-room-controls to give your users a button to flip the config on/off.<br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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?<br></div><div dir="ltr"><br></div><div dir="ltr">I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<br></div><div dir="ltr">519-824-4120 Ext. 56354 | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr"><image001.png><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/9993b829/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/9993b829/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 10<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 01:55:59 +0000<br></div><div dir="ltr">From: "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>><br></div><div dir="ltr">To: JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>><br></div><div dir="ltr">Cc: Nimloth <<a href="mailto:nimloth@nimloth.pl" rel="nofollow" target="_blank">nimloth@nimloth.pl</a>>, cisco-voip list<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?<br></div><div dir="ltr">Message-ID: <<a href="mailto:49E4DFCD-A978-4CEC-93E1-D54065BA023E@cisco.com" rel="nofollow" target="_blank">49E4DFCD-A978-4CEC-93E1-D54065BA023E@cisco.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">I think this has been covered on this list before but that specific issue is NOT a problem that requires an RMA to resolve.<br></div><div dir="ltr"><br></div><div dir="ltr">It?s an incompatibility of older loads with the PoE injector.<br></div><div dir="ltr"><a href="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" rel="nofollow" target="_blank">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</a><br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 9, 2018, at 3:49 PM, JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a><mailto:<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Nimloth [mailto:<a href="mailto:nimloth@nimloth.pl" rel="nofollow" target="_blank">nimloth@nimloth.pl</a>]<br></div><div dir="ltr">Sent: Tuesday, October 09, 2018 3:40 PM<br></div><div dir="ltr">To: JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a><mailto:<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>>><br></div><div dir="ltr">Cc: cisco-voip voyp list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>>><br></div><div dir="ltr">Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr">________________________________<br></div><div dir="ltr">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.<br></div><div dir="ltr">W dniu 9 pa? 2018, o 20:35, u?ytkownik JASON BURWELL <<a href="mailto:jason.burwell@foundersfcu.com" rel="nofollow" target="_blank">jason.burwell@foundersfcu.com</a><mailto:<a href="mailto:jason.burwell@foundersfcu.com" rel="nofollow" target="_blank">jason.burwell@foundersfcu.com</a>>> napisa?:<br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">________________________________<br></div><div dir="ltr"><br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><<a href="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=" rel="nofollow" target="_blank">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=</a>><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/de392cd0/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/de392cd0/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 11<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 02:32:28 +0000<br></div><div dir="ltr">From: Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr">To: "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>><br></div><div dir="ltr">Cc: cisco-voip list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] anonymous proximity issues?<br></div><div dir="ltr">Message-ID: <<a href="mailto:56B13A6D-E9D3-4E2D-A8C4-A57A9594CFAA@uoguelph.ca" rel="nofollow" target="_blank">56B13A6D-E9D3-4E2D-A8C4-A57A9594CFAA@uoguelph.ca</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">The idea of macros is nice, but not sure it really helps secure the system while they actually want to use it.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">-sent from mobile device-<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0><br></div><div dir="ltr">519-824-4120 Ext. 56354<tel:519-824-4120;56354> | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr">[University of Guelph Cornerstone with Improve Life tagline]<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 11, 2018, at 9:50 PM, Ryan Ratliff (rratliff) <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a><mailto:<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.<br></div><div dir="ltr"><br></div><div dir="ltr">If you want your users to have control over toggling the feature take an example from <a href="https://github.com/CiscoDevNet/roomdevices-macros-samples " rel="nofollow" target="_blank">https://github.com/CiscoDevNet/roomdevices-macros-samples </a>and create a macro that works with in-room-controls to give your users a button to flip the config on/off.<br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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?<br></div><div dir="ltr"><br></div><div dir="ltr">I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<br></div><div dir="ltr">519-824-4120 Ext. 56354 | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr"><image001.png><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b08bb11a/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b08bb11a/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 12<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 02:35:46 +0000<br></div><div dir="ltr">From: Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr">To: "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>><br></div><div dir="ltr">Cc: JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>>, cisco-voip list<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?<br></div><div dir="ltr">Message-ID: <<a href="mailto:D3AADD86-B06B-4E89-9781-9F5BC9569206@uoguelph.ca" rel="nofollow" target="_blank">D3AADD86-B06B-4E89-9781-9F5BC9569206@uoguelph.ca</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">?Good save, wedding singer.? comes to mind.<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks for sharing this.<br></div><div dir="ltr"><br></div><div dir="ltr">-sent from mobile device-<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0><br></div><div dir="ltr">519-824-4120 Ext. 56354<tel:519-824-4120;56354> | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr">[University of Guelph Cornerstone with Improve Life tagline]<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 11, 2018, at 9:56 PM, Ryan Ratliff (rratliff) via cisco-voip <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">I think this has been covered on this list before but that specific issue is NOT a problem that requires an RMA to resolve.<br></div><div dir="ltr"><br></div><div dir="ltr">It?s an incompatibility of older loads with the PoE injector.<br></div><div dir="ltr"><a href="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" rel="nofollow" target="_blank">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</a><br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 9, 2018, at 3:49 PM, JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a><mailto:<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Nimloth [mailto:<a href="mailto:nimloth@nimloth.pl" rel="nofollow" target="_blank">nimloth@nimloth.pl</a>]<br></div><div dir="ltr">Sent: Tuesday, October 09, 2018 3:40 PM<br></div><div dir="ltr">To: JASON BURWELL <<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a><mailto:<a href="mailto:JASON.BURWELL@foundersfcu.com" rel="nofollow" target="_blank">JASON.BURWELL@foundersfcu.com</a>>><br></div><div dir="ltr">Cc: cisco-voip voyp list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>>><br></div><div dir="ltr">Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr">________________________________<br></div><div dir="ltr">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.<br></div><div dir="ltr">W dniu 9 pa? 2018, o 20:35, u?ytkownik JASON BURWELL <<a href="mailto:jason.burwell@foundersfcu.com" rel="nofollow" target="_blank">jason.burwell@foundersfcu.com</a><mailto:<a href="mailto:jason.burwell@foundersfcu.com" rel="nofollow" target="_blank">jason.burwell@foundersfcu.com</a>>> napisa?:<br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">________________________________<br></div><div dir="ltr"><br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><<a href="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=" rel="nofollow" target="_blank">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=</a>><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/bbc3a933/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/bbc3a933/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 13<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 09:56:19 +0000<br></div><div dir="ltr">From: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">To: "<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:B5861604FFBFF545BA7BDD7763E6C3FCBDCFD2EE@CSEXMBOX05.charles-stanley.co.uk" rel="nofollow" target="_blank">B5861604FFBFF545BA7BDD7763E6C3FCBDCFD2EE@CSEXMBOX05.charles-stanley.co.uk</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="us-ascii"<br></div><div dir="ltr"><br></div><div dir="ltr">Morning all,<br></div><div dir="ltr"><br></div><div dir="ltr">I have created a call handler on our unity server for a number range we no longer use.<br></div><div dir="ltr"><br></div><div dir="ltr">Our staff have created an mp4 file, with the desired recording on it which I wish to upload to this call handler.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Could someone tell me what format the file should be in please?<br></div><div dir="ltr"><br></div><div dir="ltr">My unity verison is: Cisco Unity Connection version: 11.5.1.15900-18<br></div><div dir="ltr"><br></div><div dir="ltr">Consider the environment - Think before you print<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL <a href="http://www.charles-stanley.co.uk/contact-us/disclosure/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/contact-us/disclosure/</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/2f953c61/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/2f953c61/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 14<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 10:35:08 +0000<br></div><div dir="ltr">From: Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">To: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">Cc: "<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID: <<a href="mailto:47D92FF7-3037-4E90-A9A0-AD50F08BAF6A@lboro.ac.uk" rel="nofollow" target="_blank">47D92FF7-3037-4E90-A9A0-AD50F08BAF6A@lboro.ac.uk</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On 12 Oct 2018, at 10:56, James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>> wrote:<br></div><div dir="ltr">> <br></div><div dir="ltr">> I have created a call handler on our unity server for a number range we no longer use.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Our staff have created an mp4 file, with the desired recording on it which I wish to upload to this call handler.<br></div><div dir="ltr">> <br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Could someone tell me what format the file should be in please?<br></div><div dir="ltr"><br></div><div dir="ltr">Hi James, I found this article on using the free Audacity tool to convert very helpful:<br></div><div dir="ltr"><br></div><div dir="ltr"><a href="http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html" rel="nofollow" target="_blank">http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html</a><br></div><div dir="ltr"><br></div><div dir="ltr">Long story short, you need a mono, 8-bit, 8kHz, u-law WAV.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr"><a href="https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html" rel="nofollow" target="_blank">https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html</a><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">/-Gary Parker----------------------------------f--\<br></div><div dir="ltr">| Unified Communications Service Manager |<br></div><div dir="ltr">n Loughborough University, IT Services |<br></div><div dir="ltr">| tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a> o<br></div><div dir="ltr">| <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">\r----------------------------------------------d-/<br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">A non-text attachment was scrubbed...<br></div><div dir="ltr">Name: signature.asc<br></div><div dir="ltr">Type: application/pgp-signature<br></div><div dir="ltr">Size: 833 bytes<br></div><div dir="ltr">Desc: Message signed with OpenPGP<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/63c97db5/attachment-0001.sig" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/63c97db5/attachment-0001.sig</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 15<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 12:19:41 +0000<br></div><div dir="ltr">From: "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>><br></div><div dir="ltr">To: Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr">Cc: cisco-voip list <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] anonymous proximity issues?<br></div><div dir="ltr">Message-ID: <<a href="mailto:45EC9ABD-93FB-4644-A686-C889247E45F7@cisco.com" rel="nofollow" target="_blank">45EC9ABD-93FB-4644-A686-C889247E45F7@cisco.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Also, for all of your Proximity questions:<br></div><div dir="ltr"><a href="https://community.cisco.com/t5/mobile-applications-documents/troubleshooting-guide-cisco-proximity/ta-p/3148841#toc-hId--2135534734" rel="nofollow" target="_blank">https://community.cisco.com/t5/mobile-applications-documents/troubleshooting-guide-cisco-proximity/ta-p/3148841#toc-hId--2135534734</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 11, 2018, at 10:32 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">The idea of macros is nice, but not sure it really helps secure the system while they actually want to use it.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">-sent from mobile device-<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<x-apple-data-detectors://1/0><br></div><div dir="ltr">519-824-4120 Ext. 56354<tel:519-824-4120;56354> | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr">[University of Guelph Cornerstone with Improve Life tagline]<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 11, 2018, at 9:50 PM, Ryan Ratliff (rratliff) <<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a><mailto:<a href="mailto:rratliff@cisco.com" rel="nofollow" target="_blank">rratliff@cisco.com</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Users in the room also see a notification on the screen when a proximity client connects, so it?s not hidden.<br></div><div dir="ltr"><br></div><div dir="ltr">If you want your users to have control over toggling the feature take an example from <a href="https://github.com/CiscoDevNet/roomdevices-macros-samples " rel="nofollow" target="_blank">https://github.com/CiscoDevNet/roomdevices-macros-samples </a>and create a macro that works with in-room-controls to give your users a button to flip the config on/off.<br></div><div dir="ltr"><br></div><div dir="ltr">-Ryan<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">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?<br></div><div dir="ltr"><br></div><div dir="ltr">I read somewhere where you can lower the proximity HF volume(?), but that?s like lowering the wifi antenna power to restrict wifi access.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Does anyone know if proximity will be PIN controlled (or anything like this) any time soon?<br></div><div dir="ltr"><br></div><div dir="ltr">Lelio<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">Lelio Fulgenzi, B.A. | Senior Analyst<br></div><div dir="ltr">Computing and Communications Services | University of Guelph<br></div><div dir="ltr">Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1<br></div><div dir="ltr">519-824-4120 Ext. 56354 | <a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a><mailto:<a href="mailto:lelio@uoguelph.ca" rel="nofollow" target="_blank">lelio@uoguelph.ca</a>><br></div><div dir="ltr"><br></div><div dir="ltr">www.uoguelph.ca/ccs<<a href="http://www.uoguelph.ca/ccs" rel="nofollow" target="_blank">http://www.uoguelph.ca/ccs</a>> | @UofGCCS on Instagram, Twitter and Facebook<br></div><div dir="ltr"><br></div><div dir="ltr"><image001.png><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/fe76b853/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/fe76b853/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 16<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 08:43:11 -0500<br></div><div dir="ltr">From: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">To: Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">Cc: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CACRCJOi5YGQ2T7+the0Bok5Cv6DyN-N9eC=<a href="mailto:fE-QDUMzb0NNtyw@mail.gmail.com" rel="nofollow" target="_blank">fE-QDUMzb0NNtyw@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">In addition to Audacity, which I use myself, try this site out:<br></div><div dir="ltr"><a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 5:35 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> > On 12 Oct 2018, at 10:56, James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">> wrote:<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > I have created a call handler on our unity server for a number range we<br></div><div dir="ltr">> no longer use.<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > Our staff have created an mp4 file, with the desired recording on it<br></div><div dir="ltr">> which I wish to upload to this call handler.<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > I?ve converted the file to both .mp3 and .wav, however when I upload the<br></div><div dir="ltr">> file I get an error message stating the format is oncorrect.<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > Could someone tell me what format the file should be in please?<br></div><div dir="ltr">><br></div><div dir="ltr">> Hi James, I found this article on using the free Audacity tool to convert<br></div><div dir="ltr">> very helpful:<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> <a href="http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html" rel="nofollow" target="_blank">http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html</a><br></div><div dir="ltr">><br></div><div dir="ltr">> Long story short, you need a mono, 8-bit, 8kHz, u-law WAV.<br></div><div dir="ltr">><br></div><div dir="ltr">> However, use Audiotext Manager and it does all the heavy lifting for you.<br></div><div dir="ltr">> Just drop any old wav file or MP3 and it converts it as it uploads.<br></div><div dir="ltr">> Definitely my recommended solution.<br></div><div dir="ltr">><br></div><div dir="ltr">> <a href="https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html" rel="nofollow" target="_blank">https://www.ciscounitytools.com/Applications/CxN/ATM/ATM.html</a><br></div><div dir="ltr">><br></div><div dir="ltr">> ---<br></div><div dir="ltr">> /-Gary Parker----------------------------------f--\<br></div><div dir="ltr">> | Unified Communications Service Manager |<br></div><div dir="ltr">> n Loughborough University, IT Services |<br></div><div dir="ltr">> | tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a> o<br></div><div dir="ltr">> | <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">> \r----------------------------------------------d-/<br></div><div dir="ltr">><br></div><div dir="ltr">> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b09599c2/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b09599c2/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 17<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 13:50:46 +0000<br></div><div dir="ltr">From: Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">Cc: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID: <<a href="mailto:C8163CCA-9FA2-4C12-876A-88C14B3C9EBF@lboro.ac.uk" rel="nofollow" target="_blank">C8163CCA-9FA2-4C12-876A-88C14B3C9EBF@lboro.ac.uk</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">> <br></div><div dir="ltr">> In addition to Audacity, which I use myself, try this site out: <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr"><br></div><div dir="ltr">Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">/-Gary Parker----------------------------------f--\<br></div><div dir="ltr">| Unified Communications Service Manager |<br></div><div dir="ltr">n Loughborough University, IT Services |<br></div><div dir="ltr">| tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a> o<br></div><div dir="ltr">| <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">\r----------------------------------------------d-/<br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">A non-text attachment was scrubbed...<br></div><div dir="ltr">Name: signature.asc<br></div><div dir="ltr">Type: application/pgp-signature<br></div><div dir="ltr">Size: 833 bytes<br></div><div dir="ltr">Desc: Message signed with OpenPGP<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/5ee6c368/attachment-0001.sig" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/5ee6c368/attachment-0001.sig</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 18<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 08:53:23 -0500<br></div><div dir="ltr">From: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">To: Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">Cc: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CACRCJOiNrLQcGo=iHqDEHLqfgfUVN0DSY_=<a href="mailto:9DVvFFck2vngi9w@mail.gmail.com" rel="nofollow" target="_blank">9DVvFFck2vngi9w@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">I agree. How awesome would it be if it did the conversion purely client<br></div><div dir="ltr">side?<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> > On 12 Oct 2018, at 14:43, Anthony Holloway <<br></div><div dir="ltr">> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > In addition to Audacity, which I use myself, try this site out:<br></div><div dir="ltr">> <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr">><br></div><div dir="ltr">> Neat idea, and well implemented, but obviously please be wary of sending<br></div><div dir="ltr">> your data to someone else?s site!<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> ---<br></div><div dir="ltr">> /-Gary Parker----------------------------------f--\<br></div><div dir="ltr">> | Unified Communications Service Manager |<br></div><div dir="ltr">> n Loughborough University, IT Services |<br></div><div dir="ltr">> | tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a> o<br></div><div dir="ltr">> | <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">> \r----------------------------------------------d-/<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b293f61e/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/b293f61e/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 19<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 14:06:10 +0000<br></div><div dir="ltr">From: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>>, Gary Parker<br></div><div dir="ltr"> <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">Cc: Cisco VoIP Group <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:B5861604FFBFF545BA7BDD7763E6C3FCBDCFEC26@CSEXMBOX05.charles-stanley.co.uk" rel="nofollow" target="_blank">B5861604FFBFF545BA7BDD7763E6C3FCBDCFEC26@CSEXMBOX05.charles-stanley.co.uk</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks very much for your help gents ? this is working for me now,<br></div><div dir="ltr"><br></div><div dir="ltr">One final thing, when I make a call I receive ?sorry? before the message plays.<br></div><div dir="ltr"><br></div><div dir="ltr">Is there a way to remove this system default?<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Anthony Holloway [mailto:avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>]<br></div><div dir="ltr">Sent: 12 October 2018 14:53<br></div><div dir="ltr">To: Gary Parker<br></div><div dir="ltr">Cc: James Dust; Cisco VoIP Group<br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr"><br></div><div dir="ltr">I agree. How awesome would it be if it did the conversion purely client side?<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a><mailto:<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a><mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> In addition to Audacity, which I use myself, try this site out: <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr"><br></div><div dir="ltr">Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">/-Gary Parker----------------------------------f--\<br></div><div dir="ltr">| Unified Communications Service Manager |<br></div><div dir="ltr">n Loughborough University, IT Services |<br></div><div dir="ltr">| tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a><mailto:sip%<a href="mailto:3Agary@lboro.ac.uk" rel="nofollow" target="_blank">3Agary@lboro.ac.uk</a>> o<br></div><div dir="ltr">| <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">\r----------------------------------------------d-/<br></div><div dir="ltr"><br></div><div dir="ltr">Consider the environment - Think before you print<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL <a href="http://www.charles-stanley.co.uk/contact-us/disclosure/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/contact-us/disclosure/</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/c7cbc63f/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/c7cbc63f/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 20<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 09:07:31 -0500<br></div><div dir="ltr">From: Bill Talley <<a href="mailto:btalley@gmail.com" rel="nofollow" target="_blank">btalley@gmail.com</a>><br></div><div dir="ltr">To: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>><br></div><div dir="ltr">Cc: <a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CAM+<a href="mailto:6AtDDQKs0pFzeJoexmvoTOUBGJ9jqYzaWTyrup6PDb3OgDg@mail.gmail.com" rel="nofollow" target="_blank">6AtDDQKs0pFzeJoexmvoTOUBGJ9jqYzaWTyrup6PDb3OgDg@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">(replying all this time doh)<br></div><div dir="ltr"><br></div><div dir="ltr">Client side, as in using the built-in afconvert command in Mac OSX?<br></div><div dir="ltr"><br></div><div dir="ltr">If you have a MacBook, keep reading, otherwise this may not interest you.<br></div><div dir="ltr">In addition to creating temporary prompt files from the command line on<br></div><div dir="ltr">your Mac, you can also convert incompatible prompt files quickly and easily<br></div><div dir="ltr">from the command line with the following command.<br></div><div dir="ltr"><br></div><div dir="ltr">afconvert -d ?<a href="mailto:ulaw@8000" rel="nofollow" target="_blank">ulaw@8000</a>? -f ?WAVE? {source file name} {destination file<br></div><div dir="ltr">name}<br></div><div dir="ltr"><br></div><div dir="ltr">For example, to convert HelpDesk.mp3 to the compatible uLaw format, the<br></div><div dir="ltr">following command would be executed from the directory containing<br></div><div dir="ltr">HelpDesk.mp3.<br></div><div dir="ltr">afconvert -d ?<a href="mailto:ulaw@8000" rel="nofollow" target="_blank">ulaw@8000</a>? -f ?WAVE? HelpDesk.mp3 HelpDesk.wav<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 8:54 AM Anthony Holloway <<br></div><div dir="ltr">avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">> I agree. How awesome would it be if it did the conversion purely client<br></div><div dir="ltr">> side?<br></div><div dir="ltr">><br></div><div dir="ltr">> On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>><br></div><div dir="ltr">> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> > On 12 Oct 2018, at 14:43, Anthony Holloway <<br></div><div dir="ltr">>> avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>> wrote:<br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > In addition to Audacity, which I use myself, try this site out:<br></div><div dir="ltr">>> <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Neat idea, and well implemented, but obviously please be wary of sending<br></div><div dir="ltr">>> your data to someone else?s site!<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> ---<br></div><div dir="ltr">>> /-Gary Parker----------------------------------f--\<br></div><div dir="ltr">>> | Unified Communications Service Manager |<br></div><div dir="ltr">>> n Loughborough University, IT Services |<br></div><div dir="ltr">>> | tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a> o<br></div><div dir="ltr">>> | <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">>> \r----------------------------------------------d-/<br></div><div dir="ltr">>><br></div><div dir="ltr">>> _______________________________________________<br></div><div dir="ltr">> cisco-voip mailing list<br></div><div dir="ltr">> <a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr">> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/9c096da5/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/9c096da5/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 21<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 14:29:51 +0000<br></div><div dir="ltr">From: Myron Young <<a href="mailto:mdavid_young@hotmail.com" rel="nofollow" target="_blank">mdavid_young@hotmail.com</a>><br></div><div dir="ltr">To: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">Cc: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>>, Gary Parker<br></div><div dir="ltr"> <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:SN1PR12MB0189BC1722CC248A12ABBBE8E9E20@SN1PR12MB0189.namprd12.prod.outlook.com" rel="nofollow" target="_blank">SN1PR12MB0189BC1722CC248A12ABBBE8E9E20@SN1PR12MB0189.namprd12.prod.outlook.com</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Hey James,<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">Sent from my iPhone<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 12, 2018, at 8:06 AM, James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a><mailto:<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks very much for your help gents ? this is working for me now,<br></div><div dir="ltr"><br></div><div dir="ltr">One final thing, when I make a call I receive ?sorry? before the message plays.<br></div><div dir="ltr"><br></div><div dir="ltr">Is there a way to remove this system default?<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Anthony Holloway [mailto:avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>]<br></div><div dir="ltr">Sent: 12 October 2018 14:53<br></div><div dir="ltr">To: Gary Parker<br></div><div dir="ltr">Cc: James Dust; Cisco VoIP Group<br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr"><br></div><div dir="ltr">I agree. How awesome would it be if it did the conversion purely client side?<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a><mailto:<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a><mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> In addition to Audacity, which I use myself, try this site out: <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr"><br></div><div dir="ltr">Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">/-Gary Parker----------------------------------f--\<br></div><div dir="ltr">| Unified Communications Service Manager |<br></div><div dir="ltr">n Loughborough University, IT Services |<br></div><div dir="ltr">| tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a><mailto:sip%<a href="mailto:3Agary@lboro.ac.uk" rel="nofollow" target="_blank">3Agary@lboro.ac.uk</a>> o<br></div><div dir="ltr">| <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">\r----------------------------------------------d-/<br></div><div dir="ltr"><br></div><div dir="ltr">Consider the environment - Think before you print<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL <a href="http://www.charles-stanley.co.uk/contact-us/disclosure/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/contact-us/disclosure/</a><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/beb37e79/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/beb37e79/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 22<br></div><div dir="ltr">Date: Fri, 12 Oct 2018 14:52:47 +0000<br></div><div dir="ltr">From: James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>><br></div><div dir="ltr">To: Myron Young <<a href="mailto:mdavid_young@hotmail.com" rel="nofollow" target="_blank">mdavid_young@hotmail.com</a>><br></div><div dir="ltr">Cc: Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>>, Gary Parker<br></div><div dir="ltr"> <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>>, Cisco VoIP Group<br></div><div dir="ltr"> <<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:B5861604FFBFF545BA7BDD7763E6C3FCBDCFEE6D@CSEXMBOX05.charles-stanley.co.uk" rel="nofollow" target="_blank">B5861604FFBFF545BA7BDD7763E6C3FCBDCFEE6D@CSEXMBOX05.charles-stanley.co.uk</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Thank you for your help,<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Kind Regards<br></div><div dir="ltr"><br></div><div dir="ltr">James Dust<br></div><div dir="ltr">ICT Network Infrastructure & Communications Engineer<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">[cid:<a href="mailto:image005.png@01D17638.0229E040" rel="nofollow" target="_blank">image005.png@01D17638.0229E040</a>]<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">55 Bishopsgate, London EC2N 3AS<br></div><div dir="ltr"><br></div><div dir="ltr">Telephone: 020 7149 6314<br></div><div dir="ltr">Website<<a href="http://www.charles-stanley.co.uk/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/</a>> | LinkedIn<<a href="https://www.linkedin.com/company/charles-stanley" rel="nofollow" target="_blank">https://www.linkedin.com/company/charles-stanley</a>> | Twitter<<a href="https://twitter.com/_CharlesStanley" rel="nofollow" target="_blank">https://twitter.com/_CharlesStanley</a>><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Myron Young [mailto:<a href="mailto:mdavid_young@hotmail.com" rel="nofollow" target="_blank">mdavid_young@hotmail.com</a>]<br></div><div dir="ltr">Sent: 12 October 2018 15:30<br></div><div dir="ltr">To: James Dust<br></div><div dir="ltr">Cc: Anthony Holloway; Gary Parker; Cisco VoIP Group<br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr"><br></div><div dir="ltr">Hey James,<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr">Sent from my iPhone<br></div><div dir="ltr"><br></div><div dir="ltr">On Oct 12, 2018, at 8:06 AM, James Dust <<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a><mailto:<a href="mailto:james.dust@charles-stanley.co.uk" rel="nofollow" target="_blank">james.dust@charles-stanley.co.uk</a>>> wrote:<br></div><div dir="ltr">Thanks very much for your help gents ? this is working for me now,<br></div><div dir="ltr"><br></div><div dir="ltr">One final thing, when I make a call I receive ?sorry? before the message plays.<br></div><div dir="ltr"><br></div><div dir="ltr">Is there a way to remove this system default?<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">From: Anthony Holloway [mailto:avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a>]<br></div><div dir="ltr">Sent: 12 October 2018 14:53<br></div><div dir="ltr">To: Gary Parker<br></div><div dir="ltr">Cc: James Dust; Cisco VoIP Group<br></div><div dir="ltr">Subject: Re: [cisco-voip] Unity Call Handler recording upload<br></div><div dir="ltr"><br></div><div dir="ltr">I agree. How awesome would it be if it did the conversion purely client side?<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri, Oct 12, 2018 at 8:51 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a><mailto:<a href="mailto:G.J.Parker@lboro.ac.uk" rel="nofollow" target="_blank">G.J.Parker@lboro.ac.uk</a>>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> On 12 Oct 2018, at 14:43, Anthony Holloway <avholloway+<a href="mailto:cisco-voip@gmail.com" rel="nofollow" target="_blank">cisco-voip@gmail.com</a><mailto:avholloway%<a href="mailto:2Bcisco-voip@gmail.com" rel="nofollow" target="_blank">2Bcisco-voip@gmail.com</a>>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> In addition to Audacity, which I use myself, try this site out: <a href="http://g711.org/" rel="nofollow" target="_blank">http://g711.org/</a><br></div><div dir="ltr"><br></div><div dir="ltr">Neat idea, and well implemented, but obviously please be wary of sending your data to someone else?s site!<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">---<br></div><div dir="ltr">/-Gary Parker----------------------------------f--\<br></div><div dir="ltr">| Unified Communications Service Manager |<br></div><div dir="ltr">n Loughborough University, IT Services |<br></div><div dir="ltr">| tel:+441509635635 sip:<a href="mailto:gary@lboro.ac.uk" rel="nofollow" target="_blank">gary@lboro.ac.uk</a><mailto:sip%<a href="mailto:3Agary@lboro.ac.uk" rel="nofollow" target="_blank">3Agary@lboro.ac.uk</a>> o<br></div><div dir="ltr">| <a href="https://www.osx.ninja/pubkey.txt " rel="nofollow" target="_blank">https://www.osx.ninja/pubkey.txt </a> |<br></div><div dir="ltr">\r----------------------------------------------d-/<br></div><div dir="ltr"><br></div><div dir="ltr">Consider the environment - Think before you print<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL <a href="http://www.charles-stanley.co.uk/contact-us/disclosure/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/contact-us/disclosure/</a><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><mailto:<a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a>><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr">Consider the environment - Think before you print<br></div><div dir="ltr"><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br></div><div dir="ltr">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).<br></div><div dir="ltr"><br></div><div dir="ltr">Details of Charles Stanley group companies and their regulators (where applicable), can be found at this URL <a href="http://www.charles-stanley.co.uk/contact-us/disclosure/" rel="nofollow" target="_blank">http://www.charles-stanley.co.uk/contact-us/disclosure/</a><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.html" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.html</a>><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">A non-text attachment was scrubbed...<br></div><div dir="ltr">Name: image001.png<br></div><div dir="ltr">Type: image/png<br></div><div dir="ltr">Size: 6097 bytes<br></div><div dir="ltr">Desc: image001.png<br></div><div dir="ltr">URL: <<a href="https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.png" rel="nofollow" target="_blank">https://puck.nether.net/pipermail/cisco-voip/attachments/20181012/f239d18d/attachment-0001.png</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Subject: Digest Footer<br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">cisco-voip mailing list<br></div><div dir="ltr"><a href="mailto:cisco-voip@puck.nether.net" rel="nofollow" target="_blank">cisco-voip@puck.nether.net</a><br></div><div dir="ltr"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="nofollow" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">End of cisco-voip Digest, Vol 180, Issue 11<br></div><div dir="ltr">*******************************************<br></div></div>
</div>
</div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank" style="color: #4453ea;">www.avg.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div></body></html>