Once the endpoint successfully subscribe to KPML,CUCM sends a NOTIFY for KPML event, this is how DTMF will be sent out Next CUCM sends a 200 OK to the SUBSCRIBEġ0:59:30.695 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 172.10.104.32:: The next thing we see is that the gateway sends a subscribe for KPML eventġ0:59:30.695 |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 906 from 172.10.104.32:: NB: The ACK sent out to the gateway by CUCM doesn’t advertise RFC2833ġ0:59:30.684 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 172.10.104.32::
Looking at the advertised capabilites, both sides support KPML, KPML is chosing as the dtmf transport method UNSOL=0, KPML=1, Inband=0(0) mDefaultTelephonyEvent=101, mDtmfPreference=1, mMtpAllocated=0|*^*^* UNSOL=1, KPML=1, Inband=1(101) mEndppointsDtmfCaps. On the right hand side after the mEndppointsDtmfCaps (highlighted blue) refers to the dtmf supported by the gateway: which we can see is only KPML. NB: The "mLocalDtmfCaps" (highlighted) refers to the dtmf methods supported by CUCM.Here we see that CUCM supports unsolicited, KPML and RTP-NTE Next we see CUCM telling us the DTMF capabilites of the two endpoints (sip trunk and gateway Remote-Party-ID: party=called screen=no privacy=offĬontent-Disposition: session handling=required Note the DTMF advertised in the SDPĪllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
This is the 183 Session progress we get back from the gateway. Remote-Party-ID: "Deji okanlawon" party=calling screen=yes privacy=off This is the outbound CUCM INVITE sent to the Gatewayġ0:59:28.180 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 172.10.104.32:: Let’s look at the relevant section of the logs
0 kommentar(er)
