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. FWD one Ext to Another (David Zhars)
2. Re: FWD one Ext to Another (Joel Perez)
3. Re: FWD one Ext to Another (Ryan Ratliff)
4. CUCM MTP and g729 (Anthony Holloway)
5. Re: CUCM MTP and g729 (Justin Steinberg)
6. Re: CUCM MTP and g729 (Wes Sisk)
7. Re: CUCM MTP and g729 (Anthony Holloway)
8. Re: CUCM MTP and g729 (Anthony Holloway)
9. Re: CUCM MTP and g729 (Peter Slow)
10. Re: CUCM MTP and g729 (Peter Slow)
11. Re: CUCM MTP and g729 (Anthony Holloway)
12. Re: CUCM MTP and g729 (Peter Slow)
13. Re: CUCM MTP and g729 (Ryan Ratliff)
14. Re: FWD one Ext to Another (David Zhars)
15. CUC Cluster replication issues ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Jan 2013 13:32:53 -0500
From: David Zhars <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] FWD one Ext to Another
Message-ID:
<CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=weayhy...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/34d0c2ab/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 11 Jan 2013 14:24:36 -0500
From: Joel Perez <[email protected]>
To: David Zhars <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] FWD one Ext to Another
Message-ID:
<cabdwoufirq_pnxggdthgwgqe+7wvoxnfyqanier4mbe-diz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Dave,
If i'm understanding what you want to do correctly then you can just do a
CFWA on old ext 1212 to 1702. That way any call that comes into 1212 will
be sent to the new one of 1702.
You can also do a translation pattern from 1212 to 1702.
As far as Unity you can keep the VMB for 1212 and just add 1702 as an
alternate or vice-versa.
Joel P
On Fri, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/5f400fb6/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 11 Jan 2013 14:28:15 -0500
From: Ryan Ratliff <[email protected]>
To: David Zhars <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] FWD one Ext to Another
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/689f20b2/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 11 Jan 2013 14:11:56 -0600
From: Anthony Holloway <[email protected]>
To: Cisco VoIP Group <[email protected]>
Subject: [cisco-voip] CUCM MTP and g729
Message-ID:
<cacrcjoi5svz2he4nuzdhx-xs7sfgphgbww-pxqaccto9spm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/a172ab95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cucm-mtp-g729-redacted.png
Type: image/png
Size: 58634 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/a172ab95/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cucm-mtp-redacted.png
Type: image/png
Size: 13778 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/a172ab95/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cucm-sub02b-redacted.png
Type: image/png
Size: 12147 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/a172ab95/attachment-0005.png>
------------------------------
Message: 5
Date: Fri, 11 Jan 2013 15:43:07 -0500
From: Justin Steinberg <[email protected]>
To: Anthony Holloway <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<CACCAghZi4gbL6M-iEJcNfR+BS=oMBczN=2jj7dbwzkmueqp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
interesting. I always wondered why the software MTP couldn't terminate
G729 for things like DTMF mismatch. It isn't like it is transcoding audio,
it is simply handling different DTMF protocols.
is it possible Wireshark is just identifying it incorrectly? could you try
to convert it to audio and see if you hear it.
On Fri, Jan 11, 2013 at 3:11 PM, Anthony Holloway <
[email protected]> 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!
>
>
>
> _______________________________________________
> 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/20130111/db790514/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 11 Jan 2013 15:48:00 -0500
From: Wes Sisk <[email protected]>
To: Anthony Holloway <[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=us-ascii
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
------------------------------
Message: 7
Date: Fri, 11 Jan 2013 15:02:15 -0600
From: Anthony Holloway <[email protected]>
To: Justin Steinberg <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<CACRCJOiYAgisxj-UR_1T-SHmL-yYTJvJhe=kfq1a8cs6icp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
When I do a "show call active voice brief" on the VG224, it shows g729 and
the IP Address of the CUCM. That confirms it in another way. Thanks for
responding.
On Fri, Jan 11, 2013 at 2:43 PM, Justin Steinberg <[email protected]>wrote:
> interesting. I always wondered why the software MTP couldn't terminate
> G729 for things like DTMF mismatch. It isn't like it is transcoding audio,
> it is simply handling different DTMF protocols.
>
> is it possible Wireshark is just identifying it incorrectly? could you
> try to convert it to audio and see if you hear it.
>
> On Fri, Jan 11, 2013 at 3:11 PM, Anthony Holloway <
> [email protected]> 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!
>>
>>
>>
>> _______________________________________________
>> 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/20130111/c20109ab/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 11 Jan 2013 15:08:54 -0600
From: Anthony Holloway <[email protected]>
To: Wes Sisk <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<CACRCJOguqqYfJrY38mSG47qgmnkz=ryrezdla2rtdppypus...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/e1d6bd21/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 11 Jan 2013 16:13:17 -0500
From: Peter Slow <[email protected]>
To: Anthony Holloway <[email protected]>, Wes Sisk
<[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<cama5jw7zznc4s8extruy3zti_s8mrnb0gauqorcw0fxg+zf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Wes,
I once filed a defect against ipvmsapp for, if i remember
correctly, ORCAcking ("successfully") a skinny ORC for 729. I can't
remember the exact heaadline, and I think it may actually have been
against the conference bridge portion of the code. maybe there's
similar behavior in the MTP portion of the code? See anything that
looks similar to what I'm describing? It'd be interesting to find it
again and see exactly what it was.
-Pete
On Fri, Jan 11, 2013 at 4:02 PM, Anthony Holloway
<[email protected]> wrote:
> When I do a "show call active voice brief" on the VG224, it shows g729 and
> the IP Address of the CUCM. That confirms it in another way. Thanks for
> responding.
>
>
> On Fri, Jan 11, 2013 at 2:43 PM, Justin Steinberg <[email protected]>
> wrote:
>>
>> interesting. I always wondered why the software MTP couldn't terminate
>> G729 for things like DTMF mismatch. It isn't like it is transcoding audio,
>> it is simply handling different DTMF protocols.
>>
>> is it possible Wireshark is just identifying it incorrectly? could you
>> try to convert it to audio and see if you hear it.
>>
>> On Fri, Jan 11, 2013 at 3:11 PM, Anthony Holloway
>> <[email protected]> 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!
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
------------------------------
Message: 10
Date: Fri, 11 Jan 2013 16:24:35 -0500
From: Peter Slow <[email protected]>
To: Anthony Holloway <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<cama5jw7oz1-cqoo3kvdx56a9fdtdmoqvk9rzxy5+chr8v8d...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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
>
------------------------------
Message: 11
Date: Fri, 11 Jan 2013 15:36:13 -0600
From: Anthony Holloway <[email protected]>
To: Peter Slow <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<cacrcjoirphqnmhlnyglevttkuunie7y82hkvffuw1zcbu-6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/675b1648/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 11 Jan 2013 16:48:37 -0500
From: Peter Slow <[email protected]>
To: Anthony Holloway <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] CUCM MTP and g729
Message-ID:
<CAMa5Jw6ZJqrba8Hp9OgxcZtsmpXv6W13Pm6-QV99=wskd3z...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
the skinny signalling is between the MTP and the CUCM - thats how it
knows what RTP streams to send and expect and which ones to tie with
which. you can tell a CUCM MTP on server A to register with CUCM on
server B - this forces that MTPS skinny signalling over the wire so
you can get a packet capture of it. use the CM group on the device
pool of the MTP, ANN conference or MoH device to do this - it will
work for all of those types of endpoints. seeing the skinny signalling
in your packet catpure woudl be a very easy way of proving
specifically what service that RTP is destined for.
easier than looking at traces anyway =)
...this is also how you'd get a packet capture of the registration of
those devices. that would allow you to see which ones were reporting
729 support.
there HAVE been a couple instances here and there where CUCM
mistakenly signals one device to use a codec that the other device
doesnt support, but thats typically a very very complex call flow and
probably not what's happening here. There is liekly a more simple
explanation =)
-Pete
On Fri, 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
>> >
>
>
------------------------------
Message: 13
Date: Fri, 11 Jan 2013 17:02:35 -0500
From: Ryan Ratliff <[email protected]>
To: Anthony Holloway <[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="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/572fd442/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 11 Jan 2013 19:49:08 -0500
From: David Zhars <[email protected]>
To: Ryan Ratliff <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [cisco-voip] FWD one Ext to Another
Message-ID:
<CADe=jtf5qu4xvn-nrvyka_ohqnxcxduweqd4z5-9e9b_te_...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/23ae8f45/attachment-0001.html>
------------------------------
Message: 15
Date: Sat, 12 Jan 2013 12:45:58 +0000
From: [email protected]
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] CUC Cluster replication issues
Message-ID:
<255f57bb43f894468da6bd4f2f5dd1ce6490d...@rstn-s-mbx01.net.its.l-3com.com>
Content-Type: text/plain; charset="us-ascii"
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/f513189c/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 11
*******************************************
