[cisco-voip] variable-length translation pattern

[daniele visaggio]

Hi all,

I have two translation pattern within the same partition (cucm 9.x).

They are:

1XXX
1!

When an incoming call from external sip gateway comes in with called number
(say) 1234, the matched translation is 1!.

At first, I thought that 1!, being less specific than 1XXX, should not
being matched.

Reading through Cisco Collaboration System 9.x Solution Reference Network
Designs (SRND)
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/dialplan.html,
I saw this:

When determining the number of matched strings for a variable-length
 pattern, Unified CM takes into account only the number of matched strings
 that are equal in length to the number of digits dialed. Assuming a user
 dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following
 table shows the number of matched strings of these potentially matching
 patterns*In this example the variable-length pattern 13! is selected
 as the best match*.


Changing temporarily the translation pattern with a leading # and then
going back to the original form, the pattern 1XXX started to be matched.

What do you think, guys? is this a bug or are 1! and 1XXX equal-precision
matches from cucm point of view?

Thank you
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] variable-length translation pattern

[daniele visaggio]

The reference from the SRND was only to make clear the origin of my
suspect. Initially I tought that 1XXX has higher priority than 1! but now,
after reading the SNRD, I'm not that sure. Of course the pattern from the
SRND examples are different from mine but the concept still applies imo.

I was trying to receive some confirmation/denial of my suspect.

2014-12-09 17:41 GMT+01:00 Bill Talley btal...@gmail.com:

 Your patterns are both 1 followed by a wildcard.  The SRNDs examples are
 NOT 1 followed by a wildcard, they are 1 followed by more specific
 wildcards or digits.

 1! Is NOT equal to 12!




 Sent from an Apple iOS device with very tiny touchscreen input keys.
 Please excude my typtos.

 On Dec 9, 2014, at 9:35 AM, daniele visaggio visaggio.dani...@gmail.com
 wrote:

 Always from the SRND:

 [...] This does not mean that the urgent pattern has a higher priority
 than other patterns; the closest-match logic described in the section on
 Call Routing in Unified CM still applies.

 For example, assume the route pattern 1XX is configured as urgent and the
 pattern 12! is configured as a regular route pattern. If a user dials 123,
 Unified CM will not make its routing decision as soon as it receives the
 third digit because even though 1XX is an urgent pattern, it is not the
 best match (10 total patterns matched by 12! versus 100 patterns matched by
 1XX). Unified CM will have to wait for inter-digit timeout before routing
 the call because the pattern 12! allows for more digits to be input by the
 user.


 Both my translation patterns have urgent priority enabled, so this aspect
 should not matter. I do not understand if 1XXX has higher priority than 1!
 or viceversa, given 1234 as called number.


 2014-12-09 16:09 GMT+01:00 Bill Talley btal...@gmail.com:

 I would think it will always match 1! because of the urgent priority
 setting.   Keep in mind the example you gave from the SRND list three
 different translation patterns.  The two you have are the same as far as
 the first two digits, no?

 Sent from an Apple iOS device with very tiny touchscreen input keys.
 Please excude my typtos.

 On Dec 9, 2014, at 5:59 AM, daniele visaggio visaggio.dani...@gmail.com
 wrote:

 Hi all,

 I have two translation pattern within the same partition (cucm 9.x).

 They are:

 1XXX
 1!

 When an incoming call from external sip gateway comes in with called
 number (say) 1234, the matched translation is 1!.

 At first, I thought that 1!, being less specific than 1XXX, should not
 being matched.

 Reading through Cisco Collaboration System 9.x Solution Reference
 Network Designs (SRND)
 http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/dialplan.html,
 I saw this:

 When determining the number of matched strings for a variable-length
 pattern, Unified CM takes into account only the number of matched strings
 that are equal in length to the number of digits dialed. Assuming a user
 dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following
 table shows the number of matched strings of these potentially matching
 patterns*In this example the variable-length pattern 13! is
 selected as the best match*.


 Changing temporarily the translation pattern with a leading # and then
 going back to the original form, the pattern 1XXX started to be matched.

 What do you think, guys? is this a bug or are 1! and 1XXX equal-precision
 matches from cucm point of view?

 Thank you

 ___
 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.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] sending sip 403 Forbidden msg upon reception of ISDN DISCONNECT msg

[daniele visaggio]

Hi,

I have a cisco voice-gateway (SIP to ISDN), model 2811 with
c2800nm-spservicesk9-mz.124-24.T8.bin ios.

Scenario:

1) dial from sip client an outside pstn number (my mobile phone).
2) I do not answer the call, instead I tear it down, hitting the red button
during ringing.

This what I get on the voice gateway (debug isdn q931 + debug ccsip
messages):

#

Dec 12 *11:04:18*.681 CET: ISDN BR0/1/0 Q931: *RX - DISCONNECT* pd = 8
callref = 0x84
Cause i = 0x8095 - Call rejected
Progress Ind i = 0x8288 - In-band info or appropriate now available
Display i = 'OCCUPATO'
VGTestDiData#

Dec 12 *11:04:49*.374 CET: ISDN BR0/1/0 Q931: *RX - RELEASE* pd = 8
callref = 0x84
Cause i = 0x8095 - Call rejected
Cause i = 0x82E6333036 - Recovery on timer expiry
Display i = 'OCCUPATO'
Dec 12 11:04:49.378 CET: ISDN BR0/1/0 Q931: TX - RELEASE_COMP pd = 8
callref = 0x04

Dec 12 *11:04:49*.410 CET: //-1//SIP/Msg/ccsipDisplayMsg:
Sent:
*SIP/2.0 403 Forbidden*
Via: SIP/2.0/UDP 10.98.67.97:5060
;branch=z9hG4bK-363631-262bf0ddaa74c7cced49a9f4d5fefb33
From: sip:null@10.130.124.120:5060;tag=-1350970591
To: sip:03456654741@10.130.124.120;tag=21B0F200-1574
Date: Fri, 12 Dec 2014 10:04:09 GMT

#

As you can see from logs, the pstn send DISCONNECT MSG and then wait 31
sec. before sending the RELEASE MSG to the vg.

Upon receiving the the RELEASE MSG, the gateway send 403 FORBIDDEN MSG to
the sip client.

My goal is to send the 403 FORBIDDEN MSG as soon as the gateway receives
the DISCONNECT MSG, in other words I don't want to wait 31 sec before
sending SIP 403.

Is this possible?

Thank you in advance,

Daniele
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Cube Recording Configuration

[daniele visaggio]

Thank you for all of your responses.

Sadly i'm still not able to get this working.

@daniel

for the time being I have no mediasense server. It's just a microsip client
+ wireshark (this is to simulate the recorder and look up the signaling).
The problem is that I can't see any signaling whatsoever reaching my fake
recorder. dial-peer on cube are all using udp, so in wireshark/microsip I
expect to see at least an incoming invite.

Btw I tried with tcp too and even then I couldn't spot any incoming SYN
packet.

It seems the dial-peer pointing the fake recorder simply doesn't get
matched (so no signaling).

2016-04-01 21:59 GMT+02:00 <dan...@ohnesorge.me>:

> Hi All,
>
> I think the config looks correct;
>
> - Dial-peer 1 is the dial-peer you want to record so you apply media-class
> 30
> - Media-class 30 is associated with recorder 400
> - Recorder 400 is associated with media-recording 3 (in other words
> dial-peer 3)
> - Dial-peer 3 is the 'SIP Trunk' towards MediaSense
>
> On MediaSense you would need to make sure 450123 is configured to record
> but I'm sure you've configured that already.
>
> I've had some really weird issues with MediaSense in the past where CUCM
> was sending TCP SYN on port 5060 but MediaSense never responded. A cluster
> reboot of MediaSense solved that issue. Perhaps take an IP Traffic Export
> on the router to see if it is sending TCP SYN and if MediaSense is
> responding.
>
> Sent from my iPhone
>
> On 2 Apr 2016, at 02:02, Anthony Holloway <avholloway+cisco-v...@gmail.com>
> wrote:
>
> First of all, be careful doing this in production:
>
> voice service voip
>  ip address trusted list
>   ipv4 0.0.0.0 0.0.0.0
>
>
> That is just reducing the security of your application and opening you up
> to abuse.  It's fine for troubleshooting and eliminating it as root cause,
> but then remove it and add addresses/subnets in there to lock down from
> where you will accept control traffic from.
>
> One last thing on this topic, since your dial-peers 2 and 3 already point
> to IP addresses of SIP peers, you don't need to even do anything more.
> That simple fact already permits those IP addresses to send you control
> traffic.
>
> Ok, on to the recording bit.  I have not done this task myself, but
> looking quickly through the following document:
>
>
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-ntwk-based.html
>
> ...it looks like you might have at least one error in your configuration.
>
> The one error I think you have:  Your "*media-class 30*" dial-peer
> command should be on dial-peer 3, not dial-peer 1.
>
> On Fri, Apr 1, 2016 at 3:56 AM, daniele visaggio <
> visaggio.dani...@gmail.com> wrote:
>
>> Good morning,
>>
>> I'm trying to record calls via CUBE. It doesn't work. This means that on
>> the recording server I can't see any SIP invite incoming from CUBE.
>>
>> Scenario:
>>
>> Phone --- CUCM --- SIP --- CUBE  ITSP  PSTN
>>   |
>>   |
>> Recording Server
>>
>>
>> Let's say I want to record all calls going to the PSTN.
>>
>> This is my config:
>>
>> #
>> !
>> voice service voip
>>  ip address trusted list
>>   ipv4 0.0.0.0 0.0.0.0
>>  allow-connections sip to sip
>> !
>> media profile recorder 400
>> media-recording 3
>> !
>> media class 30
>> recorder profile 400
>> !
>> !
>> dial-peer voice 1 voip
>> description :: Incoming calls from CUCM ::
>> session protocol sipv2
>> incoming called-number .
>> media-class 30
>> codec g711ulaw
>> !
>> dial-peer voice 2 voip
>> description :: To ITSP/PSTN ::
>> destination-pattern 0T
>> session protocol sipv2
>> session target ipv4:10.128.179.12
>> codec g711ulaw
>> !
>> dial-peer voice 3 voip
>> description :: To Recorder Server ::
>> destination-pattern 450123
>> session protocol sipv2
>> session target ipv4:10.130.221.218
>> codec g711ulaw
>> !
>>
>>
>> I double checked the configuration and it seems correct to me.
>>
>> Is there something else I need to do? Can someone spot an error?
>>
>>
>> Thank you,
>>
>> Daniele
>>
>>
>> ___
>> 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.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Cube Recording Configuration

[daniele visaggio]

Good morning,

I'm trying to record calls via CUBE. It doesn't work. This means that on
the recording server I can't see any SIP invite incoming from CUBE.

Scenario:

Phone --- CUCM --- SIP --- CUBE  ITSP  PSTN
  |
  |
Recording Server


Let's say I want to record all calls going to the PSTN.

This is my config:

#
!
voice service voip
 ip address trusted list
  ipv4 0.0.0.0 0.0.0.0
 allow-connections sip to sip
!
media profile recorder 400
media-recording 3
!
media class 30
recorder profile 400
!
!
dial-peer voice 1 voip
description :: Incoming calls from CUCM ::
session protocol sipv2
incoming called-number .
media-class 30
codec g711ulaw
!
dial-peer voice 2 voip
description :: To ITSP/PSTN ::
destination-pattern 0T
session protocol sipv2
session target ipv4:10.128.179.12
codec g711ulaw
!
dial-peer voice 3 voip
description :: To Recorder Server ::
destination-pattern 450123
session protocol sipv2
session target ipv4:10.130.221.218
codec g711ulaw
!


I double checked the configuration and it seems correct to me.

Is there something else I need to do? Can someone spot an error?


Thank you,

Daniele
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Firmware question

[daniele visaggio]

Yes, it is possible.

Go in ssh on the cucm node where the firmware has been installed.

Then do: show version active

it will give you the actual cucm version and the list of all the installed
firmware.

2018-06-13 8:22 GMT+02:00 James Dust :

> On version 11.5 cucm, is it possible once a cop.sgn file has been uploaded
> to view the previous firmware versions that reside on the nodes?
>
> For instance once the cop file is uploaded and has refreshed the device
> defaults page on an SCCP 7970, how would I know what previous 7970
> firmware’s reside on the cluster?
>
> Regards
>
> James
>
> Consider the environment - Think before you print
>
> The contents of this email are confidential to the intended recipient and
> may not be disclosed. Although it is believed that this email and any
> attachments are virus free, it is the responsibility of the recipient to
> confirm this.
>
> You are advised that urgent, time-sensitive communications should not be
> sent by email. We hereby give you notice that a delivery receipt does not
> constitute acknowledgement or receipt by the intended recipient(s).
>
> Details of Charles Stanley group companies and their regulators (where
> applicable), can be found at this URL http://www.charles-stanley.co.
> uk/contact-us/disclosure/
>
> ___
> 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] Switch CUCM cluster back to no Secure

[daniele visaggio]

 What about upgrading to 11.5? from 11.5 auto-registration in mixed mode is
supported.

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200716-CUCM-Auto-registration-Process-In-Mixed.html


2018-07-12 19:24 GMT+02:00 Reto Gassmann :

> Hallo Group
>
> What are the steps, challanges and risks if I switch a CUCM 10.5 cluster
> from mixed mode back to no secure.
> I have to do that because I need IP phone autregistration back.
>
> Thanks a lot
> Regards Reto
>
>
>
> ___
> 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] BE6K Starter Pack behavior/limitation

[daniele visaggio]

Ops, I misread. Sorry

You bought two starter kits, so 70 CUWL in total.

The answer to both your questions then is yes.

Each cucm asks to the plm all the needed licenses, as per your
configuration.

As long as the total users among the two clusters with less than 10 devices
is <= 70, you are fine.

In theory you could have 70 clusters with one user each 

Regards

2018-04-13 14:15 GMT+02:00 Matthew Loraditch <
mloradi...@heliontechnologies.com>:

> The starter pack is a marketing thing, on the backend it’s just regular
> licenses and can be pooled.
>
> It will just show as 70 licenses as you mentioned and can be shared.
>
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> *From:* cisco-voip  *On Behalf Of *Ki
> Wi
> *Sent:* Friday, April 13, 2018 4:02 AM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] BE6K Starter Pack behavior/limitation
>
>
>
> Hi Group,
>
>
>
> If I purchased 2 x BE6k starter packs of 35 CUWL Standard license for
> installation with 2 different clusters. There are located in 2 different
> part of the world, there's latency issues so we have to do this although
> number of users are low.
>
>
>
> How will it show up in PLM? 70 CUWL STD license? Can it be shared among
> the 2 clusters?
>
>
>
> Let's say 1 cluster will be using 45 CUWL standard licenses while another
> one use like 25 CUWL ? Will this lead to any license violation in the PLM?
>
> --
>
> Regards,
>
> Ki Wi
>
> ___
> 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] ILS PSTN Failover - rerouting on Destination out of order (Q.850; cause=27)

[daniele visaggio]

Hi Dave,

I was aware of that service parameter. Sadly, I don't think it can help in
this case. What I need would be something like "Continue routing on Q.931
Disconnect Cause Code" and giving it the cause code 27 in order to continue
routing.

Instead, I change the Stop Routing on Unallocated Number Flag to False
(default True).

I was expecting this could trigger the pstn failover but my tests showed
otherwise.

Thank you!

2018-03-17 1:28 GMT+01:00 Dave Goodwin <dave.good...@december.net>:

> Daniele, have you tried exploring the service parameter "Stop Routing on
> Q.931 Disconnect Cause Code" at all? I'm not certain it will be useful in
> your scenario, but if you haven't tried it, that may be an option for you.
> It's under Service Parameters > select server > select Cisco CallManager >
> click Advanced button and then search the page for the word cause.
>
> For the other issue you mentioned where rerouting fails when the SIP trunk
> to SME is out of service, are you utilizing OPTIONS ping on the leaf
> cluster towards the SME? In order for the trunk device to be seen as out of
> service and another route selected, you need to make sure OPTIONS ping
> (configurable on a SIP profile) is applied to the SIP trunk.
>
> On Fri, Mar 16, 2018 at 1:29 PM, daniele visaggio <
> visaggio.dani...@gmail.com> wrote:
>
>> Good evening,
>>
>> I want to enable rerouting for enterprise pattern learned via ILS.The
>> scenario is a classic sme plus leaves.
>>
>> Rerouting over pstn does not occur for the following cause codes:
>>
>> - unallocated number
>> - user busy
>> - normal call clearing
>> - destination out of order
>> - service not available
>>
>> I'd like instead to trigger rerouting on Q.850;cause=27 (destination out
>> of order) and on service not available.
>>
>> With cucm 11.5 this doesn't seem possible.
>>
>> Destination out of order is the Q.850 code I get calling a unregistered
>> phone (think srst scenario). In this case rerouting over pstn would be
>> useful.
>>
>> ILS rerouting over pstn does not trigger even if the outgoing sip trunk
>> to sme is out of service ( 503 Service Unavailable or 408 Timeout ).
>>
>> The only scenario in which I managed to trigger the behavior is cac.
>> Playing with locations is the only way I found to reroute over pstn.
>>
>> Any thought on this?
>>
>> thank you
>>
>>
>> ___
>> 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] Customizing called party name/number display for route patterns

[daniele visaggio]

It is a *calling *party transformation css, but if you set the service
parameter 'Apply Transformations on Remote Number' to True, it will be
applied on the called number too.

It just works like this 

Il giorno ven 5 ott 2018 alle ore 21:07 Lelio Fulgenzi 
ha scritto:

> Ciao Daniele,
>
>
>
> Just revisiting this to see how much effort is involved and the impact of
> changing a service parameter.
>
>
>
> You mention “create a calling party transformation pattern”… would I not
> want a “called party transformation pattern” ?
>
>
>
> Calling party A is calling called party B, I want party B’s information to
> be transformed.
>
>
>
> Just wondering before I start digging to deep.
>
>
>
> Lelio
>
>
>
>
>
> ---
>
> *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
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> *From:* daniele visaggio 
> *Sent:* Monday, September 24, 2018 5:50 PM
> *To:* Lelio Fulgenzi 
> *Cc:* cisco-voip voyp list 
> *Subject:* Re: [cisco-voip] Customizing called party name/number display
> for route patterns
>
>
>
> mhhh then try to play with Remote Number Calling Party Transformation CSS.
>
>
>
> Create a calling party transformation pattern to change the number from
> "prefix + number" to just "number". Keep it in a relevant partition and
> assign the CSS to Remote Number Calling Party Transformation CSS on device
> page.
>
> Set the advanced service parameter 'Apply Transformations on Remote
> Number' to True. Default is False.
>
>
>
> This is for cosmetic reasons only. Typical use: user dials e.g. 911 and tp
> globalizes to +911 BUT my user doesn't want to see the + sign  on the
> phone's display. So I discard the + with a calling transformation pattern
> applied there.
>
>
>
> Hope it is helpful.
>
>
>
> Il giorno lun 24 set 2018 alle ore 21:44 Lelio Fulgenzi 
> ha scritto:
>
>
>
> I was afraid you were going to ask that. :(
>
>
>
> It’s not something I’m prepared to change since it’s going to affect
> enterprise wide dialing and how things are displayed.
>
>
>
> I was hoping to be able to do this without modifying that parameter.
>
>
>
> That being said, I did try it on our dev server and rather than keeping
> the original dialed digits, it kept the SIP uri equivalent. Which is
> another problem altogether.
>
>
>
> I might be stuck with prefix showing. :(
>
> *-sent from mobile device-*
>
>
>
> *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 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 24, 2018, at 3:41 PM, daniele visaggio 
> wrote:
>
> Hi,
>
>
>
> did you try setting the *Always Display Original Dialed Number *service
> parameter to True?
>
>
>
>
>
>
>
> Il giorno lun 24 set 2018 alle ore 20:49 Lelio Fulgenzi 
> ha scritto:
>
>
>
> Hmmm, went through the effort of building a route group and route list and
> adding the prefix digits I need on the route group member configuration of
> the route list.
>
>
>
> But still, the prefix digits appear on the display of the dialing device.
> ☹
>
>
>
> How do I get rid of displaying those prefix digits? I was pretty sure this
> was the way.
>
>
>
>
>
> ---
>
> *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
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> *From:* cisco-voip  *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Friday, September 21, 2018 11:20 AM
> *To:* Florian Kroessbacher ; Brian Meade <
> bmead...@vt.edu>
> *Cc:* cisco-voip voyp list 
> *Subject:* Re: [cisco-voip] Customizing called party name/number display
> for route patterns
>
>
>
>
>
> Hmmm, l

Re: [cisco-voip] Customizing called party name/number display for route patterns

[daniele visaggio]

mhhh then try to play with Remote Number Calling Party Transformation CSS.

Create a calling party transformation pattern to change the number from
"prefix + number" to just "number". Keep it in a relevant partition and
assign the CSS to Remote Number Calling Party Transformation CSS on device
page.

Set the advanced service parameter 'Apply Transformations on Remote Number'
to True. Default is False.

This is for cosmetic reasons only. Typical use: user dials e.g. 911 and tp
globalizes to +911 BUT my user doesn't want to see the + sign  on the
phone's display. So I discard the + with a calling transformation pattern
applied there.

Hope it is helpful.

Il giorno lun 24 set 2018 alle ore 21:44 Lelio Fulgenzi 
ha scritto:

>
> I was afraid you were going to ask that. :(
>
> It’s not something I’m prepared to change since it’s going to affect
> enterprise wide dialing and how things are displayed.
>
> I was hoping to be able to do this without modifying that parameter.
>
> That being said, I did try it on our dev server and rather than keeping
> the original dialed digits, it kept the SIP uri equivalent. Which is
> another problem altogether.
>
> I might be stuck with prefix showing. :(
>
> *-sent from mobile device-*
>
>
> *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 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Sep 24, 2018, at 3:41 PM, daniele visaggio 
> wrote:
>
> Hi,
>
> did you try setting the *Always Display Original Dialed Number *service
> parameter to True?
>
>
>
> Il giorno lun 24 set 2018 alle ore 20:49 Lelio Fulgenzi 
> ha scritto:
>
>>
>>
>> Hmmm, went through the effort of building a route group and route list
>> and adding the prefix digits I need on the route group member configuration
>> of the route list.
>>
>>
>>
>> But still, the prefix digits appear on the display of the dialing device.
>> ☹
>>
>>
>>
>> How do I get rid of displaying those prefix digits? I was pretty sure
>> this was the way.
>>
>>
>>
>>
>>
>> ---
>>
>> *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
>>
>>
>>
>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>
>>
>>
>> *From:* cisco-voip  *On Behalf Of *Lelio
>> Fulgenzi
>> *Sent:* Friday, September 21, 2018 11:20 AM
>> *To:* Florian Kroessbacher ; Brian Meade
>> 
>> *Cc:* cisco-voip voyp list 
>> *Subject:* Re: [cisco-voip] Customizing called party name/number display
>> for route patterns
>>
>>
>>
>>
>>
>> Hmmm, looks like another programming option.
>>
>>
>>
>> I was hoping for a built-in option. ☹
>>
>>
>>
>> ---
>>
>> *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
>>
>>
>>
>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>
>>
>>
>> *From:* Florian Kroessbacher 
>> *Sent:* Friday, September 21, 2018 10:52 AM
>> *To:* Brian Meade ; Lelio Fulgenzi 
>> *Cc:* cisco-voip voyp list 
>> *Subject:* Re: [cisco-voip] Customizing called party name/number display
>> for route patterns
>>
>>
>>
>> Hy out there
>>
>> what about CURRI if u were on >10
>>
>> Am 20. Sep. 2018, 23:43 +0200 schrieb Lelio Fulgenzi :
>>
>>
>>
>> I half want to try the old trick of a CTI route point and use forwarding,
>> but not sure I want to intercept that complexity.
>>
>> *-sent from mobile device-*
>>
>>
>>
>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>
>> Com

Re: [cisco-voip] Customizing called party name/number display for route patterns

[daniele visaggio]

Hi,

did you try setting the *Always Display Original Dialed Number *service
parameter to True?



Il giorno lun 24 set 2018 alle ore 20:49 Lelio Fulgenzi 
ha scritto:

>
>
> Hmmm, went through the effort of building a route group and route list and
> adding the prefix digits I need on the route group member configuration of
> the route list.
>
>
>
> But still, the prefix digits appear on the display of the dialing device.
> ☹
>
>
>
> How do I get rid of displaying those prefix digits? I was pretty sure this
> was the way.
>
>
>
>
>
> ---
>
> *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
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> *From:* cisco-voip  *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Friday, September 21, 2018 11:20 AM
> *To:* Florian Kroessbacher ; Brian Meade <
> bmead...@vt.edu>
> *Cc:* cisco-voip voyp list 
> *Subject:* Re: [cisco-voip] Customizing called party name/number display
> for route patterns
>
>
>
>
>
> Hmmm, looks like another programming option.
>
>
>
> I was hoping for a built-in option. ☹
>
>
>
> ---
>
> *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
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> *From:* Florian Kroessbacher 
> *Sent:* Friday, September 21, 2018 10:52 AM
> *To:* Brian Meade ; Lelio Fulgenzi 
> *Cc:* cisco-voip voyp list 
> *Subject:* Re: [cisco-voip] Customizing called party name/number display
> for route patterns
>
>
>
> Hy out there
>
> what about CURRI if u were on >10
>
> Am 20. Sep. 2018, 23:43 +0200 schrieb Lelio Fulgenzi :
>
>
>
> I half want to try the old trick of a CTI route point and use forwarding,
> but not sure I want to intercept that complexity.
>
> *-sent from mobile device-*
>
>
>
> *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 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
> On Sep 20, 2018, at 5:32 PM, Brian Meade  wrote:
>
> For name modification, CUCM doesn't have much.  Probably would need a LUA
> script to update the name in the SIP messaging.
>
>
>
> On Wed, Sep 19, 2018 at 9:33 PM Lelio Fulgenzi  wrote:
>
>
>
> It’s been a while, and I know I can use route lists and route groups to
> customize called party number display but I can’t recall what my options
> are, if any, to customize the called party name display.
>
>
>
> For example, if I dial 4 and want only 4 to continue to display,
> I can do the modifications on the route list/group, ie prefix 999, and
> build appropriate rules on expressway.
>
>
>
> But what if I’d like to display “WebEx Pilot” on the phone when they call
> a particular route pattern?
>
>
>
> I can’t seem to find any option for that.
>
> *-sent from mobile device-*
>
>
>
> *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 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> ___
> 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.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] Cisco Cube drops uri-user in From header with no reason

[daniele visaggio]

Hi list,

Weird issue on ISR4331/K9 running isr4300-universalk9.16.03.06.SPA.bin.

[image: image.png]

Given that, cube has two interfaces, inbound and outbound.

Incoming Invite:

INVITE sip:34949X@10.133.8.120 SIP/2.0
Via: SIP/2.0/UDP 10.133.8.67:58800
;branch=z9hG4bK-d8754z-996d480d1e399c62-1---d8754z-;rport
Max-Forwards: 70
Require: 100rel
Contact: 
To: 
*From: >;tag=e221c36f*
Call-ID: 96588d79-f9481729-0e5fbd03-a83db356
CSeq: 1 INVITE
Session-Expires: 1800
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY, PRACK, REFER,
NOTIFY, OPTIONS
Content-Type: Multipart/mixed;boundary=uniqueBoundary
Supported: timer, resource-priority, replaces
User-Agent: Cisco-SIPDialer/UCCE10.0
Content-Length: 608
.

Outgoing Invite:

INVITE sip: 34949X@10.133.8.108:5060 SIP/2.0
Via: SIP/2.0/TCP 172.20.76.4:5060;branch=z9hG4bK53AD7401
*From: ;tag=C9E25923-243A*
To: 
Date: Tue, 22 Jan 2019 16:05:15 GMT
Call-ID: 56DE4CA5-1D9611E9-BED19CF1-431F5EFE@172.20.76.4
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 1457369213-0496374249-3201015025-1126129406
User-Agent: Cisco-SIPGateway/IOS-16.3.6
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1548173115
Contact: 
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-ID:
1472dea8dda35277a0db64ddc038d48c;remote=
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 243


Given that there are no voice translation rules and there are no voice
class sip-profiles, how is it possible that cube is dropping the uri-user??

Has anyone seen this kind of behavior?

Thank you
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Call Transfer: Inject an arbitrary calling id (ANI) to a JTapi Transfer target

[daniele visaggio]

Good morning.

Diagram:

FINESSE --- UCCE --- CUCM --- SBC --- THIRD PARTY SIP SERVER

*Scenario*:

CUCM receives a call from PSTN. A route pattern sends the call to THIRD
PARTY SIP SERVER which, in turn, transfers the call back to UCCE IVR SCRIPT
via SBC/CUCM.

So we have:

*Transferee*: it's the PSTN caller, i.e. the party ending up being
transferred to the finesse agent

*Transfer Target*: technically it's a CTI route point on CUCM, which
triggers a UCCE script placing the call on a queue. It is the new party
being introduced to the Transferee. In the end it represents a finesse
agent.

*Transferor*: THIRD PARTY SIP SERVER, i.e. the party initiating the
transfer of the Transferee (PSTN caller) to the Transfer target (finesse
agent)

In order to transfer the call, THIRD PARTY SIP SERVER sends a SIP REFER
message to SBC/CUCM.

>From a routing perspective, the transfer works fine. The pstn caller can be
transferred to a finesse agent.

*GOAL*:

we need to alter the calling id seen by UCCE and then by Finesse Agent.
Actually, the calling id (ANI) seen by UCCE/Finesse is the original PSTN
phone number.

There are business reasons why we need to do so.

The crucial point is that THIRD PARTY SIP SERVER sends back to cucm a
custom sip header in the REFER message containing the phone number needed
to be seen by UCCE/Finesse. This can be different from the original PSTN
ANI (e.g. the pstn call is anonymous). This new ANI is dynamic and so it's
not always the same.

I tried with many sip manipulations on the SBC. I placed the new ANI into
the REFER FROM sip header, in the Remote-Party-id, the PAI header. Nothing
worked so far.

Is there a way to set a new ani in this call transfer scenario? I need to
find a way to "convince" cucm to pass the new ANI via Jtapi to
UCCE/IVR/Finesse. Is this possible?

Thanks,

Daniele
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Call Transfer: Inject an arbitrary calling id (ANI) to a JTapi Transfer target

[daniele visaggio]

Thanks, Stephen.

Yes, I'm aware of lua scripting.

Having an sbc in front of the cucm, I already tried to alter the REFER
message in some obvious ways but no luck so far.

I tried also to transform the incoming REFER into a brand new INVITE
(oracle sbc has this feature built-in). Sadly this breaks the routing,
meaning the transfer totally fails.

Before going on with other exotic manipulations, I would like to know in
advance if what I want is even possible...it seems to me cucm is totally
ignoring whatever I put in the REFER.

Best Regards


Il giorno mar 19 nov 2019 alle ore 11:01 Stephen Welsh <
stephen.we...@unifiedfx.com> ha scritto:

> Hi Daniele,
>
> Not my area, but have you looked at using LUA scripts to
> pass-thru/transform SIP headers on UCM:
>
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/9_0_1/sip_t_n/5-sip_pass_thru.html
>
> Thanks
>
> Stephen Welsh
>
> On 19 Nov 2019, at 09:38, daniele visaggio 
> wrote:
>
> Good morning.
>
> Diagram:
>
> FINESSE --- UCCE --- CUCM --- SBC --- THIRD PARTY SIP SERVER
>
> *Scenario*:
>
> CUCM receives a call from PSTN. A route pattern sends the call to THIRD
> PARTY SIP SERVER which, in turn, transfers the call back to UCCE IVR SCRIPT
> via SBC/CUCM.
>
> So we have:
>
> *Transferee*: it's the PSTN caller, i.e. the party ending up being
> transferred to the finesse agent
>
> *Transfer Target*: technically it's a CTI route point on CUCM, which
> triggers a UCCE script placing the call on a queue. It is the new party
> being introduced to the Transferee. In the end it represents a finesse
> agent.
>
> *Transferor*: THIRD PARTY SIP SERVER, i.e. the party initiating the
> transfer of the Transferee (PSTN caller) to the Transfer target (finesse
> agent)
>
> In order to transfer the call, THIRD PARTY SIP SERVER sends a SIP REFER
> message to SBC/CUCM.
>
> From a routing perspective, the transfer works fine. The pstn caller can
> be transferred to a finesse agent.
>
> *GOAL*:
>
> we need to alter the calling id seen by UCCE and then by Finesse Agent.
> Actually, the calling id (ANI) seen by UCCE/Finesse is the original PSTN
> phone number.
>
> There are business reasons why we need to do so.
>
> The crucial point is that THIRD PARTY SIP SERVER sends back to cucm a
> custom sip header in the REFER message containing the phone number needed
> to be seen by UCCE/Finesse. This can be different from the original PSTN
> ANI (e.g. the pstn call is anonymous). This new ANI is dynamic and so it's
> not always the same.
>
> I tried with many sip manipulations on the SBC. I placed the new ANI into
> the REFER FROM sip header, in the Remote-Party-id, the PAI header. Nothing
> worked so far.
>
> Is there a way to set a new ani in this call transfer scenario? I need to
> find a way to "convince" cucm to pass the new ANI via Jtapi to
> UCCE/IVR/Finesse. Is this possible?
>
> Thanks,
>
> Daniele
> ___
> 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] Call Transfer: Inject an arbitrary calling id (ANI) to a JTapi Transfer target

[daniele visaggio]

Hi Kent,

even though we are talking about a UCCE deployment, we are still stuck with
IP IVR. This means no CVP for the time being.

The only way I can pass this kind of metadata to the IVR/ICM/UCCE world is
through CTI/Jtapi, afaik.

It is not clear to me the precise logic used by cucm to translate between
sip and Jtapi.

Any hints in this regard?

Thanks!

Il giorno mar 19 nov 2019 alle ore 15:23 Kent Roberts  ha
scritto:

> Did something similar to this in the SBC at the dial-peer level with
> number translations, when UCCE first didn’t support improper ANI many moons
> ago...
>
> If you can grab the inbound call at the dial-peer level (or via the return
> carrier). And send it in to its own CUCM SIP config, then you can do
> anything you want with it.
>
> I believe your stuck replacing ANI, as CUCM may not forward all the sip
> headers…
>
> Have you tried to turn up the  CVP SIP  debugs, and see if the headers get
> passed?
>
>
> On Nov 19, 2019, at 3:19 AM, daniele visaggio 
> wrote:
>
> Thanks, Stephen.
>
> Yes, I'm aware of lua scripting.
>
> Having an sbc in front of the cucm, I already tried to alter the REFER
> message in some obvious ways but no luck so far.
>
> I tried also to transform the incoming REFER into a brand new INVITE
> (oracle sbc has this feature built-in). Sadly this breaks the routing,
> meaning the transfer totally fails.
>
> Before going on with other exotic manipulations, I would like to know in
> advance if what I want is even possible...it seems to me cucm is totally
> ignoring whatever I put in the REFER.
>
> Best Regards
>
>
> Il giorno mar 19 nov 2019 alle ore 11:01 Stephen Welsh <
> stephen.we...@unifiedfx.com> ha scritto:
>
>> Hi Daniele,
>>
>> Not my area, but have you looked at using LUA scripts to
>> pass-thru/transform SIP headers on UCM:
>>
>>
>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/9_0_1/sip_t_n/5-sip_pass_thru.html
>>
>> Thanks
>>
>> Stephen Welsh
>>
>> On 19 Nov 2019, at 09:38, daniele visaggio 
>> wrote:
>>
>> Good morning.
>>
>> Diagram:
>>
>> FINESSE --- UCCE --- CUCM --- SBC --- THIRD PARTY SIP SERVER
>>
>> *Scenario*:
>>
>> CUCM receives a call from PSTN. A route pattern sends the call to THIRD
>> PARTY SIP SERVER which, in turn, transfers the call back to UCCE IVR SCRIPT
>> via SBC/CUCM.
>>
>> So we have:
>>
>> *Transferee*: it's the PSTN caller, i.e. the party ending up being
>> transferred to the finesse agent
>>
>> *Transfer Target*: technically it's a CTI route point on CUCM, which
>> triggers a UCCE script placing the call on a queue. It is the new party
>> being introduced to the Transferee. In the end it represents a finesse
>> agent.
>>
>> *Transferor*: THIRD PARTY SIP SERVER, i.e. the party initiating the
>> transfer of the Transferee (PSTN caller) to the Transfer target (finesse
>> agent)
>>
>> In order to transfer the call, THIRD PARTY SIP SERVER sends a SIP REFER
>> message to SBC/CUCM.
>>
>> From a routing perspective, the transfer works fine. The pstn caller can
>> be transferred to a finesse agent.
>>
>> *GOAL*:
>>
>> we need to alter the calling id seen by UCCE and then by Finesse Agent.
>> Actually, the calling id (ANI) seen by UCCE/Finesse is the original PSTN
>> phone number.
>>
>> There are business reasons why we need to do so.
>>
>> The crucial point is that THIRD PARTY SIP SERVER sends back to cucm a
>> custom sip header in the REFER message containing the phone number needed
>> to be seen by UCCE/Finesse. This can be different from the original PSTN
>> ANI (e.g. the pstn call is anonymous). This new ANI is dynamic and so it's
>> not always the same.
>>
>> I tried with many sip manipulations on the SBC. I placed the new ANI into
>> the REFER FROM sip header, in the Remote-Party-id, the PAI header. Nothing
>> worked so far.
>>
>> Is there a way to set a new ani in this call transfer scenario? I need to
>> find a way to "convince" cucm to pass the new ANI via Jtapi to
>> UCCE/IVR/Finesse. Is this possible?
>>
>> Thanks,
>>
>> Daniele
>> ___
>> 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.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Native Call Queuing on UCM 12.5 with SIP Trunks

[daniele visaggio]

Hi,

Try to check if your trunk has access to moh resources.

This means your trunk needs to be placed inside a device pool whose mrgl
contains at least one mrg containing at least one moh server.

Sip trunk > device pool > mrgl > mrg > moh server.

Additional test: call some external party through your sip trunk and try to
put called party on hold. Does the called party hear moh?

Regards

On Mon, Dec 2, 2019, 07:54 Dana Tong  wrote:

> Sorry forgot to mention that Supplementary services such as call forward
> all, transfer, hold/retrieve, and conferencing work fine.
>
>
>
>
>
>
>
> *From:* Dana Tong
> *Sent:* Monday, 2 December 2019 4:37 PM
> *To:* cisco-voip@puck.nether.net
> *Subject:* Native Call Queuing on UCM 12.5 with SIP Trunks
>
>
>
> Hi all,
>
>
>
> This being back on the tools is doing my head in. I think I’ve been away
> too long.
>
>
>
> So I have configured native call queuing on UCM 12.5.x
>
> Internal calls queue fine. The initial announcement plays. Period
> announcements work and the MOH is fine in between.
>
>
>
> External calls hear the initial announcement.
>
> There is no MOH after the announcement and the external user has ring-back
> tone.
>
> There is no periodic announcement.
>
>
>
> Any thoughts on why internal is okay and external is not working? Is it
> relating to SIP supplementary services?
>
>
>
> Cheers
>
> Dana
>
>
> ___
> 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] Inbound MGCP call dead-air

[daniele visaggio]

can you do a "show isdn status" ?

Is the t1 completely up?

Il giorno gio 19 dic 2019 alle ore 03:14 Jonathan Charles 
ha scritto:

> We rebooted the CCM cluster and the problem persisted...
>
> Traces show no sign of the call int he calllog...
>
>
>
> Jonathan
>
> On Wed, Dec 18, 2019 at 8:00 PM Ryan Huff  wrote:
>
>> Have you pulled a ccm trace and debug voice ccapi inout, to verif you’re
>> not seeing any weirdness there?
>>
>> “no mgcp / mgcp” has been known to fix weird things; I assume you’ve
>> tried that though.
>>
>> Sent from my iPhone
>>
>> On Dec 18, 2019, at 19:59, Jonathan Charles  wrote:
>>
>> 
>> Inbound call (to x2475) on an MGCP T1-CAS  E Wink
>>
>> Gateway is a 4331 running 16.06.02.SPA, CCM is 11.5.1.2900-21
>>
>> Get dead air and see no MGCP setup message to CCM, after 60 seconds, call
>> times out (debug vpm signal and mgcp packet, below):
>>
>> 006469: Dec 18 18:23:38.037: htsp_dsp_message: SEND_SIG_STATUS: state=0xC
>> timestamp=35130 systime=1042275951
>> 006470: Dec 18 18:23:38.037: htsp_process_event: [0/1/1:1(21), EM_ONHOOK,
>> E_DSP_SIG_1100]em_onhook_offhook
>> 006471: Dec 18 18:23:38.037: htsp_timer - 50 msec
>> 006472: Dec 18 18:23:38.088: htsp_process_event: [0/1/1:1(21),
>> EM_QUALIFY_SEIZURE,
>> E_HTSP_EVENT_TIMER]em_qualify_seizure_timeouthtsp_setup_ind
>> 006473: Dec 18 18:23:38.088: [0/1/1:1(21)] get_local_station_id calling
>> num= calling name= calling time=12/18 18:23  orig called=
>> 006474: Dec 18 18:23:38.088: htsp_timer - 3000 msec
>> 006475: Dec 18 18:23:38.090: htsp_process_event: [0/1/1:1(21),
>> EM_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]em_wait_setup_ack_get_ack
>> 006476: Dec 18 18:23:38.090: htsp_timer_stop interdigit timer cfgd to 3000
>> 006477: Dec 18 18:23:38.090: htsp_timer2 - 127 msec
>> 006478: Dec 18 18:23:38.217: htsp_process_event: [0/1/1:1(21),
>> EM_WAIT_SETUP_ACK, E_HTSP_EVENT_TIMER2]em_wait_prewink_timer
>> 006479: Dec 18 18:23:38.217: em_offhook (0)vnm_dsp_set_sig_state:[recEive
>> and transMit0/1/1:1(21)] set signal state = 0x8em_onhook
>> (200)vnm_dsp_set_sig_state:[recEive and transMit0/1/1:1(21)] set signal
>> state = 0x0
>> 006480: Dec 18 18:23:38.611: htsp_digit_ready: digit = 32
>> 006481: Dec 18 18:23:38.611: htsp_process_event: [0/1/1:1(21),
>> EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect
>> 006482: Dec 18 18:23:38.751: htsp_digit_ready: digit = 34
>> 006483: Dec 18 18:23:38.751: htsp_process_event: [0/1/1:1(21),
>> EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect
>> 006484: Dec 18 18:23:38.892: htsp_digit_ready: digit = 37
>> 006485: Dec 18 18:23:38.892: htsp_process_event: [0/1/1:1(21),
>> EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect
>> 006486: Dec 18 18:23:39.032: htsp_digit_ready: digit = 35
>> 006487: Dec 18 18:23:39.032: htsp_process_event: [0/1/1:1(21),
>> EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect
>>
>> 006488: Dec 18 18:23:41.335: MGCP Packet sent to 10.48.41.81:2427--->
>> NTFY 331838278 *@ORHC-VG4331-01.orhcnet.local MGCP 0.1
>> X: 0
>> O:
>> <---
>>
>> 006489: Dec 18 18:23:41.337: MGCP Packet received from 10.48.41.81:2427
>> --->
>> 200 331838278
>> <---
>>
>> 006490: Dec 18 18:23:56.336: MGCP Packet sent to 10.48.41.81:2427--->
>> NTFY 331838279 *@ORHC-VG4331-01.orhcnet.local MGCP 0.1
>> X: 0
>> O:
>> <---
>>
>> 006491: Dec 18 18:23:56.337: MGCP Packet received from 10.48.41.81:2427
>> --->
>> 200 331838279
>> <---
>>
>> 006492: Dec 18 18:24:11.336: MGCP Packet sent to 10.48.41.81:2427--->
>> NTFY 331838280 *@ORHC-VG4331-01.orhcnet.local MGCP 0.1
>> X: 0
>> O:
>> <---
>>
>> 006493: Dec 18 18:24:11.337: MGCP Packet received from 10.48.41.81:2427
>> --->
>> 200 331838280
>> <---
>>
>> 006494: Dec 18 18:24:26.336: MGCP Packet sent to 10.48.41.81:2427--->
>> NTFY 331838281 *@ORHC-VG4331-01.orhcnet.local MGCP 0.1
>> X: 0
>> O:
>> <---
>>
>> 006495: Dec 18 18:24:26.337: MGCP Packet received from 10.48.41.81:2427
>> --->
>> 200 331838281
>> <---
>>
>> Configs:
>>
>>
>> controller T1 0/1/1
>>  framing sf
>>  clock source line primary
>>  linecode ami
>>  cablelength long 0db
>>  ds0-group 1 timeslots 1-24 type e
>>  description Local T1 CAS
>> !
>> mgcp
>> mgcp call-agent 10.48.41.80 2427 service-type mgcp version 0.1
>> mgcp rtp unreachable timeout 1000 action notify
>> mgcp modem passthrough voip mode nse
>> mgcp package-capability mf-package
>> mgcp package-capability rtp-package
>> mgcp package-capability sst-package
>> mgcp package-capability pre-package
>> mgcp package-capability fm-package
>> no mgcp package-capability res-package
>> no mgcp timer receive-rtcp
>> mgcp sdp simple
>> mgcp bind control source-interface GigabitEthernet0/0/0
>> mgcp bind media source-interface GigabitEthernet0/0/0
>> mgcp behavior rsip-range tgcp-only
>> mgcp behavior comedia-role none
>> mgcp behavior comedia-check-media-src disable
>> mgcp behavior comedia-sdp-force disable
>> !
>> ccm-manager fallback-mgcp
>> ccm-manager redundant-host 10.48.41.81
>> ccm-manager mgcp
>> no ccm-manager fax protocol cisco
>> ccm-manager