Remember to have all the cucm ips on your cube\sbc if your using security there or you will have new issues to track down
Kent > On Mar 21, 2018, at 12:05, Ryan Huff <[email protected]> wrote: > > Correct, that is how I understand CMG to work too and yes, very likely a bug > or a reset that didn’t apply (or was needed) ... etc. > > Sent from my iPhone > > On Mar 21, 2018, at 14:00, Anthony Holloway <[email protected]> > wrote: > >> "Run on all nodes" does two things for you: >> >> 1) It creates an instance of that object on all CPEs, such that any one of >> them can answer the request, or generate a request. >> >> 2) It causes a thing to happen called, route local, which attempts to keep >> outbound requests on the same CPE where the inbound request was seen. This >> is to alleviate ICCS traffic by involving multiple CPEs in a single call >> flow where not necessary. >> >> If you've seen behavior where "run on all nodes" has caused you to adjust >> your CMG, then I suspect it was either not working (E.g., A reset of the >> device did not work), or you were hitting a defect. >> >>> On Wed, Mar 21, 2018 at 12:52 PM Ryan Huff <[email protected]> wrote: >>> This comes from empirical experience here but I have most definitely hit >>> odd issues with “Run on all CM nodes” and the originator not being in the >>> CMG of the SIP trunk. >>> >>> Sent from my iPhone >>> >>> On Mar 21, 2018, at 13:43, Anthony Holloway >>> <[email protected]> wrote: >>> >>>> Typo? If its enabled, then CMG doesn't matter. >>>> >>>>> On Wed, Mar 21, 2018 at 12:30 PM Ryan Huff <[email protected]> wrote: >>>>> >>>>> Do you have “Run on all nodes” checked on the CUCM trunk? If so, please >>>>> verify all CM nodes running the call manager service are in the CM Group >>>>> specified in the device pool bring used by the CUCM sip trunk. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Mar 21, 2018, at 13:24, Ryan Huff <[email protected]> wrote: >>>>> >>>>>> Looks like your DTMF methods are changing between the good and bad calls >>>>>> and possibly why Century is disregarding? >>>>>> >>>>>> Also seems like the ccm originator is different in the good and bad SDP. >>>>>> >>>>>> “Every fifth time” seems to predictable to be a random issue; seems more >>>>>> like CUCM cycling through a list or something >>>>>> >>>>>> Do you have “Run on all nodes” checked on the CUCM trunk? If so, please >>>>>> verify all CM nodes running the call manager service are in the CM Group >>>>>> specified in the device pool used by the CUCM. >>>>>> >>>>>> Are you having the issue in both directions? >>>>>> >>>>>> What DTMF method do you have set on the CUCM trunk, “No Preference”? >>>>>> >>>>>> What version of CUCM? >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Mar 21, 2018, at 12:37, Jonatan Quezada >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mon, Mar 19, 2018 at 8:33 AM, Jonatan Quezada >>>>>>>> <[email protected]> wrote: >>>>>>>> What would change this this packet 20 percent of the time? We are >>>>>>>> trouble shooting the last ghost issue after SIP cutover. I was on the >>>>>>>> horn with the provider and CiscoTAC and we see this for good and bad >>>>>>>> calls: any reason why centuryLink's stuff would not recognize this >>>>>>>> update from us, or possibly the (Cube,CUCM) sending last wierd packet >>>>>>>> of update one in five times which causes the call to drop >>>>>>>> >>>>>>>> Bad calls the last invite has m=audio 20674 RTP/AVP 0 >>>>>>>> a=X-cisco-media:umoh a=ptime:20 >>>>>>>> a=rtpmap:0 PCMU/8000 and no RTP from the cusotmer PBX >>>>>>>> >>>>>>>> and good calls has m=audio 20650 RTP/AVP 0 101 a=ptime:20 a=rtpmap:0 >>>>>>>> PCMU/8000 and good RTP from the PBX >>>>>>>> >>>>>>>> >>>>>>>> Last invite on good call from the customer >>>>>>>> >>>>>>>> INVITE sip:[email protected]:5100;transport=udp SIP/2.0 >>>>>>>> Via: SIP/2.0/UDP 65.152.176.94:5060;branch=z9hG4bK43843FB >>>>>>>> P-Asserted-Identity: "3300 CCBI Mailbox" >>>>>>>> From: "5033995181 5033995181";tag=6F13621-138F >>>>>>>> To: "STEVEN UPCHURCH";tag=1960181175-1521299570039 >>>>>>>> - >>>>>>>> Date: Sat, 17 Mar 2018 08:13:17 PST >>>>>>>> Call-ID: [email protected] >>>>>>>> Supported: rel100,timer,resource-priority,replaces,sdp-anat >>>>>>>> Min-SE: 1800 >>>>>>>> Cisco-Guid: 2155609728-0690754024-2718484947-3801912337 >>>>>>>> User-Agent: Cisco-SIPGateway/IOS-15.5.3.S6b >>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, >>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER >>>>>>>> CSeq: 108 INVITE >>>>>>>> Max-Forwards: 70 >>>>>>>> Timestamp: 1521299597 >>>>>>>> Contact: >>>>>>>> Expires: 300 >>>>>>>> Allow-Events: telephone-event >>>>>>>> Authorization: Digest >>>>>>>> username="263015-9717185172",realm="voip.centurylink.com",uri="sip:303319179 >>>>>>>> [email protected]:5100;transport=udp",response="1fe4a6632f960305157b16ff3dd05944",nonce="BroadWorksXje >>>>>>>> vihnztT47s3bhBW",cnonce="FFFFFFFF",qop=auth,algorithm=MD5,nc=00000007 >>>>>>>> Session-Expires: 1800;refresher=uac >>>>>>>> Content-Type: application/sdp >>>>>>>> Content-Length: 247 >>>>>>>> v=0 >>>>>>>> o=CiscoSystemsCCM-SIP 2058187 5 IN IP4 10.200.1.11 >>>>>>>> s=SIP Call >>>>>>>> c=IN IP4 OurEndOf SIpTrunk >>>>>>>> b=TIAS:64000 >>>>>>>> b=CT:64 >>>>>>>> b=AS:64 >>>>>>>> t=0 0 >>>>>>>> m=audio 20650 RTP/AVP 0 101 >>>>>>>> a=ptime:20 >>>>>>>> a=rtpmap:0 PCMU/8000 >>>>>>>> a=rtpmap:101 telephone-event/8000 >>>>>>>> a=fmtp:101 0-15 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bad call >>>>>>>> >>>>>>>> >>>>>>>> INVITE sip:[email protected]:5100;transport=udp SIP/2.0 >>>>>>>> Via: SIP/2.0/UDP 65.152.176.94:5060;branch=z9hG4bK43B6CCD >>>>>>>> P-Asserted-Identity: "3300 CCBI Mailbox" >>>>>>>> From: "5033995181 5033995181";tag=706CB6F-176F >>>>>>>> To: "STEVEN UPCHURCH";tag=790178935-1521300984448- >>>>>>>> Date: Sat, 17 Mar 2018 08:36:48 PST >>>>>>>> Call-ID: [email protected] >>>>>>>> Supported: rel100,timer,resource-priority,replaces,sdp-anat >>>>>>>> Min-SE: 1800 >>>>>>>> Cisco-Guid: 3415568030-0690950632-2724317651-3801912337 >>>>>>>> User-Agent: Cisco-SIPGateway/IOS-15.5.3.S6b >>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, >>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER >>>>>>>> CSeq: 106 INVITE >>>>>>>> Max-Forwards: 70 >>>>>>>> Timestamp: 1521301008 >>>>>>>> Contact: >>>>>>>> Expires: 300 >>>>>>>> Allow-Events: telephone-event >>>>>>>> Authorization: Digest >>>>>>>> username="sipUserCreds",realm="voip.centurylink.com",uri="sip:303319179 >>>>>>>> [email protected]:5100;transport=udp",response="afdfcac6b618eca813909e53f7a6ed2e",nonce="BroadWorksXje >>>>>>>> vjbx40Tz7f6gcBW",cnonce="FFFFFFFF",qop=auth,algorithm=MD5,nc=00000005 >>>>>>>> Content-Type: application/sdp >>>>>>>> Content-Length: 181 >>>>>>>> v=0 >>>>>>>> o=CiscoSystemsCCM-SIP 2060501 3 IN IP4 Subscriber >>>>>>>> s=SIP Call >>>>>>>> c=IN IP4 OurEndOf SIpTrunk >>>>>>>> t=0 0 >>>>>>>> m=audio 20674 RTP/AVP 0 >>>>>>>> a=X-cisco-media:umoh >>>>>>>> a=ptime:20 >>>>>>>> a=rtpmap:0 PCMU/8000 >>>>>>>> >>>>>>>> >>>>>>>> <image.png> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> cisco-voip mailing list >>>>>>> [email protected] >>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>> _______________________________________________ >>>>>> cisco-voip mailing list >>>>>> [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>> _______________________________________________ >>>>> cisco-voip mailing list >>>>> [email protected] >>>>> https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
