Re: [cisco-voip] CUCM Pre-Upgrade Checklist

[Bill Talley]

I've seen it and had the same reaction you're having.  I *believe*, but
could be wrong, those disclaimers are added in relation to Prime
Collaboration Deployment (PCD) upgrades.  I've performed several PCD
upgrades and experienced the issues described in your email (and many
others) when using PCD and have stopped using PCD for those reason.  Doing
direct upgrades, I've taken the precautions outlined in the docs you
referenced, but have not encountered those issues during direct upgrades.

On Sat, Mar 31, 2018 at 10:38 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Has anyone seen this lately?  This thing is nuts.  I've been doing
> upgrades for like 10 years now, and this seems a little over the top.
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/
> upgrade/11_5_1/cucm_b_upgrade-guide-cucm-115/cucm_b_upgrade-
> guide-cucm-115_chapter_010001.html
>
> Some Highlights:
>
> "If you have custom ringtones or background images in the TFTP directory,
> you need to create a separate backup for these files. They are not included
> in the Disaster Recovery System (DRS) backup file."
>
> Good to know.  I must admit that I didn't know that.
>
> "Record the following login and password information: all application
> users credentials, such as DRS, AXL, and accounts for other third-party
> integration"
>
> What?  Why?  What do you plan on doing with my configuration?
>
> "Record the settings for Enterprise Parameters on both [CM] nodes and
> [IM&P] nodes. [T]he settings that are configured on Unified Communications
> Manager nodes overwrite the settings configured on IM and Presence Service
> nodes during the upgrade process."
>
> Well that's some lazy software engineering right there folks.
>
> "Export user records using the Bulk Administration Tool (BAT)."
>
> That's a nice list of users you got there.  It would be a shame if this
> upgrade deleted all of them.
>
> And the list just goes on, and on, and on.  The pre-upgrade is as long as
> the upgrade.  Who legitimately is already doing 100% of these things?
>
> ___
> 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] CUCM Pre-Upgrade Checklist

[Anthony Holloway]

Has anyone seen this lately?  This thing is nuts.  I've been doing upgrades
for like 10 years now, and this seems a little over the top.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/11_5_1/cucm_b_upgrade-guide-cucm-115/cucm_b_upgrade-guide-cucm-115_chapter_010001.html

Some Highlights:

"If you have custom ringtones or background images in the TFTP directory,
you need to create a separate backup for these files. They are not included
in the Disaster Recovery System (DRS) backup file."

Good to know.  I must admit that I didn't know that.

"Record the following login and password information: all application users
credentials, such as DRS, AXL, and accounts for other third-party
integration"

What?  Why?  What do you plan on doing with my configuration?

"Record the settings for Enterprise Parameters on both [CM] nodes and
[IM&P] nodes. [T]he settings that are configured on Unified Communications
Manager nodes overwrite the settings configured on IM and Presence Service
nodes during the upgrade process."

Well that's some lazy software engineering right there folks.

"Export user records using the Bulk Administration Tool (BAT)."

That's a nice list of users you got there.  It would be a shame if this
upgrade deleted all of them.

And the list just goes on, and on, and on.  The pre-upgrade is as long as
the upgrade.  Who legitimately is already doing 100% of these things?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUBE DTMF

[Anthony Holloway]

Depends on the device capabilities involved in the call.  What I'm saying
is, limiting your DTMF to inband only is a bad idea, and opening it up to
OOB as well as inband is a better idea.  Since most CTI based applications,
which includes call center, do not support Inband DTMF, you will be
invoking MTPs for those calls flows, 100% of the time.

On Sat, Mar 31, 2018 at 8:28 PM Kent Roberts  wrote:

> Interesting. Hundreds of millions of never saw that issue.   I wonder if
> that was a carrier specific setting.   Cause they did some really screwy
> things that I haven’t seen with other carriers
>
>
>
> Kent
>
> On Mar 31, 2018, at 18:56, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Don't do that.  That's a sure fire way to invoking MTPs for flows that
> don't need it, when your CUBE will happily inter-work Inband to OOB.
>
> On Fri, Mar 30, 2018 at 10:38 PM Kent Roberts  wrote:
>
>> Put the NTE first, or if you can only use NTE.
>>
>>
>> On Mar 30, 2018, at 9:10 PM, GR  wrote:
>>
>> Thx Anthony. Just an update, did that and interworking works fine between
>> kpml and rtp nte.
>>
>> Was enquiring abt digit drop to follow a proactive approach rather than
>> reactive.  So far its ok without that - but I still have few pending sites
>> so not implemented globally yet.
>>
>> Sent from my iPhone
>>
>> On 17 Mar 2018, at 5:08 am, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> I have had to add digit-drop to the dial-peers when calls were heading to
>> CUC, but not 100% of the time.  As with a lot of things, don't configure
>> something just to configure it.  Know that it's needed first, then
>> configure it.  Else you end up with this giant configuration that you
>> cannot explain half of what its doing.
>>
>> On Fri, Mar 16, 2018 at 12:33 AM GR  wrote:
>>
>>> Thanks Anthony. So no need to configure digit drop ? Even if I am doing
>>> RFC2833 on one leg and advertise both Inband and OOB on second leg.
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On 16 Mar 2018, at 2:10 am, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
>>> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml
>>> interworking.  Weird, I know.  But that's how it was.  However, when I went
>>> to grab the link for my source, the table has been updated, and I see that
>>> this is now supported.
>>>
>>>
>>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
>>>
>>> Therefore, I see no gotchas with enablingwell...maybe one gotcha.
>>> If you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will
>>> advertise both, and the offer answer model dictates that CUBE will then not
>>> be able to choose or control the DTMF relay selected.  However, when CUBE
>>> receives an offer with multiple relays in it, it will choose which to use
>>> based on ordermaybe.
>>>
>>> Citations from that link:
>>>
>>> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and
>>> are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes
>>> precedence."
>>>
>>> "If you configure more than one out-of-band DTMF method, preference goes
>>> from highest to lowest in the order of configuration."
>>>
>>> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and
>>> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF
>>> method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE
>>> still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting
>>> problems at CUBE."
>>>
>>> "CUBE selects DTMF relay mechanisms using the following priority:
>>>
>>>
>>>- sip-notify or sip-kpml (highest priority)
>>>   - rtp-nte
>>>   - None—Send DTMF in-band"
>>>
>>> I recommend to read that entire document, or at least the chapter I
>>> linked, because it has some good info on it.  Of course, you'll want to
>>> test everything, because it's not out of reason to have to file a
>>> documentation defect.
>>>
>>> On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:
>>>
 Hi Guys,

 I am having an issue with SIP provider only supporting rfc2833. The
 CUBEs are configured only for rtp-nte on all dial-peers facing both the
 provider and the CUCM internal network (multiple clusters)

 Randomly one of the MGCP/h323 gateway is having issues, where it only
 supports OOB and then further complications trying to resolve the problem.

 I am planning to add sip kpml as well on top of rtp-nte to advertise
 both inband and outofband DTMF methods towards our internal CUCM network
 and let CUBE do inter-working in case where one leg is rfc2833 (carrier
 side) and other is kpml(internal network lets say MGCP gateway). Trying to
 stay away from MTPs.

 Any gotchas if I just go ahead and add kpml on top of existing rtp-nte
 method (on CUBE dial-peers facing our internal network) as I don’t w

Re: [cisco-voip] Log Parser for RTMT

[Kent Roberts]

I should have said feedback welcome but please be polite



Kent

> On Mar 31, 2018, at 19:00, Anthony Holloway  
> wrote:
> 
> What did you mean by, don't bother with negative feedback?
> 
> Does your solution just copy the SDL files which contain lines pertaining to 
> the call, or does it strip out the lines pertaining to the call and create a 
> whole new log file containing just that call?
> 
>> On Fri, Mar 30, 2018 at 10:29 PM Kent Roberts  wrote:
>> Hi all.  
>> 
>> So I am one of the few people that have worked with CUCM since Cisco started 
>> with CallManager, back in 2000’s.  As such, there is one thing that I have 
>> always hated, and that was reading the logs cause there is just soo much 
>> stuff there.
>> 
>> I wrote a set of scrips a couple years ago, that is designed to parse the 
>> RTMT logs from CUCM and return only data based on the call.
>> 
>> After a few people begging for a copy of it, I decided to make it a real 
>> program.
>> 
>> If you find it useful, please contribute to my tax deductible non-profit.  
>> (Facebook has an easy donation program.  
>> Https://www.facebook.com/projecttesn)
>> 
>> 
>> If you have Ideas for other stuff you would like to see let me know, I will 
>> see what I can do.
>> 
>> 
>> So the program works or should work like the following.(It is beta right 
>> now, as I am trying to make it self contained instead of scrips)
>> 
>> Put in the ANI or DNIS.  (Right now I know the extension on cucm works, not 
>> sure about the other side yet).   Or the SIP ID.   (This might be hit or 
>> miss at the moment)
>> 
>> Push the button to start.  Select the location of the RTMT files.  (Gz’s are 
>> ok, it will unpack them)   
>> 
>> It will create a -output on the end of the path you provide with the data.
>> 
>> It will collect the calllog files,  and put the revenant data into a file.  
>> Once it finds matches it will start to assemble the data into a file, and 
>> copy the SDL files that are tied to it.
>> 
>> The goal is to get only the data related to the call provided, so tracking 
>> down what went on is much easier.
>> 
>> Once complete, you can or should be able to load the file with translatorx 
>> and have a smaller file to work with.
>> 
>> Find it here.Please note, I have restricted the running time, as it will 
>> need some updates.  Please feel free to help me make it better.   If its 
>> negative feedback, please don’t bother.
>> 
>> http://www.projecttesn.org/ckrparse4rtmt.exe
>> 
>> FYI. This is running with a test CERT, and right now not signed, so windows 
>> defender may pop up and Symantec will have a cow…. Put should not be any 
>> worries.
>> ___
>> 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

Re: [cisco-voip] Log Parser for RTMT

[Kent Roberts]

Negative feed back in the form of bashing.I’ve had bad experiences before 
trying to do nice things.

  I don’t mind things to be fixed modified or changed or if it broke.
I know there is going to be things people find and that info is great to make 
it better.   

Hope that makes sense?

To answer your question  if it is working correctly it does both.
It will copy the complete sdl file if it finds a match in it   It will create a 
new file with just the detected lines in it for the call.  And it will also 
create a file for each server that was involved 




Kent

> On Mar 31, 2018, at 19:00, Anthony Holloway  
> wrote:
> 
> What did you mean by, don't bother with negative feedback?
> 
> Does your solution just copy the SDL files which contain lines pertaining to 
> the call, or does it strip out the lines pertaining to the call and create a 
> whole new log file containing just that call?
> 
>> On Fri, Mar 30, 2018 at 10:29 PM Kent Roberts  wrote:
>> Hi all.  
>> 
>> So I am one of the few people that have worked with CUCM since Cisco started 
>> with CallManager, back in 2000’s.  As such, there is one thing that I have 
>> always hated, and that was reading the logs cause there is just soo much 
>> stuff there.
>> 
>> I wrote a set of scrips a couple years ago, that is designed to parse the 
>> RTMT logs from CUCM and return only data based on the call.
>> 
>> After a few people begging for a copy of it, I decided to make it a real 
>> program.
>> 
>> If you find it useful, please contribute to my tax deductible non-profit.  
>> (Facebook has an easy donation program.  
>> Https://www.facebook.com/projecttesn)
>> 
>> 
>> If you have Ideas for other stuff you would like to see let me know, I will 
>> see what I can do.
>> 
>> 
>> So the program works or should work like the following.(It is beta right 
>> now, as I am trying to make it self contained instead of scrips)
>> 
>> Put in the ANI or DNIS.  (Right now I know the extension on cucm works, not 
>> sure about the other side yet).   Or the SIP ID.   (This might be hit or 
>> miss at the moment)
>> 
>> Push the button to start.  Select the location of the RTMT files.  (Gz’s are 
>> ok, it will unpack them)   
>> 
>> It will create a -output on the end of the path you provide with the data.
>> 
>> It will collect the calllog files,  and put the revenant data into a file.  
>> Once it finds matches it will start to assemble the data into a file, and 
>> copy the SDL files that are tied to it.
>> 
>> The goal is to get only the data related to the call provided, so tracking 
>> down what went on is much easier.
>> 
>> Once complete, you can or should be able to load the file with translatorx 
>> and have a smaller file to work with.
>> 
>> Find it here.Please note, I have restricted the running time, as it will 
>> need some updates.  Please feel free to help me make it better.   If its 
>> negative feedback, please don’t bother.
>> 
>> http://www.projecttesn.org/ckrparse4rtmt.exe
>> 
>> FYI. This is running with a test CERT, and right now not signed, so windows 
>> defender may pop up and Symantec will have a cow…. Put should not be any 
>> worries.
>> ___
>> 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

Re: [cisco-voip] CUBE DTMF

[Kent Roberts]

Interesting. Hundreds of millions of never saw that issue.   I wonder if that 
was a carrier specific setting.   Cause they did some really screwy things that 
I haven’t seen with other carriers


Kent

> On Mar 31, 2018, at 18:56, Anthony Holloway  
> wrote:
> 
> Don't do that.  That's a sure fire way to invoking MTPs for flows that don't 
> need it, when your CUBE will happily inter-work Inband to OOB.
> 
>> On Fri, Mar 30, 2018 at 10:38 PM Kent Roberts  wrote:
>> Put the NTE first, or if you can only use NTE.
>> 
>> 
>>> On Mar 30, 2018, at 9:10 PM, GR  wrote:
>>> 
>>> Thx Anthony. Just an update, did that and interworking works fine between 
>>> kpml and rtp nte. 
>>> 
>>> Was enquiring abt digit drop to follow a proactive approach rather than 
>>> reactive.  So far its ok without that - but I still have few pending sites 
>>> so not implemented globally yet. 
>>> 
>>> Sent from my iPhone
>>> 
 On 17 Mar 2018, at 5:08 am, Anthony Holloway 
  wrote:
 
 I have had to add digit-drop to the dial-peers when calls were heading to 
 CUC, but not 100% of the time.  As with a lot of things, don't configure 
 something just to configure it.  Know that it's needed first, then 
 configure it.  Else you end up with this giant configuration that you 
 cannot explain half of what its doing.
 
> On Fri, Mar 16, 2018 at 12:33 AM GR  wrote:
> Thanks Anthony. So no need to configure digit drop ? Even if I am doing 
> RFC2833 on one leg and advertise both Inband and OOB on second leg. 
> 
> 
> Sent from my iPhone
> 
>> On 16 Mar 2018, at 2:10 am, Anthony Holloway 
>>  wrote:
>> 
>> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml 
>> interworking.  Weird, I know.  But that's how it was.  However, when I 
>> went to grab the link for my source, the table has been updated, and I 
>> see that this is now supported.
>> 
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
>> 
>> Therefore, I see no gotchas with enablingwell...maybe one gotcha.  
>> If you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE 
>> will advertise both, and the offer answer model dictates that CUBE will 
>> then not be able to choose or control the DTMF relay selected.  However, 
>> when CUBE receives an offer with multiple relays in it, it will choose 
>> which to use based on ordermaybe.
>> 
>> Citations from that link:
>> 
>> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and 
>> are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes 
>> precedence."
>> 
>> "If you configure more than one out-of-band DTMF method, preference goes 
>> from highest to lowest in the order of configuration."
>> 
>> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and 
>> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte 
>> DTMF method to receive digits and a SUBSCRIBE if sip-kpml is not 
>> initiated. CUBE still accepts SUBSCRIBEs for KPML. This prevents 
>> double-digit reporting problems at CUBE."
>> 
>> "CUBE selects DTMF relay mechanisms using the following priority:
>> sip-notify or sip-kpml (highest priority)
>> rtp-nte
>> None—Send DTMF in-band"
>> I recommend to read that entire document, or at least the chapter I 
>> linked, because it has some good info on it.  Of course, you'll want to 
>> test everything, because it's not out of reason to have to file a 
>> documentation defect.
>> 
>>> On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:
>>> Hi Guys,
>>> 
>>> I am having an issue with SIP provider only supporting rfc2833. The 
>>> CUBEs are configured only for rtp-nte on all dial-peers facing both the 
>>> provider and the CUCM internal network (multiple clusters)
>>> 
>>> Randomly one of the MGCP/h323 gateway is having issues, where it only 
>>> supports OOB and then further complications trying to resolve the 
>>> problem.
>>> 
>>> I am planning to add sip kpml as well on top of rtp-nte to advertise 
>>> both inband and outofband DTMF methods towards our internal CUCM 
>>> network and let CUBE do inter-working in case where one leg is rfc2833 
>>> (carrier side) and other is kpml(internal network lets say MGCP 
>>> gateway). Trying to stay away from MTPs.
>>> 
>>> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte 
>>> method (on CUBE dial-peers facing our internal network) as I don’t want 
>>> to break the setup where only inband is supported, hard to check in a 
>>> global deployment.
>>> 
>>> Any need to use digit-drop in case both inband and out of band digits 
>>> are sent? If required it will be only on dial-peers fa

Re: [cisco-voip] Log Parser for RTMT

[Anthony Holloway]

What did you mean by, don't bother with negative feedback?

Does your solution just copy the SDL files which contain lines pertaining
to the call, or does it strip out the lines pertaining to the call and
create a whole new log file containing just that call?

On Fri, Mar 30, 2018 at 10:29 PM Kent Roberts  wrote:

> Hi all.
>
> So I am one of the few people that have worked with CUCM since Cisco
> started with CallManager, back in 2000’s.  As such, there is one thing that
> I have always hated, and that was reading the logs cause there is just
> soo much stuff there.
>
> I wrote a set of scrips a couple years ago, that is designed to parse the
> RTMT logs from CUCM and return only data based on the call.
>
> After a few people begging for a copy of it, I decided to make it a real
> program.
>
> If you find it useful, please contribute to my tax deductible non-profit.
>  (Facebook has an easy donation program.
> Https://www.facebook.com/projecttesn)
>
>
> If you have Ideas for other stuff you would like to see let me know, I
> will see what I can do.
>
>
> So the program works or should work like the following.(It is beta
> right now, as I am trying to make it self contained instead of scrips)
>
> Put in the ANI or DNIS.  (Right now I know the extension on cucm works,
> not sure about the other side yet).   Or the SIP ID.   (This might be hit
> or miss at the moment)
>
> Push the button to start.  Select the location of the RTMT files.  (Gz’s
> are ok, it will unpack them)
>
> It will create a -output on the end of the path you provide with the data.
>
> It will collect the calllog files,  and put the revenant data into a
> file.  Once it finds matches it will start to assemble the data into a
> file, and copy the SDL files that are tied to it.
>
> The goal is to get only the data related to the call provided, so tracking
> down what went on is much easier.
>
> Once complete, you can or should be able to load the file with translatorx
> and have a smaller file to work with.
>
> Find it here.Please note, I have restricted the running time, as it
> will need some updates.  Please feel free to help me make it better.   If
> its negative feedback, please don’t bother.
>
> http://www.projecttesn.org/ckrparse4rtmt.exe
>
> FYI. This is running with a test CERT, and right now not signed, so
> windows defender may pop up and Symantec will have a cow…. Put should not
> be any worries.
> ___
> 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

Re: [cisco-voip] CUBE DTMF

[Anthony Holloway]

Don't do that.  That's a sure fire way to invoking MTPs for flows that
don't need it, when your CUBE will happily inter-work Inband to OOB.

On Fri, Mar 30, 2018 at 10:38 PM Kent Roberts  wrote:

> Put the NTE first, or if you can only use NTE.
>
>
> On Mar 30, 2018, at 9:10 PM, GR  wrote:
>
> Thx Anthony. Just an update, did that and interworking works fine between
> kpml and rtp nte.
>
> Was enquiring abt digit drop to follow a proactive approach rather than
> reactive.  So far its ok without that - but I still have few pending sites
> so not implemented globally yet.
>
> Sent from my iPhone
>
> On 17 Mar 2018, at 5:08 am, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> I have had to add digit-drop to the dial-peers when calls were heading to
> CUC, but not 100% of the time.  As with a lot of things, don't configure
> something just to configure it.  Know that it's needed first, then
> configure it.  Else you end up with this giant configuration that you
> cannot explain half of what its doing.
>
> On Fri, Mar 16, 2018 at 12:33 AM GR  wrote:
>
>> Thanks Anthony. So no need to configure digit drop ? Even if I am doing
>> RFC2833 on one leg and advertise both Inband and OOB on second leg.
>>
>>
>> Sent from my iPhone
>>
>> On 16 Mar 2018, at 2:10 am, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml
>> interworking.  Weird, I know.  But that's how it was.  However, when I went
>> to grab the link for my source, the table has been updated, and I see that
>> this is now supported.
>>
>>
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
>>
>> Therefore, I see no gotchas with enablingwell...maybe one gotcha.  If
>> you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will
>> advertise both, and the offer answer model dictates that CUBE will then not
>> be able to choose or control the DTMF relay selected.  However, when CUBE
>> receives an offer with multiple relays in it, it will choose which to use
>> based on ordermaybe.
>>
>> Citations from that link:
>>
>> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are
>> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes
>> precedence."
>>
>> "If you configure more than one out-of-band DTMF method, preference goes
>> from highest to lowest in the order of configuration."
>>
>> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and
>> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF
>> method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE
>> still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting
>> problems at CUBE."
>>
>> "CUBE selects DTMF relay mechanisms using the following priority:
>>
>>
>>- sip-notify or sip-kpml (highest priority)
>>   - rtp-nte
>>   - None—Send DTMF in-band"
>>
>> I recommend to read that entire document, or at least the chapter I
>> linked, because it has some good info on it.  Of course, you'll want to
>> test everything, because it's not out of reason to have to file a
>> documentation defect.
>>
>> On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:
>>
>>> Hi Guys,
>>>
>>> I am having an issue with SIP provider only supporting rfc2833. The
>>> CUBEs are configured only for rtp-nte on all dial-peers facing both the
>>> provider and the CUCM internal network (multiple clusters)
>>>
>>> Randomly one of the MGCP/h323 gateway is having issues, where it only
>>> supports OOB and then further complications trying to resolve the problem.
>>>
>>> I am planning to add sip kpml as well on top of rtp-nte to advertise
>>> both inband and outofband DTMF methods towards our internal CUCM network
>>> and let CUBE do inter-working in case where one leg is rfc2833 (carrier
>>> side) and other is kpml(internal network lets say MGCP gateway). Trying to
>>> stay away from MTPs.
>>>
>>> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte
>>> method (on CUBE dial-peers facing our internal network) as I don’t want to
>>> break the setup where only inband is supported, hard to check in a global
>>> deployment.
>>>
>>> Any need to use digit-drop in case both inband and out of band digits
>>> are sent? If required it will be only on dial-peers facing CUCM side? Or
>>> this is not required as the provider only supports rfc2833.
>>>
>>> Thanks
>>> GR
>>>
>>>
>>>
>>>
>>> Sent from my iPhone
>>> ___
>>> 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.net

Re: [cisco-voip] Log Parser for RTMT

[Lelio Fulgenzi]

Gotcha! Thx.

---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Kent Roberts [mailto:k...@fredf.org]
Sent: Saturday, March 31, 2018 5:18 PM
To: Lelio Fulgenzi 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Log Parser for RTMT

I think your asking about translatorx?

https://translatorx.org. Great program helps you go 
through logs either from cucm or gatewaysBut it can get slow if you have 
lots of log files to load in to track a call.   35000 devices on a system that 
does 1-2 million calls a month and a30 min call can  you 750 megs early.

So my program will smash that down to say 30-50 megs (depends what your doing). 
And makes translatorx much faster since it doesn’t have the extra calls to parse


Kent

On Mar 31, 2018, at 14:56, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:
TranslatorX?
Sent from my iPhone

On Mar 30, 2018, at 11:27 PM, Kent Roberts 
mailto:k...@fredf.org>> wrote:
Hi all.

So I am one of the few people that have worked with CUCM since Cisco started 
with CallManager, back in 2000’s.  As such, there is one thing that I have 
always hated, and that was reading the logs cause there is just soo much 
stuff there.

I wrote a set of scrips a couple years ago, that is designed to parse the RTMT 
logs from CUCM and return only data based on the call.

After a few people begging for a copy of it, I decided to make it a real 
program.

If you find it useful, please contribute to my tax deductible non-profit.  
(Facebook has an easy donation program.  Https://www.facebook.com/projecttesn)


If you have Ideas for other stuff you would like to see let me know, I will see 
what I can do.


So the program works or should work like the following.(It is beta right 
now, as I am trying to make it self contained instead of scrips)

Put in the ANI or DNIS.  (Right now I know the extension on cucm works, not 
sure about the other side yet).   Or the SIP ID.   (This might be hit or miss 
at the moment)

Push the button to start.  Select the location of the RTMT files.  (Gz’s are 
ok, it will unpack them)

It will create a -output on the end of the path you provide with the data.

It will collect the calllog files,  and put the revenant data into a file.  
Once it finds matches it will start to assemble the data into a file, and copy 
the SDL files that are tied to it.

The goal is to get only the data related to the call provided, so tracking down 
what went on is much easier.

Once complete, you can or should be able to load the file with translatorx and 
have a smaller file to work with.

Find it here.Please note, I have restricted the running time, as it will 
need some updates.  Please feel free to help me make it better.   If its 
negative feedback, please don’t bother.

http://www.projecttesn.org/ckrparse4rtmt.exe

FYI. This is running with a test CERT, and right now not signed, so windows 
defender may pop up and Symantec will have a cow…. Put should not be any 
worries.
___
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

Re: [cisco-voip] Log Parser for RTMT

[Kent Roberts]

I think your asking about translatorx?

https://translatorx.org. Great program helps you go through logs either from 
cucm or gatewaysBut it can get slow if you have lots of log files to load 
in to track a call.   35000 devices on a system that does 1-2 million calls a 
month and a30 min call can  you 750 megs early.   

So my program will smash that down to say 30-50 megs (depends what your doing). 
And makes translatorx much faster since it doesn’t have the extra calls to parse



Kent

> On Mar 31, 2018, at 14:56, Lelio Fulgenzi  wrote:
> 
> TranslatorX?
> 
> Sent from my iPhone
> 
> On Mar 30, 2018, at 11:27 PM, Kent Roberts  wrote:
> 
>> Hi all.  
>> 
>> So I am one of the few people that have worked with CUCM since Cisco started 
>> with CallManager, back in 2000’s.  As such, there is one thing that I have 
>> always hated, and that was reading the logs cause there is just soo much 
>> stuff there.
>> 
>> I wrote a set of scrips a couple years ago, that is designed to parse the 
>> RTMT logs from CUCM and return only data based on the call.
>> 
>> After a few people begging for a copy of it, I decided to make it a real 
>> program.
>> 
>> If you find it useful, please contribute to my tax deductible non-profit.  
>> (Facebook has an easy donation program.  
>> Https://www.facebook.com/projecttesn)
>> 
>> 
>> If you have Ideas for other stuff you would like to see let me know, I will 
>> see what I can do.
>> 
>> 
>> So the program works or should work like the following.(It is beta right 
>> now, as I am trying to make it self contained instead of scrips)
>> 
>> Put in the ANI or DNIS.  (Right now I know the extension on cucm works, not 
>> sure about the other side yet).   Or the SIP ID.   (This might be hit or 
>> miss at the moment)
>> 
>> Push the button to start.  Select the location of the RTMT files.  (Gz’s are 
>> ok, it will unpack them)   
>> 
>> It will create a -output on the end of the path you provide with the data.
>> 
>> It will collect the calllog files,  and put the revenant data into a file.  
>> Once it finds matches it will start to assemble the data into a file, and 
>> copy the SDL files that are tied to it.
>> 
>> The goal is to get only the data related to the call provided, so tracking 
>> down what went on is much easier.
>> 
>> Once complete, you can or should be able to load the file with translatorx 
>> and have a smaller file to work with.
>> 
>> Find it here.Please note, I have restricted the running time, as it will 
>> need some updates.  Please feel free to help me make it better.   If its 
>> negative feedback, please don’t bother.
>> 
>> http://www.projecttesn.org/ckrparse4rtmt.exe
>> 
>> FYI. This is running with a test CERT, and right now not signed, so windows 
>> defender may pop up and Symantec will have a cow…. Put should not be any 
>> worries.
>> ___
>> 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

Re: [cisco-voip] Log Parser for RTMT

[Lelio Fulgenzi]

TranslatorX?

Sent from my iPhone

On Mar 30, 2018, at 11:27 PM, Kent Roberts 
mailto:k...@fredf.org>> wrote:

Hi all.

So I am one of the few people that have worked with CUCM since Cisco started 
with CallManager, back in 2000’s.  As such, there is one thing that I have 
always hated, and that was reading the logs cause there is just soo much 
stuff there.

I wrote a set of scrips a couple years ago, that is designed to parse the RTMT 
logs from CUCM and return only data based on the call.

After a few people begging for a copy of it, I decided to make it a real 
program.

If you find it useful, please contribute to my tax deductible non-profit.  
(Facebook has an easy donation program.  Https://www.facebook.com/projecttesn)


If you have Ideas for other stuff you would like to see let me know, I will see 
what I can do.


So the program works or should work like the following.(It is beta right 
now, as I am trying to make it self contained instead of scrips)

Put in the ANI or DNIS.  (Right now I know the extension on cucm works, not 
sure about the other side yet).   Or the SIP ID.   (This might be hit or miss 
at the moment)

Push the button to start.  Select the location of the RTMT files.  (Gz’s are 
ok, it will unpack them)

It will create a -output on the end of the path you provide with the data.

It will collect the calllog files,  and put the revenant data into a file.  
Once it finds matches it will start to assemble the data into a file, and copy 
the SDL files that are tied to it.

The goal is to get only the data related to the call provided, so tracking down 
what went on is much easier.

Once complete, you can or should be able to load the file with translatorx and 
have a smaller file to work with.

Find it here.Please note, I have restricted the running time, as it will 
need some updates.  Please feel free to help me make it better.   If its 
negative feedback, please don’t bother.

http://www.projecttesn.org/ckrparse4rtmt.exe

FYI. This is running with a test CERT, and right now not signed, so windows 
defender may pop up and Symantec will have a cow…. Put should not be any 
worries.
___
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

Re: [cisco-voip] CUBE DTMF

[Kent Roberts]

One thing to watch out for, or keep in the back of your mind.   Do you know if 
your carrier will route customer to customer calls on net?I had an issue 
with a carrier. One of their customers only did G711 and we offered G729 to 
start, and it would kill the call, since the vendor didn’t normalize the calls 
between their customers.



> On Mar 31, 2018, at 1:16 AM, GR  wrote:
> 
> Yeah - it was initially rtp-nte only (both internal and provider facing) but 
> some sites could only do out of band and I wanted to steer clear of using 
> MTPs - so added kpml on top of rtp nte. It works fine now and without the 
> need for mtp. 
> 
> Sent from my iPhone
> 
> On 31 Mar 2018, at 2:38 pm, Kent Roberts  > wrote:
> 
>> Put the NTE first, or if you can only use NTE.
>> 
>>> On Mar 30, 2018, at 9:10 PM, GR >> > wrote:
>>> 
>>> Thx Anthony. Just an update, did that and interworking works fine between 
>>> kpml and rtp nte. 
>>> 
>>> Was enquiring abt digit drop to follow a proactive approach rather than 
>>> reactive.  So far its ok without that - but I still have few pending sites 
>>> so not implemented globally yet. 
>>> 
>>> Sent from my iPhone
>>> 
>>> On 17 Mar 2018, at 5:08 am, Anthony Holloway 
>>> mailto:avholloway+cisco-v...@gmail.com>> 
>>> wrote:
>>> 
 I have had to add digit-drop to the dial-peers when calls were heading to 
 CUC, but not 100% of the time.  As with a lot of things, don't configure 
 something just to configure it.  Know that it's needed first, then 
 configure it.  Else you end up with this giant configuration that you 
 cannot explain half of what its doing.
 
 On Fri, Mar 16, 2018 at 12:33 AM GR >>> > wrote:
 Thanks Anthony. So no need to configure digit drop ? Even if I am doing 
 RFC2833 on one leg and advertise both Inband and OOB on second leg. 
 
 
 Sent from my iPhone
 
 On 16 Mar 2018, at 2:10 am, Anthony Holloway 
 mailto:avholloway+cisco-v...@gmail.com>> 
 wrote:
 
> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml 
> interworking.  Weird, I know.  But that's how it was.  However, when I 
> went to grab the link for my source, the table has been updated, and I 
> see that this is now supported.
> 
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
>  
> 
> 
> Therefore, I see no gotchas with enablingwell...maybe one gotcha.  If 
> you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will 
> advertise both, and the offer answer model dictates that CUBE will then 
> not be able to choose or control the DTMF relay selected.  However, when 
> CUBE receives an offer with multiple relays in it, it will choose which 
> to use based on ordermaybe.
> 
> Citations from that link:
> 
> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are 
> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes 
> precedence."
> 
> "If you configure more than one out-of-band DTMF method, preference goes 
> from highest to lowest in the order of configuration."
> 
> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and 
> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte 
> DTMF method to receive digits and a SUBSCRIBE if sip-kpml is not 
> initiated. CUBE still accepts SUBSCRIBEs for KPML. This prevents 
> double-digit reporting problems at CUBE."
> 
> "CUBE selects DTMF relay mechanisms using the following priority:
> sip-notify or sip-kpml (highest priority)
> rtp-nte
> None—Send DTMF in-band"
> I recommend to read that entire document, or at least the chapter I 
> linked, because it has some good info on it.  Of course, you'll want to 
> test everything, because it's not out of reason to have to file a 
> documentation defect.
> 
> On Thu, Mar 15, 2018 at 8:44 AM GR  > wrote:
> Hi Guys,
> 
> I am having an issue with SIP provider only supporting rfc2833. The CUBEs 
> are configured only for rtp-nte on all dial-peers facing both the 
> provider and the CUCM internal network (multiple clusters)
> 
> Randomly one of the MGCP/h323 gateway is having issues, where it only 
> supports OOB and then further complications trying to resolve the problem.
> 
> I am planning to add sip kpml as well on top of rtp-nte to advertise both 
> inband and outofband DTMF methods towards our internal CUCM network and 
> let CUBE do inter-working in case where one leg is rfc2833 (carrier side) 
> an

Re: [cisco-voip] CUBE DTMF

[GR]

Yeah - it was initially rtp-nte only (both internal and provider facing) but 
some sites could only do out of band and I wanted to steer clear of using MTPs 
- so added kpml on top of rtp nte. It works fine now and without the need for 
mtp. 

Sent from my iPhone

> On 31 Mar 2018, at 2:38 pm, Kent Roberts  wrote:
> 
> Put the NTE first, or if you can only use NTE.
> 
>> On Mar 30, 2018, at 9:10 PM, GR  wrote:
>> 
>> Thx Anthony. Just an update, did that and interworking works fine between 
>> kpml and rtp nte. 
>> 
>> Was enquiring abt digit drop to follow a proactive approach rather than 
>> reactive.  So far its ok without that - but I still have few pending sites 
>> so not implemented globally yet. 
>> 
>> Sent from my iPhone
>> 
>>> On 17 Mar 2018, at 5:08 am, Anthony Holloway 
>>>  wrote:
>>> 
>>> I have had to add digit-drop to the dial-peers when calls were heading to 
>>> CUC, but not 100% of the time.  As with a lot of things, don't configure 
>>> something just to configure it.  Know that it's needed first, then 
>>> configure it.  Else you end up with this giant configuration that you 
>>> cannot explain half of what its doing.
>>> 
 On Fri, Mar 16, 2018 at 12:33 AM GR  wrote:
 Thanks Anthony. So no need to configure digit drop ? Even if I am doing 
 RFC2833 on one leg and advertise both Inband and OOB on second leg. 
 
 
 Sent from my iPhone
 
> On 16 Mar 2018, at 2:10 am, Anthony Holloway 
>  wrote:
> 
> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml 
> interworking.  Weird, I know.  But that's how it was.  However, when I 
> went to grab the link for my source, the table has been updated, and I 
> see that this is now supported.
> 
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
> 
> Therefore, I see no gotchas with enablingwell...maybe one gotcha.  If 
> you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will 
> advertise both, and the offer answer model dictates that CUBE will then 
> not be able to choose or control the DTMF relay selected.  However, when 
> CUBE receives an offer with multiple relays in it, it will choose which 
> to use based on ordermaybe.
> 
> Citations from that link:
> 
> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are 
> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes 
> precedence."
> 
> "If you configure more than one out-of-band DTMF method, preference goes 
> from highest to lowest in the order of configuration."
> 
> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and 
> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte 
> DTMF method to receive digits and a SUBSCRIBE if sip-kpml is not 
> initiated. CUBE still accepts SUBSCRIBEs for KPML. This prevents 
> double-digit reporting problems at CUBE."
> 
> "CUBE selects DTMF relay mechanisms using the following priority:
> sip-notify or sip-kpml (highest priority)
> rtp-nte
> None—Send DTMF in-band"
> I recommend to read that entire document, or at least the chapter I 
> linked, because it has some good info on it.  Of course, you'll want to 
> test everything, because it's not out of reason to have to file a 
> documentation defect.
> 
>> On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:
>> Hi Guys,
>> 
>> I am having an issue with SIP provider only supporting rfc2833. The 
>> CUBEs are configured only for rtp-nte on all dial-peers facing both the 
>> provider and the CUCM internal network (multiple clusters)
>> 
>> Randomly one of the MGCP/h323 gateway is having issues, where it only 
>> supports OOB and then further complications trying to resolve the 
>> problem.
>> 
>> I am planning to add sip kpml as well on top of rtp-nte to advertise 
>> both inband and outofband DTMF methods towards our internal CUCM network 
>> and let CUBE do inter-working in case where one leg is rfc2833 (carrier 
>> side) and other is kpml(internal network lets say MGCP gateway). Trying 
>> to stay away from MTPs.
>> 
>> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte 
>> method (on CUBE dial-peers facing our internal network) as I don’t want 
>> to break the setup where only inband is supported, hard to check in a 
>> global deployment.
>> 
>> Any need to use digit-drop in case both inband and out of band digits 
>> are sent? If required it will be only on dial-peers facing CUCM side? Or 
>> this is not required as the provider only supports rfc2833.
>> 
>> Thanks
>> GR
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> ___
>> cisco-v