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