[cisco-voip] CUCM and cube sending weird packets?

Lelio Fulgenzi lelio at uoguelph.ca
Thu Mar 22 00:05:35 EDT 2018


That's exactly it, both of these are required to go from sg3 to G3.

Without this, sg3 is negotiated and faxes fail.

Unfortunately, we haven't had an opportunity to revisit things, so we've just continued as is.

We also had old equipment when we first deployed, and still have vg248s around.

I was really hoping that there was eventually going to be sg3 support in iOS 15, but there was always gotchas.

This brings back memories from when I found out, from this list, that "passthrough" and "pass-through" meant different things.

Sent from my iPhone

On Mar 21, 2018, at 11:04 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

I'm actually confused why setting the fax machine to 14400 helps, considering G3 speeds are capped at 14400.  Unless this is disabling SG3 speeds, which newer cisco gateways have sg3-to-g3 enabled.

On Wed, Mar 21, 2018 at 10:00 PM Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:

I second this magic bullet. Although we're using PRI.

Turning ecm off and 14400.

Problem is, with some of the mfps out there, you have to go into a special mode on startup by holding down keys while powering up. Once in, entering special key sequences to select 14400.

ECM can be turned off by a menu. Go figure.



Sent from my iPhone

On Mar 21, 2018, at 5:41 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

The magic bullet for faxing over sip with Cisco equip, for me, has always been to disable ECM on the fax machine (or through cube) and set the TX rate of the device to 1400 baud.

Sent from my iPhone

On Mar 21, 2018, at 17:35, Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> wrote:

thank you all for th einsight, I do have MTP checked on trunk , and run on  all CM nodes is checked as well.

The main issue anymore is with the Faxes now. the behavior of the calls is almost night and day in the fixed direction. Fax now is where my focus lies now. any thoughts?

On Wed, Mar 21, 2018 at 2:27 PM, Kent Roberts <kent at fredf.org<mailto:kent at fredf.org>> wrote:
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 <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> 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 <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> 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 <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> 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 <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

Typo? If its enabled, then CMG doesn't matter.

On Wed, Mar 21, 2018 at 12:30 PM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> 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 <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> 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 <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> wrote:



On Mon, Mar 19, 2018 at 8:33 AM, Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> 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:3033191795<tel:(303)%20319-1795>@67.14.92.87<http://67.14.92.87>: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<tel:(503)%20399-5181> 5033995181<tel:(503)%20399-5181>";tag=6F13621-138F
To: "STEVEN UPCHURCH";tag=1960181175-1521299570039
-
Date: Sat, 17 Mar 2018 08:13:17 PST
Call-ID: BW101250039170318-1114511220 at 10.73.16.89<mailto:BW101250039170318-1114511220 at 10.73.16.89>
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<http://voip.centurylink.com/>",uri="sip:303319179
5 at 67.14.92.87<mailto:5 at 67.14.92.87>: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:3033191795<tel:(303)%20319-1795>@67.14.92.84<http://67.14.92.84>: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<tel:(503)%20399-5181> 5033995181<tel:(503)%20399-5181>";tag=706CB6F-176F
To: "STEVEN UPCHURCH";tag=790178935-1521300984448-
Date: Sat, 17 Mar 2018 08:36:48 PST
Call-ID: BW103624448170318-1333973217 at 10.73.16.89<mailto:BW103624448170318-1333973217 at 10.73.16.89>
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<http://voip.centurylink.com/>",uri="sip:303319179
5 at x.x.x.x<mailto:5 at x.x.x.x>: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
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



--
For immediate assistance please reach out to Chemeketa IT Help Desk at 5033997899<tel:(503)%20399-7899>
-or-
Visit the help center from your employee dashboard found here:
https://dashboard.chemeketa.edu/helpcenter/default.aspx


Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
Johnny.Q at chemeketa.edu<mailto:Johnny.Q at chemeketa.edu>
Building 22 Room 131
Work 5033995294<tel:(503)%20399-5294>
Mobile 9712182110<tel:(971)%20218-2110>
SIP 5035406686<tel:(503)%20540-6686>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180322/c688fbcf/attachment.html>


More information about the cisco-voip mailing list