Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: CUCM MTP and g729 (Jason Aarons (AM))
2. Re: CUC Cluster replication issues ([email protected])
3. Re: CUC Cluster replication issues (Mike Lydick)
4. Re: CUCM MTP and g729 (Peter Slow)
5. Re: FWD one Ext to Another (Erick B.)
6. 9.1 Upgrade Times (Matthew Loraditch)
----------------------------------------------------------------------
Message: 1
Date: Sat, 12 Jan 2013 12:45:23 -0500
From: "Jason Aarons (AM)" <[email protected]>
To: Ryan Ratliff <[email protected]>, Anthony Holloway
<[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<4e38db0a1959b04c8c83edcf069b53ed0d2c718...@usispclexdb01.na.didata.local>
Content-Type: text/plain; charset="windows-1252"
I got a customer running 8.5.1SU2 and it's not doing IP Voice Media Streaming
App MTP with Pass-Thru. Just had a big TAC case with T38 and took awhile for
the TAC lead to come to that conclusion. A IOS Software MTP was needed to fix
it.
I've looked previously and haven't found any details about fix/improvement (eg
what's new) around IP Voice Media Streaming App in newer versions.
From: [email protected]
[mailto:[email protected]] On Behalf Of Ryan Ratliff
Sent: Friday, January 11, 2013 5:03 PM
To: Anthony Holloway
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM MTP and g729
Check the capabilities the MTP advertises to CUCM when it registers. At some
point (8.5 maybe?) IP Voice Media Streaming App began supporting audio
passthrough, which would explain what you are seeing.
-Ryan
On Jan 11, 2013, at 4:36 PM, Anthony Holloway
<[email protected]<mailto:[email protected]>> wrote:
Thanks Pete. I'll see if I can answer or reply to each of your questions or
points.
"are you SURE this isn't just a device hearing g.729 hold music while you've
got or had the Duplex Streaming service parameter enabled?"
No, this is a call from an analog device to a PSTN device, and the call is well
established and in progress with two way audio.
"Do you have the skinny signalling to go with it showing what it was
specifically set up for use as?"
I'm not sure I understand where the skinny signaling comes in. The VG224 is
MGCP, the SBC is a SIP trunk, and the MTP is local to the CUCM. Could you help
me understand? I do have traces off the CUCM if that answers your question.
"Also, I beleive MGCP Endpoints have an initial "state" when they begin call
setup. i think not using g.729 actually entails a switch from 729 to another
codec, and perhaps a small delay is causing some packets to be transmitted
using g.729? maybe? that's a complete stretch but who knows =)"
Again, this is an established call. I get the call setup, verify two way
audio, and then take the capture.
"I don't think you're really goign to get an answer unless you can recreate the
issue"
I can. I have the VG224 in my cubicle. Check out the adapter I'm using!
Photo attached. =)
"and we can see traces."
I can't upload traces to the list, but if this goes to a TAC case, I will
certainly give them up at that time.
"you'll also want a packet capture of the registration of the media device"
This is a good idea. I'll give it a try and see what it reports.
"you coudl be doing duplex audio while one of those is playing"
I'm not sure what that means, or how that would even work, but you sound
excited. =)
"anyway, can you reproduce it"
Yes. I can reproduce it at will.
Thanks for asking the questions and commenting.
On Fri, Jan 11, 2013 at 3:24 PM, Peter Slow
<[email protected]<mailto:[email protected]>> wrote:
PS> ..Also, are you SURE this isn't just a device hearing g.729 hold
music while you've got or had the Duplex Streaming service parameter
enabled? ...'Cause that would totally explain this packet capture. Do
you have the skinny signalling to go with it showing what it was
specifically set up for use as?
Also, I beleive MGCP Endpoints have an initial "state" when they begin
call setup. i think not using g.729 actually entails a switch from 729
to another codec, and perhaps a small delay is causing some packets to
be transmitted using g.729? maybe? that's a complete stretch but who
knows =)
I don't think you're really goign to get an answer unless you can
recreate the issue and we can see traces. you'll also want a packet
capture of the registration of the media device, so if you can make
the MTP register to a different callmanager than what it's running on,
using its CUCM group, we could take a look at what capabilities it was
registering with and if it says it supports 729 now =) ..you'll wnat
to look at the skinny registration of the MTP, ANN ooh, ANN
announcements are in 7.29 also, i think? you coudl be doing duplex
audio while one of those is playing =)....
anyway, can you reproduce it or verify or deny any of those guesses?
Very Interesting,
-Pete
On Fri, Jan 11, 2013 at 4:08 PM, Anthony Holloway
<[email protected]<mailto:avholloway%[email protected]>>
wrote:
>
> Hey Wes,
>
> The packet capture was done on the CUCM itself via CLI command: "utils
> network capture". Also, I filtered the capture to traffic only coming from
> the VG224, which is why you do not see any other streams. It was, however,
> going to our SBC. So the call flow was: Analog Phone > VG224 > CUCM (MTP) >
> SBC > PSTN.
>
> The negotiated CODEC was in fact g729, and both sides support it. The MGCP
> SDP shows g729 and the SBC sends back g729 in the SIP SDP. The only thing
> that is different in caps is DTMF. MGCP was trying 100 while SBC wanted to
> do 101.
>
> As for the garble: I wasn't experiencing any voice quality issues that I
> could hear, but I was experiencing double DTMF going out to the PSTN. Not
> sure if an artifact of the MTP, or simply a misonconfiguration on the
> VG224's MGCP package. Like I said it's the fm package I was missing that
> ultimately fixed the issue. The MTP is no longer used, and the double DTMF
> is gone. I didn't find very much info on what the fm packages does, only
> that it fixes DTMF and Faxing issues when communicating with a SIP device.
>
> Thanks for the late Friday afternoon reply Wes.
>
> On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk
> <[email protected]<mailto:[email protected]>> wrote:
>>
>> Interesting observations.
>>
>> I am not aware of any changes around CM's software MTP only doing G.711.
>>
>> The packet capture shows RTP coming into(?) to the MTP. I do not see any
>> sign of anything egressing the MTP.
>>
>> ccm has internal logic that attempts to connect RTP streams even if codec
>> negotiation fails. This is controlled by a service parameter. You may be
>> seeing an artifact of this behavior where no codec was common but the
>> streams attempted to setup anyway. Streaming codecs to the MTP that it does
>> not support typically results in garble or silence on the egress leg.
>>
>> /wes
>>
>>
>> On Jan 11, 2013, at 3:11 PM, Anthony Holloway wrote:
>>
>> Hi All,
>>
>> I have a wireshark capture off of my CUCM 8.6(2) which shows that it is
>> receiving a g729 audio stream from my VG224.
>>
>> Long story short, according to the CUCM SRND, the CUCM MTP can only
>> terminate g711, and yet, attached is a screenshot of the wireshark capture
>> which clearly shows it terminating g729.
>>
>> What piece of this puzzle am I missing? Also, the CUCM traces read like
>> the MTP is being invoked on that CUCM. It's due to the lack of the fm
>> package on my VG224 and a mismatch in DTMF to the PSTN (SIP). I had a fun
>> time resolving that, as you can probably imagine.
>>
>> Thanks and Happy Friday!
>>
>>
>>
>> <cucm-mtp-g729-redacted.png><cucm-mtp-redacted.png><cucm-sub02b-redacted.png>_______________________________________________
>> cisco-voip mailing list
>> [email protected]<mailto:[email protected]>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]<mailto:[email protected]>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/e4c67d11/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 12 Jan 2013 20:10:27 +0000
From: [email protected]
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CUC Cluster replication issues
Message-ID:
<255f57bb43f894468da6bd4f2f5dd1ce6490d...@rstn-s-mbx01.net.its.l-3com.com>
Content-Type: text/plain; charset="us-ascii"
Both are synch'd
PUB:
admin:utils ntp status
ntpd (pid 18803) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
*141.199.251.254 166.20.167.29 3 u - 1024 377 0.495 10.195 23.315
+141.199.251.253 166.20.167.29 3 u 114 1024 377 0.562 -11.931 23.057
synchronised to NTP server (141.199.251.254) at stratum 4
time correct to within 135 ms
polling server every 1024 s
Current time in UTC is : Sat Jan 12 20:06:23 UTC 2013
Current time in America/New_York is : Sat Jan 12 15:06:23 EST 2013
SUB:
admin:utils ntp status
ntpd (pid 18919) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
*172.20.208.7 141.199.251.254 4 u 577 1024 377 2.833 -1.293 0.037
synchronised to NTP server (172.20.208.7) at stratum 5
time correct to within 133 ms
polling server every 1024 s
Current time in UTC is : Sat Jan 12 20:07:17 UTC 2013
Current time in America/New_York is : Sat Jan 12 15:07:17 EST 2013
Bill
From: [email protected] [mailto:[email protected]]
Sent: Saturday, January 12, 2013 1:18 PM
To: Hendrix, George (Bill) @ NSS - STRATIS
Subject: RE: [cisco-voip] CUC Cluster replication issues
Check your NTP, high stratum or unsynchronized or insane NTP clocks can cause
Unity Connection Database replication to fail. Fix the ntp status and resolves
the issue
Utils ntp status
Looking for ntp to have a peer and the state is synch'd
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Saturday, January 12, 2013 7:46 AM
To: [email protected]<mailto:[email protected]>
Subject: [cisco-voip] CUC Cluster replication issues
Hey Guys,
Noticed we were having Unity Connection cluster issues when I logged. I went
ahead and restarted the Pub first and then the Sub as this was the fix that TAC
gave me last time we had a similar issue. However, it still having issues.
Please see output below from each server.
Publisher:
admin:show cuc cluster status
Server Name Member ID Server State Internal State
Reason
--------------------- --------- ------------ ----------------------------
------
rstn-2fs-cuc-pub01 0 Primary Pri Active
Normal
annjct-2720-cuc-sub01 1 Primary Sec Act Primary Disconnected
Normal
Database replication is not active
admin:
Subscriber:
admin:show cuc cluster status
Server Name Member ID Server State Internal State Reason
--------------------- --------- ---------------------- -------------- ------
rstn-2fs-cuc-pub01 0 Split Brain Resolution Pri SBR Normal
annjct-2720-cuc-sub01 1 Secondary Sec Active Normal
SERVER ID STATE STATUS QUEUE CONNECTION CHANGED
-----------------------------------------------------------------------
g_ciscounity_pub 100 Active Dropped 568373 Jan 12 07:38:42
g_ciscounity_sub1 101 Active Local 0
admin:
Any ideas of what to do next?
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/4103a824/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 12 Jan 2013 15:49:34 -0500
From: "Mike Lydick" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [cisco-voip] CUC Cluster replication issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Are the NTP server windows based NTP? I have had many issues using windows
NTP because the clocks slip. So the effect will be that NTP will slip in/out
of sync.
From: [email protected] [mailto:[email protected]]
Sent: Saturday, January 12, 2013 3:10 PM
To: [email protected]; [email protected]
Subject: RE: [cisco-voip] CUC Cluster replication issues
Both are synch'd
PUB:
admin:utils ntp status
ntpd (pid 18803) is running...
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*141.199.251.254 166.20.167.29 3 u - 1024 377 0.495 10.195
23.315
+141.199.251.253 166.20.167.29 3 u 114 1024 377 0.562 -11.931
23.057
synchronised to NTP server (141.199.251.254) at stratum 4
time correct to within 135 ms
polling server every 1024 s
Current time in UTC is : Sat Jan 12 20:06:23 UTC 2013
Current time in America/New_York is : Sat Jan 12 15:06:23 EST 2013
SUB:
admin:utils ntp status
ntpd (pid 18919) is running...
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*172.20.208.7 141.199.251.254 4 u 577 1024 377 2.833 -1.293
0.037
synchronised to NTP server (172.20.208.7) at stratum 5
time correct to within 133 ms
polling server every 1024 s
Current time in UTC is : Sat Jan 12 20:07:17 UTC 2013
Current time in America/New_York is : Sat Jan 12 15:07:17 EST 2013
Bill
From: [email protected] [mailto:[email protected]]
Sent: Saturday, January 12, 2013 1:18 PM
To: Hendrix, George (Bill) @ NSS - STRATIS
Subject: RE: [cisco-voip] CUC Cluster replication issues
Check your NTP, high stratum or unsynchronized or insane NTP clocks can
cause Unity Connection Database replication to fail. Fix the ntp status and
resolves the issue
Utils ntp status
Looking for ntp to have a peer and the state is synch'd
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Saturday, January 12, 2013 7:46 AM
To: [email protected]
Subject: [cisco-voip] CUC Cluster replication issues
Hey Guys,
Noticed we were having Unity Connection cluster issues when I logged. I
went ahead and restarted the Pub first and then the Sub as this was the fix
that TAC gave me last time we had a similar issue. However, it still having
issues. Please see output below from each server.
Publisher:
admin:show cuc cluster status
Server Name Member ID Server State Internal State
Reason
--------------------- --------- ------------ ----------------------------
------
rstn-2fs-cuc-pub01 0 Primary Pri Active
Normal
annjct-2720-cuc-sub01 1 Primary Sec Act Primary Disconnected
Normal
Database replication is not active
admin:
Subscriber:
admin:show cuc cluster status
Server Name Member ID Server State Internal State
Reason
--------------------- --------- ---------------------- --------------
------
rstn-2fs-cuc-pub01 0 Split Brain Resolution Pri SBR
Normal
annjct-2720-cuc-sub01 1 Secondary Sec Active
Normal
SERVER ID STATE STATUS QUEUE CONNECTION CHANGED
-----------------------------------------------------------------------
g_ciscounity_pub 100 Active Dropped 568373 Jan 12 07:38:42
g_ciscounity_sub1 101 Active Local 0
admin:
Any ideas of what to do next?
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/73c22f6e/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 12 Jan 2013 16:43:36 -0500
From: Peter Slow <[email protected]>
To: "Jason Aarons (AM)" <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ryan, that's awesome, didn't know that.
Anthony, it looks like the pass through codec Ryan is talking about is
registered as codec number 258. Look for that in the capabilitiesresponse
message.
Sent from my iPad
On Jan 12, 2013, at 12:45 PM, "Jason Aarons (AM)"
<[email protected]> wrote:
> I got a customer running 8.5.1SU2 and it?s not doing IP Voice Media Streaming
> App MTP with Pass-Thru. Just had a big TAC case with T38 and took awhile for
> the TAC lead to come to that conclusion. A IOS Software MTP was needed to
> fix it.
>
> I?ve looked previously and haven?t found any details about fix/improvement
> (eg what?s new) around IP Voice Media Streaming App in newer versions.
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Ryan Ratliff
> Sent: Friday, January 11, 2013 5:03 PM
> To: Anthony Holloway
> Cc: Cisco VoIP Group
> Subject: Re: [cisco-voip] CUCM MTP and g729
>
>
>
> Check the capabilities the MTP advertises to CUCM when it registers. At some
> point (8.5 maybe?) IP Voice Media Streaming App began supporting audio
> passthrough, which would explain what you are seeing.
>
> -Ryan
>
> On Jan 11, 2013, at 4:36 PM, Anthony Holloway
> <[email protected]> wrote:
>
> Thanks Pete. I'll see if I can answer or reply to each of your questions or
> points.
>
> "are you SURE this isn't just a device hearing g.729 hold music while you've
> got or had the Duplex Streaming service parameter enabled?"
> No, this is a call from an analog device to a PSTN device, and the call is
> well established and in progress with two way audio.
>
> "Do you have the skinny signalling to go with it showing what it was
> specifically set up for use as?"
> I'm not sure I understand where the skinny signaling comes in. The VG224 is
> MGCP, the SBC is a SIP trunk, and the MTP is local to the CUCM. Could you
> help me understand? I do have traces off the CUCM if that answers your
> question.
>
> "Also, I beleive MGCP Endpoints have an initial "state" when they begin call
> setup. i think not using g.729 actually entails a switch from 729 to another
> codec, and perhaps a small delay is causing some packets to be transmitted
> using g.729? maybe? that's a complete stretch but who knows =)"
> Again, this is an established call. I get the call setup, verify two way
> audio, and then take the capture.
>
> "I don't think you're really goign to get an answer unless you can recreate
> the issue"
> I can. I have the VG224 in my cubicle. Check out the adapter I'm using!
> Photo attached. =)
>
> "and we can see traces."
> I can't upload traces to the list, but if this goes to a TAC case, I will
> certainly give them up at that time.
>
> "you'll also want a packet capture of the registration of the media device"
> This is a good idea. I'll give it a try and see what it reports.
>
> "you coudl be doing duplex audio while one of those is playing"
> I'm not sure what that means, or how that would even work, but you sound
> excited. =)
>
> "anyway, can you reproduce it"
> Yes. I can reproduce it at will.
>
> Thanks for asking the questions and commenting.
>
>
> On Fri, Jan 11, 2013 at 3:24 PM, Peter Slow <[email protected]> wrote:
> PS> ..Also, are you SURE this isn't just a device hearing g.729 hold
> music while you've got or had the Duplex Streaming service parameter
> enabled? ...'Cause that would totally explain this packet capture. Do
> you have the skinny signalling to go with it showing what it was
> specifically set up for use as?
>
> Also, I beleive MGCP Endpoints have an initial "state" when they begin
> call setup. i think not using g.729 actually entails a switch from 729
> to another codec, and perhaps a small delay is causing some packets to
> be transmitted using g.729? maybe? that's a complete stretch but who
> knows =)
>
> I don't think you're really goign to get an answer unless you can
> recreate the issue and we can see traces. you'll also want a packet
> capture of the registration of the media device, so if you can make
> the MTP register to a different callmanager than what it's running on,
> using its CUCM group, we could take a look at what capabilities it was
> registering with and if it says it supports 729 now =) ..you'll wnat
> to look at the skinny registration of the MTP, ANN ooh, ANN
> announcements are in 7.29 also, i think? you coudl be doing duplex
> audio while one of those is playing =)....
>
> anyway, can you reproduce it or verify or deny any of those guesses?
>
> Very Interesting,
> -Pete
>
>
>
> On Fri, Jan 11, 2013 at 4:08 PM, Anthony Holloway
> <[email protected]> wrote:
> >
> > Hey Wes,
> >
> > The packet capture was done on the CUCM itself via CLI command: "utils
> > network capture". Also, I filtered the capture to traffic only coming from
> > the VG224, which is why you do not see any other streams. It was, however,
> > going to our SBC. So the call flow was: Analog Phone > VG224 > CUCM (MTP) >
> > SBC > PSTN.
> >
> > The negotiated CODEC was in fact g729, and both sides support it. The MGCP
> > SDP shows g729 and the SBC sends back g729 in the SIP SDP. The only thing
> > that is different in caps is DTMF. MGCP was trying 100 while SBC wanted to
> > do 101.
> >
> > As for the garble: I wasn't experiencing any voice quality issues that I
> > could hear, but I was experiencing double DTMF going out to the PSTN. Not
> > sure if an artifact of the MTP, or simply a misonconfiguration on the
> > VG224's MGCP package. Like I said it's the fm package I was missing that
> > ultimately fixed the issue. The MTP is no longer used, and the double DTMF
> > is gone. I didn't find very much info on what the fm packages does, only
> > that it fixes DTMF and Faxing issues when communicating with a SIP device.
> >
> > Thanks for the late Friday afternoon reply Wes.
> >
> > On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk <[email protected]> wrote:
> >>
> >> Interesting observations.
> >>
> >> I am not aware of any changes around CM's software MTP only doing G.711.
> >>
> >> The packet capture shows RTP coming into(?) to the MTP. I do not see any
> >> sign of anything egressing the MTP.
> >>
> >> ccm has internal logic that attempts to connect RTP streams even if codec
> >> negotiation fails. This is controlled by a service parameter. You may be
> >> seeing an artifact of this behavior where no codec was common but the
> >> streams attempted to setup anyway. Streaming codecs to the MTP that it
> >> does
> >> not support typically results in garble or silence on the egress leg.
> >>
> >> /wes
> >>
> >>
> >> On Jan 11, 2013, at 3:11 PM, Anthony Holloway wrote:
> >>
> >> Hi All,
> >>
> >> I have a wireshark capture off of my CUCM 8.6(2) which shows that it is
> >> receiving a g729 audio stream from my VG224.
> >>
> >> Long story short, according to the CUCM SRND, the CUCM MTP can only
> >> terminate g711, and yet, attached is a screenshot of the wireshark capture
> >> which clearly shows it terminating g729.
> >>
> >> What piece of this puzzle am I missing? Also, the CUCM traces read like
> >> the MTP is being invoked on that CUCM. It's due to the lack of the fm
> >> package on my VG224 and a mismatch in DTMF to the PSTN (SIP). I had a fun
> >> time resolving that, as you can probably imagine.
> >>
> >> Thanks and Happy Friday!
> >>
> >>
> >>
> >> <cucm-mtp-g729-redacted.png><cucm-mtp-redacted.png><cucm-sub02b-redacted.png>_______________________________________________
> >> cisco-voip mailing list
> >> [email protected]
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > [email protected]
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> itevomcid
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/b2df58d5/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 12 Jan 2013 23:22:27 -0600
From: "Erick B." <[email protected]>
To: David Zhars <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] FWD one Ext to Another
Message-ID:
<CAHSnBQyyhz7b=lhzhtan_a0hfciyt73govzgwnhnmxnq8cg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes, in unity add 1212 as alternate extension to the 1702 users mailbox and
any calls for 1702 or 1212 will go to that users mailbox. The ** transfer
method will still work with this to (assuming the ** pattern sends call
those calls to voicemail directly on your setup)
I would use a translation pattern on CUCM to route calls from 1212 to 1702
unless you need to keep 1212 on a phone/etc for some reason.
On Fri, Jan 11, 2013 at 6:49 PM, David Zhars <[email protected]> wrote:
> So my confusion has to extend from not having a solid understanding of an
> "alternate extension" in Unity. I assumed (there's that word) that
> applying 1212 as an alternate ext to 1702, would mean the user would STILL
> have to login SEPARATELY to both VM boxes to get messages. Are you saying
> that if I add 1212 as an alternate, he needs only check messages for ext
> 1702, and anything that went to 1212 would be in the 1702 box?? Cause that
> would be way easy!
>
>
>
> On Fri, Jan 11, 2013 at 4:21 PM, Ryan Ratliff <[email protected]> wrote:
>
>> A translation pattern is one option, the other is a DN for 1212 (not
>> assigned to a phone) with CFA set to 1702. You'll want to test your usual
>> call flows so that the fact that every call to 1702 will be a forwarded
>> calls. For example if you have any calling party selections on outbound
>> gateways set to 'first redirecting number' you may end up seeing 1212
>> instead of 1702 as the calling party number. Calls that end up in
>> voicemail will also be sent to the mailbox of 1212.
>>
>> The routing rule in Unity would basically be: Any redirected call with an
>> original called party number of 1212, send it to standard greeting for
>> 1702. I bet you could also just ad 1212 as an alternate extension for
>> 1702 and you'll be set.
>>
>> -Ryan
>>
>> On Jan 11, 2013, at 2:51 PM, David Zhars <[email protected]> wrote:
>>
>> OK, here's my dilemma. 1212 doesn't exist as far as UCM is concerned. I
>> suppose I could recreate it as a CTI Route point??
>>
>> Ryan, not sure what you mean about Unity sending calls from 1212 to
>> 1702.
>>
>> Sounds like a translation pattern in UCM may be the way to go, delete the
>> 1212 mailbox in Unity, so if someone does try and transfer a call to that
>> VM it would error out.
>>
>> While I want this to be easy for the end users, I also want it to be easy
>> for me!
>>
>>
>> On Fri, Jan 11, 2013 at 2:28 PM, Ryan Ratliff <[email protected]> wrote:
>>
>>> Unity call routing rule to send calls from 1212 to 1702, should be
>>> pretty straight forward.
>>> -Ryan
>>>
>>> On Jan 11, 2013, at 1:32 PM, David Zhars <[email protected]> wrote:
>>>
>>> Old user had ext 1212 (and this is a DID, so people can call directly
>>> from the outside).
>>> New user has ext 1702.
>>>
>>> What I want is:
>>>
>>> Internally: User dials 1212, phone rings at 1702.
>>> Internally: Reception takes a call, transfers it with TRANS **1212
>>> TRANS, call goes to 1702 voicemail.
>>>
>>> Externally: Someone calls 555-1212 and the call lands internally at 1702.
>>>
>>> Some of this I know how to do, I am not sure about the transfer to
>>> voicemail of the old extension and have it land at the new ext VM.
>>>
>>> Appreciate any help!
>>>
>>> Dave
>>>
>>> UCM 8.0, Unity 8.0
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/256e1edf/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 13 Jan 2013 13:58:28 +0000
From: Matthew Loraditch <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] 9.1 Upgrade Times
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On a Unity Connection system and CUCM both 8.6.2aSU1 started at 11:45PM and
12:12AM Last night, both are STILL running at 8:45 AM this morning. The system
I am doing this test on has about 60 Phones/Users/VM. These are the publishers
of each install, but I have never had an upgrade take this long, ever.
I'm now not sure I'll even be able to finish in my window since I haven't even
touched the subscribers yet.
Any clues as to why this is taking so long? I used to disable iothrottle during
an upgrade but that command is deprecated now.
Matthew G. Loraditch - CCNP-Voice, CCNA, CCDA
1965 Greenspring Drive
Timonium, MD 21093
voice. 410.252.8830
fax. 410.252.9284
Twitter<http://twitter.com/heliontech> |
Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> |
Website<http://www.heliontechnologies.com/> | Email
Support<mailto:[email protected]?subject=Technical%20Support%20Request>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130113/a1866840/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 111, Issue 12
*******************************************
