Hello, this question is 90% curiosity and wanting to understand how it works and 10% requirement to write correct documentation.
I am currently in the process of writing a documentation for a large customer that aims to document the current status of DTMF Relay in the customer setup. The setup is quite large, consisting of two CUCM Clusters with 10 nodes each, around 100 Gateways to branch locations and one PSTN connection.
DTMF is working fine right now, and i already found out that RTP-NTE is being used from the Phone all the way to the Gateway with no MTPs inbetween. This is the rough setup, SIP all the way, with some more Gateways on the bottom right that arent relevant in this case.
The config is simple: All SIP Trunks on both CUCMs have "No Preference" as their DTMF Method.
The CUBE has both SIP-NOTIFY and then RTP-NTE on its incoming dial-peer.
The Phone is a normal 8851.
I determined that it had to be RTP-NTE from start to finish because the dial-peer only allows NOTIFY and NTE, and as the live data capture on CUCM #2 showed no NOTIFY packets going to the CUBE, at least that part had to be NTE. then, i saw that the c= connection SDP field in the 200 OK from CUCM #1 to the telephone listed the IP of the CUBE, meaning the media flows straight from the phone to the CUBE with no MTP, so it had to be NTE from start to end.
The INVITEs/OKs/ACKs between phone, CUCM #1 and CUCM #2 also containted KPML in the allow-events, but obviously not in the 200 OK from CUBE to CUCM #2, as the dial-peer doesnt allow KPML.
But then i noticed the first thing that was odd to me: even though RTP-NTE is being used all the way, i saw that when DTMF signals were being sent, the phone STILL sends NOTIFYs with the key-presses to CUCM #1, and CUCM #1 also sends those NOTIFIYs to CUCM #2.
I looked up what the Allow-Events field actually does in the IETF docs. (https://www.ietf.org/rfc/rfc3265.txt)
It says:
The presence of the "Allow-Events" header in a message is sufficient to indicate support for SUBSCRIBE and NOTIFY.
I understand that this means that whenever a SIP header includes this Allow-Events Field, no matter what the actual EVENT is that is included in it, it indicates that it can process SUBSCRIBE/NOTIFY messages.
Those Allow-Events in my test call (telephone to PSTN) are:
INVITES:
Phone -> CUCM #1: KPML, Dialog
CUCM #1 -> CUCM #2: Presence, KPML
CUCM #2 -> CUBE: Presence, KPML
OK:
CUBE -> CUCM #2: telephone-event
CUCM #2 -> CUCM #1: Presence, KPML
CUCM #1 -> Telephone: Presence
and here is the second thing i dont understand: Why are SUBSCRIBE/NOTIFYS being sent between phone, CUCM #1 and CUCM #2, but not between CUCM #2 and CUBE? to understand what exactly is happening, i would like to know what exactly each of those EVENTs actually is - i looked up cisco docs and IETF docs, but nowhere could i find a concise list of SUBSCRIBE events and what they mean.
Also, why does CUCM #1 not send back KPML as an allowed event to the phone?
my assumption:
KPML - KPML
Presence - i think this is normal SIP-NOTIFY?
Dialog - No idea
telephone-event - NTE? But NTE is already offered in the SDP header, and is not an OOB method using NOTIFYs, so it wouldnt make sense to be a SUBSCRIBE event.
apologies for my unstructured post, in a nutshell my 3 questions are:
1 - Why are KPML NOTIFYs being sent, even though NTE is being used from start to finish?
2 - Why is the CUCM #1 SUBSCRIBEing to the phone, but CUCM #2 isnt SUBSCRIBEing to the CUBE, even though both send an Allow-Events header?
3 - What are Allow-Events "Dialog" and "Telephone-Event"?
4 - Why does the 200 OK from CUCM #1 to Phone suddenly not allow KPML anymore?
Thanks for any replies. Finding out why things work like they do is weirdly satisfying...
