You are on page 1of 1266

From tfrazee at gmail.

com Wed Jan 2 09:50:26 2013


From: tfrazee at gmail.com (Tim Frazee)
Date: Wed, 2 Jan 2013 08:50:26 -0600
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
Message-ID: <CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>

I didnt test to see if the 9.1 from CCO is bootable. In the past they
havent been.

attached is a screenshoot of the error I received when I tried to feed the


9.1 via CCO during a booted-from-nfr9.0 media

On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org>wrote:

> I had lots of problems doing upgrade during installs with 9.0 ESs. The
> ESs are usually bootable so I just gave up and installed fresh. Is the 9.1
> download bootable?****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tim Frazee
> *Sent:* Monday, December 31, 2012 3:50 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>
> ** **
>
> This was for UCM and Unity Connection. didnt try anything else.
>
>
> ****
>
> On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:****
>
> I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
>
> I'm getting an error if I feed the 9.1 iso to the 9.0 install process that
> i want to upgrade during the install process. I've been able to do this
> many times in the past with never a problem like this.
>
> Anyone have any ideas?****
>
> ** **
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.****
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/17375eb1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: temp.png
Type: image/png
Size: 17582 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/17375eb1/attachment.png>

From VanMarenNP at ldschurch.org Wed Jan 2 10:07:26 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Wed, 2 Jan 2013 15:07:26 +0000
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E3F97A@W12112.ldschurch.org>

Well that's different than what I was seeing, mine would crash during the install,
instead of saying you can't do it.

And I tried to boot from the CCO version of 9.1, it doesn't.

So if you really need to be able to install straight to 9.1, it looks like you'll
need to have TAC post the bootable iso for you.

-Nate

From: Tim Frazee [mailto:tfrazee at gmail.com]


Sent: Wednesday, January 02, 2013 7:50 AM
To: Nate VanMaren
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media
On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at
ldschurch.org<mailto:VanMarenNP at ldschurch.org>> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at
gmail.com>> wrote:
I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/becf1bee/attachment.html>

From rratliff at cisco.com Wed Jan 2 10:47:42 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 2 Jan 2013 10:47:42 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
Message-ID: <A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>

9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in the
trash and try with a real 9.0 build (I'm going to start this now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media
On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/599fbe40/attachment.html>

From tfrazee at gmail.com Wed Jan 2 11:18:21 2013


From: tfrazee at gmail.com (Tim Frazee)
Date: Wed, 2 Jan 2013 10:18:21 -0600
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
Message-ID: <CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>

I did just that. after I tried with the pre-release, I used my NFR iso.
Same result.

I only used the pre-release because it was already on my datastore and i


was feeling a bit lazy over vacation. After I attempted the same procedure
with 9.0(1) -37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with


9.1?

On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> 9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw
> it in the trash and try with a real 9.0 build (I'm going to start this
> now).
>
> -Ryan
>
> On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:
>
> I didnt test to see if the 9.1 from CCO is bootable. In the past they
> havent been.
>
> attached is a screenshoot of the error I received when I tried to feed the
> 9.1 via CCO during a booted-from-nfr9.0 media
>
> On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at
ldschurch.org>wrote:
>
>> I had lots of problems doing upgrade during installs with 9.0 ESs. The
>> ESs are usually bootable so I just gave up and installed fresh. Is the 9.1
>> download bootable?****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tim Frazee
>> *Sent:* Monday, December 31, 2012 3:50 PM
>> *To:* cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>>
>> ** **
>>
>> This was for UCM and Unity Connection. didnt try anything else.
>>
>>
>> ****
>>
>> On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:***
>> *
>>
>> I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
>>
>> I'm getting an error if I feed the 9.1 iso to the 9.0 install process
>> that i want to upgrade during the install process. I've been able to do
>> this many times in the past with never a problem like this.
>>
>> Anyone have any ideas?****
>>
>> ** **
>>
>>
>>
>> NOTICE: This email message is for the sole use of the intended
>> recipient(s) and may contain confidential and privileged information. Any
>> unauthorized review, use, disclosure or distribution is prohibited. If you
>> are not the intended recipient, please contact the sender by reply email
>> and destroy all copies of the original message.****
>>
>>
> <temp.png>_______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/2b8b716a/attachment.html>

From rratliff at cisco.com Wed Jan 2 13:21:46 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 2 Jan 2013 13:21:46 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
Message-ID: <00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>

Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.
Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?

On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in the
trash and try with a real 9.0 build (I'm going to start this now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media

On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/688cf0f5/attachment.html>

From ewellnitzvoip at gmail.com Wed Jan 2 14:15:26 2013


From: ewellnitzvoip at gmail.com (Erick Wellnitz)
Date: Wed, 2 Jan 2013 13:15:26 -0600
Subject: [cisco-voip] (no subject)
Message-ID: <CAK0wOsBfkmgyRKKBTgCB0BVLQs5FZEdMjo54taRs8S7SgG4Gyg@mail.gmail.com>

Hello all and happy new year!

I'm having a database connection issue with CUEAC 8.6

At intermittent intervals the client is unable to connect with an error


saying it can not connect to the database. Tried repairing the DB from the
database management section of the web gui with no difference. The only
thing that seems to resolve the issue temporarily is to restart the
attendant console server service.

I see a ton of the following in the log.

2/1/2013
7:50:23.034|
M|"AmendContactNumber","Request","IPA:10.12.52.46","IPP:49986","NUR:N00100161"
2/1/2013
7:50:23.034|M|"AmendContactNumber","Fail(DB-
>ICDEC_INVALIDCONTACTNOREF)","IPA:10.12.52.46","IPP:49986","NUR:N00100161","CUR:CTH
100081"
2/1/2013
7:50:33.093|
M|"AmendContactNumber","Request","IPA:10.12.52.46","IPP:49986","NUR:N00100161"

Anyone seen this before? TAC case 624321291 is open but I'm not having
much success getting more than silence from them.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/9ffcc498/attachment.html>

From tfrazee at gmail.com Wed Jan 2 16:12:56 2013


From: tfrazee at gmail.com (Tim Frazee)
Date: Wed, 2 Jan 2013 15:12:56 -0600
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
Message-ID: <CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>

I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back
in the day......

In short, you say that the only way currently to get to 9.1 is upgrade from
an already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing
the boot info file from 9.0 and pushing it into the 9.1 iso. The install
process failed post installing everything.

Thanks for digging Ryan.

On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Confirmed I see it here in the lab and it looks to be intentional, though
> I'm still digging.
> Initial word is for a while now upgrade-during-install is only supported
> to the same major/minor version.
>
> Anything beyond that requires a separate upgrade after install.
>
> -Ryan
>
> On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:
>
> I did just that. after I tried with the pre-release, I used my NFR iso.
> Same result.
>
> I only used the pre-release because it was already on my datastore and i
> was feeling a bit lazy over vacation. After I attempted the same procedure
> with 9.0(1) -37 iso, I received the exact same error.
>
> Ryan, should I be able to boot off of 9.0 and upgrade-during-install with
> 9.1?
>
> On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> 9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw
>> it in the trash and try with a real 9.0 build (I'm going to start this
>> now).
>>
>> -Ryan
>>
>> On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:
>>
>> I didnt test to see if the 9.1 from CCO is bootable. In the past they
>> havent been.
>>
>> attached is a screenshoot of the error I received when I tried to feed
>> the 9.1 via CCO during a booted-from-nfr9.0 media
>>
>> On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at
ldschurch.org>wrote:
>>
>>> I had lots of problems doing upgrade during installs with 9.0 ESs.
>>> The ESs are usually bootable so I just gave up and installed fresh. Is the
>>> 9.1 download bootable?****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tim Frazee
>>> *Sent:* Monday, December 31, 2012 3:50 PM
>>> *To:* cisco-voip at puck.nether.net
>>> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>>>
>>> ** **
>>>
>>> This was for UCM and Unity Connection. didnt try anything else.
>>>
>>>
>>> ****
>>>
>>> On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:**
>>> **
>>>
>>> I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
>>>
>>> I'm getting an error if I feed the 9.1 iso to the 9.0 install process
>>> that i want to upgrade during the install process. I've been able to do
>>> this many times in the past with never a problem like this.
>>>
>>> Anyone have any ideas?****
>>>
>>> ** **
>>>
>>>
>>>
>>> NOTICE: This email message is for the sole use of the intended
>>> recipient(s) and may contain confidential and privileged information. Any
>>> unauthorized review, use, disclosure or distribution is prohibited. If you
>>> are not the intended recipient, please contact the sender by reply email
>>> and destroy all copies of the original message.****
>>>
>>>
>> <temp.png>_______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/6173e995/attachment.html>

From rratliff at cisco.com Wed Jan 2 16:22:07 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 2 Jan 2013 16:22:07 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
Message-ID: <5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>

I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.

To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.

-Ryan

On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in the
day......

In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.

Thanks for digging Ryan.

On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.
Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?

On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in the
trash and try with a real 9.0 build (I'm going to start this now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media

On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/14816e69/attachment.html>

From MLoraditch at heliontechnologies.com Wed Jan 2 16:34:00 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Wed, 2 Jan 2013 21:34:00 +0000
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>

Well that's good, I can just put a PUT order in edelivery and get it. Let's see if
it works.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Wednesday, January 02, 2013 4:22 PM
To: Tim Frazee
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.

To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.

-Ryan

On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in the
day......

In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.

Thanks for digging Ryan.

On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at


cisco.com<mailto:rratliff at cisco.com>> wrote:
Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.
Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?
On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com<mailto:rratliff
at cisco.com>> wrote:
9.0.0.99101-22<tel:9.0.0.99101-22> is not a 9.0 ES, it's a pre-release build of
9.1. Throw it in the trash and try with a real 9.0 build (I'm going to start this
now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media
On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at
ldschurch.org<mailto:VanMarenNP at ldschurch.org>> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at
gmail.com>> wrote:
I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130102/527d4a29/attachment.html>

From robhass at gmail.com Wed Jan 2 20:47:04 2013


From: robhass at gmail.com (Robert Hass)
Date: Thu, 3 Jan 2013 02:47:04 +0100
Subject: [cisco-voip] Call Recording on CUCM
Message-ID: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>

Hi
My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM
without Contact Center).
We considering two options of call recording
a) record all voice calls
b) record voice calls on demand - user can turn on/off recording via xml
application of softkey on the phone

My question : Are above scenarios of call recording are possible on CUCM ?


What else I need - probably server for call-recording with big amount of
storange and some additional software (Zoom ? Cisco ?)

thanks for help

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/ec0b59de/attachment.html>

From JOrr at parknationalbank.com Wed Jan 2 21:05:01 2013


From: JOrr at parknationalbank.com (Orr, Jeff B.)
Date: Thu, 3 Jan 2013 02:05:01 +0000
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
Message-ID: <72FE638DB23C1049AA265B28B5F87F3364A56940@prk-alford-mbx1.PRK.LOCAL>

Hi Rob,

I just went through this for our environment. Call manager will provide the backend
requirements to do recordings. However, you will need a 3rd party software to
actually record and store the calls.

We evaluated several options and went with Zoom. It is a nice, Linux based
recording software. It fully supports spanless recordings and can function as
record all the time or on-demand recording. It does this by actually recording
every call, and then allowing a user to press a service button to record a call
that occurred earlier.
Jeff

____________________________________
Jeff Orr
Technical Services - Network Engineer
Park National Corporation (AMEX: PRK)

This message is confidential and is intended only for the named recipients, and may
contain information that is privileged, or exempt from disclosure under applicable
law. If you are not the intended recipients of the email, you are hereby notified
that the dissemination, distribution or copying of this e-mail or its contents is
strictly prohibited. If you received this e-mail in error, please notify the sender
at either the e-mail address or the phone number above and delete this e-mail from
your computer.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Robert Hass
Sent: Wednesday, January 02, 2013 8:47 PM
To: cisco-voip
Subject: [cisco-voip] Call Recording on CUCM

Hi
My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM without
Contact Center).
We considering two options of call recording
a) record all voice calls
b) record voice calls on demand - user can turn on/off recording via xml
application of softkey on the phone

My question : Are above scenarios of call recording are possible on CUCM ? What
else I need - probably server for call-recording with big amount of storange and
some additional software (Zoom ? Cisco ?)

thanks for help

Rob

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/16ea81dd/attachment.html>

From erickbee at gmail.com Wed Jan 2 22:32:24 2013


From: erickbee at gmail.com (Erick B)
Date: Wed, 2 Jan 2013 21:32:24 -0600
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
Message-ID: <44547C16-7070-4462-9213-8661B44DBD8B@gmail.com>

Yes, you'll need zoom or another 3rd party recording application.

On recent cucm versions, you enable built in bridge on newer model phones then
assign a recording profile to the DN on the phone you want to record. The recording
has the IP address of recording server (sip trunk) the phone will send the audio
to.
You can do it the old way with span ports to on switches, depends on recording
application you are using and where the phones are if span works easily or not.

Sent from my iPhone

On Jan 2, 2013, at 7:47 PM, Robert Hass <robhass at gmail.com> wrote:

> Hi
> My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM without
Contact Center).
> We considering two options of call recording
> a) record all voice calls
> b) record voice calls on demand - user can turn on/off recording via xml
application of softkey on the phone
>
> My question : Are above scenarios of call recording are possible on CUCM ? What
else I need - probably server for call-recording with big amount of storange and
some additional software (Zoom ? Cisco ?)
>
> thanks for help
>
> Rob
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

From ckos1976 at hotmail.com Thu Jan 3 05:43:26 2013


From: ckos1976 at hotmail.com (costas georgiou)
Date: Thu, 3 Jan 2013 10:43:26 +0000
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>,
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>,
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
Message-ID: <BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>

Hi All,

I have been informed by Cisco that I have to rebuild my subscriber (version 8.5),
are there any good Cisco docs out there on rebuilds?

Regards

Cos

From: salamka at gmail.com


Date: Thu, 20 Dec 2012 16:05:35 +0530
Subject: Re: [cisco-voip] No access to Publisher
To: ckos1976 at hotmail.com
CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
You got a remote console , like iLO or Vsphere ?

---AS

On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com> wrote:

Hi,

Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.

From: davidytk at netvigator.com


To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] No access to Publisher
Date: Thu, 20 Dec 2012 17:39:11 +0800

Try to restart the Tomcat service in Pub & Sub

Util service restart Cisco Tomcat

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of costas georgiou
Sent: Thursday, December 20, 2012 5:32 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] No access to Publisher

Hi All,

I was wondering whether anyone has come across this before. I have just started at
a new company and they have a CUCM cluster running 8.5.1, they have one pub and two
subs. I downloaded RTMT and noticed that one of the subs was not accessible, I can
ping the IP address, but cannot access it via SSH or URL, someone should be going
to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.

Any Ideas.

Regards

Costas

__________ Information from ESET NOD32 Antivirus, version of virus signature


database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature


database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/a2153ef9/attachment.html>

From salamka at gmail.com Thu Jan 3 05:49:40 2013


From: salamka at gmail.com (Abdul Salam .)
Date: Thu, 3 Jan 2013 16:19:40 +0530
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
Message-ID: <CAKav0XTZLu6M6Uzp4EYDTg-0LymQSnYqiPhZTDXbc8OBiuh10w@mail.gmail.com>

I think DRS admin guide would be helpful

*---AS*

On Thu, Jan 3, 2013 at 4:13 PM, costas georgiou <ckos1976 at hotmail.com>wrote:

> Hi All,
>
> I have been informed by Cisco that I have to rebuild my subscriber
> (version 8.5), are there any good Cisco docs out there on rebuilds?
>
> Regards
>
> Cos
>
> ------------------------------
> From: salamka at gmail.com
> Date: Thu, 20 Dec 2012 16:05:35 +0530
> Subject: Re: [cisco-voip] No access to Publisher
> To: ckos1976 at hotmail.com
> CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
>
>
> You got a remote console , like iLO or Vsphere ?
>
>
>
> *---AS*
>
>
>
> On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com>wrote:
>
> Hi,
>
> Thanks for getting back to me. I tried restarting Tomcat on the pub and I
> can access it for a while then I can't. Tomcat service on the Sub, i
> cannot restart yet as I cannot access the server. DO you think these
> problems are due to the Sub being down? I think this server has been down
> for a few days.
>
> ------------------------------
> From: davidytk at netvigator.com
> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] No access to Publisher
> Date: Thu, 20 Dec 2012 17:39:11 +0800
>
>
> Try to restart the Tomcat service in Pub & Sub
>
> Util service restart Cisco Tomcat
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *costas georgiou
> *Sent:* Thursday, December 20, 2012 5:32 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] No access to Publisher
>
> Hi All,
>
> I was wondering whether anyone has come across this before. I have just
> started at a new company and they have a CUCM cluster running 8.5.1, they
> have one pub and two subs. I downloaded RTMT and noticed that one of the
> subs was not accessible, I can ping the IP address, but cannot access it
> via SSH or URL, someone should be going to the site today to re-boot. The
> day after, I could no longer access the Publisher, this server I can access
> via SSH, but cannot access via URL or RMTM, I stopped and started the
> Tomcat service and it came back for a while, but after a while i cannot
> access again.
>
> Any Ideas.
>
> Regards
>
> Costas
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/71651943/attachment.html>

From terry.cheema at gmail.com Thu Jan 3 06:54:02 2013


From: terry.cheema at gmail.com (Terry Cheema)
Date: Thu, 3 Jan 2013 22:54:02 +1100
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
Message-ID: <81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>

Hi Costas,

While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.

Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml

I have done this few times, and in one case eventually I had to rebuild the whole
cluster. Whats the hardware? I had done this on MCS servers, but process will be
almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.

I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:

1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)

2) Record your administrator login/pwd

3) Record application login/pwd

4) run and record output from cli - show network eth0


It will give you ip address, subnet, default gateway, duplex, dns etc all network
related info

5) run and record output from cli - utils ntp status. Will give all ntp servers

6) run and record output command show status from CLI, will show hostname, license
mac etc.

7) Record all device information etc from RTMT device summary


prior and match the same post rebuilt.

8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize

Hope that helps and let us know if you have any other query.

Terry

PS : excuse fonts from iphone notes :)

Sent from my iPhone

On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com> wrote:

> Hi All,
>
> I have been informed by Cisco that I have to rebuild my subscriber (version 8.5),
are there any good Cisco docs out there on rebuilds?
>
> Regards
>
> Cos
>
> From: salamka at gmail.com
> Date: Thu, 20 Dec 2012 16:05:35 +0530
> Subject: Re: [cisco-voip] No access to Publisher
> To: ckos1976 at hotmail.com
> CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
>
> You got a remote console , like iLO or Vsphere ?
>
>
>
> ---AS
>
>
>
> On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
> Hi,
>
> Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.
>
> From: davidytk at netvigator.com
> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] No access to Publisher
> Date: Thu, 20 Dec 2012 17:39:11 +0800
>
>
> Try to restart the Tomcat service in Pub & Sub
>
> Util service restart Cisco Tomcat
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of costas georgiou
> Sent: Thursday, December 20, 2012 5:32 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] No access to Publisher
>
> Hi All,
>
> I was wondering whether anyone has come across this before. I have just started
at a new company and they have a CUCM cluster running 8.5.1, they have one pub and
two subs. I downloaded RTMT and noticed that one of the subs was not accessible, I
can ping the IP address, but cannot access it via SSH or URL, someone should be
going to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.
>
> Any Ideas.
>
> Regards
>
> Costas
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/b8137c20/attachment.html>

From terry.cheema at gmail.com Thu Jan 3 07:15:04 2013


From: terry.cheema at gmail.com (Terry Cheema)
Date: Thu, 3 Jan 2013 23:15:04 +1100
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
<81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
Message-ID: <5FB65336-EDDF-46A4-AFB2-DDD95D0A2D3F@gmail.com>

To add further to below mail:

Once you record all information. Take a backup of your system.


Shut down the server and rebuild the new server with information at your hand.
In the end restore back up data to this node.

Terry

Sent from my iPhone

On 03/01/2013, at 10:54 PM, Terry Cheema <terry.cheema at gmail.com> wrote:

> Hi Costas,
>
> While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.
>
> Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.
>
>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml
>
> I have done this few times, and in one case eventually I had to rebuild the whole
cluster. Whats the hardware? I had done this on MCS servers, but process will be
almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.
>
> I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:
>
> 1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)
>
> 2) Record your administrator login/pwd
>
> 3) Record application login/pwd
>
> 4) run and record output from cli - show network eth0
> It will give you ip address, subnet, default gateway, duplex, dns etc all network
related info
>
> 5) run and record output from cli - utils ntp status. Will give all ntp servers
>
> 6) run and record output command show status from CLI, will show hostname,
license mac etc.
>
> 7) Record all device information etc from RTMT device summary
> prior and match the same post rebuilt.
>
> 8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize
>
> Hope that helps and let us know if you have any other query.
>
> Terry
>
> PS : excuse fonts from iphone notes :)
>
> Sent from my iPhone
>
> On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
>
>> Hi All,
>>
>> I have been informed by Cisco that I have to rebuild my subscriber (version
8.5), are there any good Cisco docs out there on rebuilds?
>>
>> Regards
>>
>> Cos
>>
>> From: salamka at gmail.com
>> Date: Thu, 20 Dec 2012 16:05:35 +0530
>> Subject: Re: [cisco-voip] No access to Publisher
>> To: ckos1976 at hotmail.com
>> CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
>>
>> You got a remote console , like iLO or Vsphere ?
>>
>>
>>
>> ---AS
>>
>>
>>
>> On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com>
wrote:
>> Hi,
>>
>> Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.
>>
>> From: davidytk at netvigator.com
>> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
>> Subject: RE: [cisco-voip] No access to Publisher
>> Date: Thu, 20 Dec 2012 17:39:11 +0800
>>
>>
>> Try to restart the Tomcat service in Pub & Sub
>>
>> Util service restart Cisco Tomcat
>>
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of costas georgiou
>> Sent: Thursday, December 20, 2012 5:32 PM
>> To: cisco-voip at puck.nether.net
>> Subject: [cisco-voip] No access to Publisher
>>
>> Hi All,
>>
>> I was wondering whether anyone has come across this before. I have just started
at a new company and they have a CUCM cluster running 8.5.1, they have one pub and
two subs. I downloaded RTMT and noticed that one of the subs was not accessible, I
can ping the IP address, but cannot access it via SSH or URL, someone should be
going to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.
>>
>> Any Ideas.
>>
>> Regards
>>
>> Costas
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/4c151985/attachment.html>

From Zoltan.Kelemen at emerson.com Thu Jan 3 07:38:55 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Thu, 3 Jan 2013 12:38:55 +0000
Subject: [cisco-voip] Calling Party Transformation Patterns on CUCM 8.x
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061A96F325B9@GBLONZ-PMSGEM02.emrsn.org>

Hi and a Happy New Year!

CUCM 8.5.1 and I'm trying to globalize calling numbers of outgoing calls on a
specific SIP trunk.

My problem is, there are more than one DID ranges, i.e.:
1XXX numbers would have +40 345 671 XXX
2XXX numbers would have +40 341 232 XXX

I want to make sure to set the proper caller ID/calling number on outgoing calls.
(I can do that since it's an internal SIP trunk, so any callerID is ok)

So I've created a partition and a CSS for transformations and added a Calling Party
Transformation Pattern (Call Routing > Transformation > Transformation Pattern >
Calling Party Transformation Pattern), applied it properly to the SIP trunk etc.

For testing I have created a single test pattern, with my own extension: 2356
This matched and applied the transformations I was expecting. I tested it with
changing the transformations, it kept working.

However, when I rewrote the pattern to 2XXX it stopped matching. Basically it seems
that I'm unable to use any non-specific pattern to match the calling party number.
(neither 2!, nor 235X nor anything else that I've tried seems to match)
Any ideas?

Thanks,
Zoltan Kelemen
Emerson

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/7b5e8eb4/attachment.html>

From terry.cheema at gmail.com Thu Jan 3 08:13:42 2013


From: terry.cheema at gmail.com (Terry Cheema)
Date: Fri, 4 Jan 2013 00:13:42 +1100
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <38B85D43-C2BF-41B9-9432-F4AAB6E18898@gmail.com>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
<81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
<5FB65336-EDDF-46A4-AFB2-DDD95D0A2D3F@gmail.com>
<BLU174-W8123B4C672C665F3898B6D2210@phx.gbl>
<38B85D43-C2BF-41B9-9432-F4AAB6E18898@gmail.com>
Message-ID: <C673498F-E86C-49DB-AEAF-64317E717A2D@gmail.com>

Including the list, in case anyone has other ideas/experiences...

Sent from my iPhone

On 03/01/2013, at 11:56 PM, Terry Cheema <terry.cheema at gmail.com> wrote:

> Hi Costas,
>
> Not a problem. Few things i would suggest.
>
> 1) First of all try if you can recover the servers using recovery disk. Once you
can access the servers and verify dbreplication (repair, reboot if you nned to) is
correct then take a good backup and move ahead with rebuild. Now if you question,
why to rebuild if everything is good - because it will again go into read only mode
or start having dbreplication issues or file system errors in a week or two.
>
> 2) Regards to your question of backup restore, if possible best approach would be
to restore from backup. Thats how Cisco recommends, in the doc, if you go to
replacing a subscriber section. That works fine.
>
> 3) And for your server accesibilty and errors, I would suggest you to run a
recovery disk and recover your server first. It would require a reboot.
>
> 4) In the end, if you are not able to recover your server by all means, then
consult with TAC and rebuild the server and let dbreplication do the work, if you
dont have a recent good backup. But again I would say if you must do this way get
full consultation from TAC first.
>
> When I ran into this first time, TAC recommended to first recover the server to
normal to minimize any risk. Everything went fine with that approach.
>
>
>
> Terry
>
>
>
> Sent from my iPhone
>
> On 03/01/2013, at 11:21 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
>
>> Hi Terry,
>>
>> Thanks for the info, appreciate it. I was going to rebuild then let replication
do its thing, do you suggest restoring with a backup? Currently replication is not
working, I was going to rebuild the subscriber then do a reboot on all servers
probably on Monday to sort out replication. The reason for this is because I have
top raise a change request, I have only joined this company and found the server
down when I downloaded RTMT. Also, just to let you know, I cannot access the
faulty sub, i get to the CLI enter username and password then get lots of error
messages and it hangs. Cisco recommended the rebuild.
>>
>> Regards
>> Costas
>>
>> Subject: Re: [cisco-voip] No access to Publisher
>> From: terry.cheema at gmail.com
>> Date: Thu, 3 Jan 2013 23:15:04 +1100
>> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
>>
>> To add further to below mail:
>>
>> Once you record all information. Take a backup of your system.
>> Shut down the server and rebuild the new server with information at your hand.
>> In the end restore back up data to this node.
>>
>> Terry
>>
>> Sent from my iPhone
>>
>> On 03/01/2013, at 10:54 PM, Terry Cheema <terry.cheema at gmail.com> wrote:
>>
>> Hi Costas,
>>
>> While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.
>>
>> Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.
>>
>>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml
>>
>> I have done this few times, and in one case eventually I had to rebuild the
whole cluster. Whats the hardware? I had done this on MCS servers, but process will
be almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.
>>
>> I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:
>>
>> 1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)
>>
>> 2) Record your administrator login/pwd
>>
>> 3) Record application login/pwd
>>
>> 4) run and record output from cli - show network eth0
>> It will give you ip address, subnet, default gateway, duplex, dns etc all
network related info
>>
>> 5) run and record output from cli - utils ntp status. Will give all ntp servers
>>
>> 6) run and record output command show status from CLI, will show hostname,
license mac etc.
>>
>> 7) Record all device information etc from RTMT device summary
>> prior and match the same post rebuilt.
>>
>> 8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize
>>
>> Hope that helps and let us know if you have any other query.
>>
>> Terry
>>
>> PS : excuse fonts from iphone notes :)
>>
>> Sent from my iPhone
>>
>> On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
>>
>> Hi All,
>>
>> I have been informed by Cisco that I have to rebuild my subscriber (version
8.5), are there any good Cisco docs out there on rebuilds?
>>
>> Regards
>>
>> Cos
>>
>> From: salamka at gmail.com
>> Date: Thu, 20 Dec 2012 16:05:35 +0530
>> Subject: Re: [cisco-voip] No access to Publisher
>> To: ckos1976 at hotmail.com
>> CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
>>
>> You got a remote console , like iLO or Vsphere ?
>>
>>
>>
>> ---AS
>>
>>
>>
>> On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com>
wrote:
>> Hi,
>>
>> Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.
>>
>> From: davidytk at netvigator.com
>> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
>> Subject: RE: [cisco-voip] No access to Publisher
>> Date: Thu, 20 Dec 2012 17:39:11 +0800
>>
>>
>> Try to restart the Tomcat service in Pub & Sub
>>
>> Util service restart Cisco Tomcat
>>
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of costas georgiou
>> Sent: Thursday, December 20, 2012 5:32 PM
>> To: cisco-voip at puck.nether.net
>> Subject: [cisco-voip] No access to Publisher
>>
>> Hi All,
>>
>> I was wondering whether anyone has come across this before. I have just started
at a new company and they have a CUCM cluster running 8.5.1, they have one pub and
two subs. I downloaded RTMT and noticed that one of the subs was not accessible, I
can ping the IP address, but cannot access it via SSH or URL, someone should be
going to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.
>>
>> Any Ideas.
>>
>> Regards
>>
>> Costas
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/1d07a8f7/attachment.html>

From robhass at gmail.com Thu Jan 3 08:14:12 2013


From: robhass at gmail.com (Robert Hass)
Date: Thu, 3 Jan 2013 14:14:12 +0100
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <44547C16-7070-4462-9213-8661B44DBD8B@gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
<44547C16-7070-4462-9213-8661B44DBD8B@gmail.com>
Message-ID: <CALNfFTE=hH3mQroMKhWqDpd6Ytbg7xgwO451NCwmXArew3qU3A@mail.gmail.com>

We mostly have 7941 and 7945 ip phones. Are these both models have build-in
bridge ?

Rob

On Thursday, January 3, 2013, Erick B wrote:

> Yes, you'll need zoom or another 3rd party recording application.
>
> On recent cucm versions, you enable built in bridge on newer model phones
> then assign a recording profile to the DN on the phone you want to record.
> The recording has the IP address of recording server (sip trunk) the phone
> will send the audio to.
>
> You can do it the old way with span ports to on switches, depends on
> recording application you are using and where the phones are if span works
> easily or not.
>
> Sent from my iPhone
>
> On Jan 2, 2013, at 7:47 PM, Robert Hass <robhass at gmail.com <javascript:;>>
> wrote:
>
> > Hi
> > My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM
> without Contact Center).
> > We considering two options of call recording
> > a) record all voice calls
> > b) record voice calls on demand - user can turn on/off recording via xml
> application of softkey on the phone
> >
> > My question : Are above scenarios of call recording are possible on CUCM
> ? What else I need - probably server for call-recording with big amount of
> storange and some additional software (Zoom ? Cisco ?)
> >
> > thanks for help
> >
> > Rob
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net <javascript:;>
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/7bb1b474/attachment.html>

From robhass at gmail.com Thu Jan 3 08:15:55 2013


From: robhass at gmail.com (Robert Hass)
Date: Thu, 3 Jan 2013 14:15:55 +0100
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <72FE638DB23C1049AA265B28B5F87F3364A56940@prk-alford-mbx1.PRK.LOCAL>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
<72FE638DB23C1049AA265B28B5F87F3364A56940@prk-alford-mbx1.PRK.LOCAL>
Message-ID: <CALNfFTHLmMJeiUTcSyWBP9PfmReg4WWKOMRa2HMsz1E-_4q14w@mail.gmail.com>

Thanks for info


Are you recording allcalls or only selected DNs ?
Is it possible to on/off recording by user using some XML application or
soft key on user's phone ?

Rob

On Thursday, January 3, 2013, Orr, Jeff B. wrote:

> Hi Rob,****
>
> ** **
>
> I just went through this for our environment. Call manager will provide
> the backend requirements to do recordings. However, you will need a 3rdparty
software to actually record and store the calls.
> ****
>
> ** **
>
> We evaluated several options and went with Zoom. It is a nice, Linux based
> recording software. It fully supports spanless recordings and can function
> as record all the time or on-demand recording. It does this by actually
> recording every call, and then allowing a user to press a service button to
> record a call that occurred earlier. ****
>
> ** **
>
> Jeff ****
>
> ** **
>
> ** **
>
> ____________________________________****
>
> Jeff Orr****
>
> Technical Services - Network Engineer****
>
> Park National Corporation (AMEX: PRK)****
>
> ** **
>
> This message is confidential and is intended only for the named
> recipients, and may contain information that is privileged, or exempt from
> disclosure under applicable law. If you are not the intended recipients of
> the email, you are hereby notified that the dissemination, distribution or
> copying of this e-mail or its contents is strictly prohibited. If you
> received this e-mail in error, please notify the sender at either the
> e-mail address or the phone number above and delete this e-mail from your
> computer.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net <javascript:_e({}, 'cvml',
> 'cisco-voip-bounces at puck.nether.net');> [mailto:
> cisco-voip-bounces at puck.nether.net <javascript:_e({}, 'cvml',
> 'cisco-voip-bounces at puck.nether.net');>] *On Behalf Of *Robert Hass
> *Sent:* Wednesday, January 02, 2013 8:47 PM
> *To:* cisco-voip
> *Subject:* [cisco-voip] Call Recording on CUCM****
>
> ** **
>
> Hi****
>
> My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM
> without Contact Center).****
>
> We considering two options of call recording****
>
> a) record all voice calls****
>
> b) record voice calls on demand - user can turn on/off recording via xml
> application of softkey on the phone****
>
> ** **
>
> My question : Are above scenarios of call recording are possible on CUCM ?
> What else I need - probably server for call-recording with big amount of
> storange and some additional software (Zoom ? Cisco ?)****
>
> ** **
>
> thanks for help****
>
> ** **
>
> Rob****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/0cc57186/attachment.html>

From terry.cheema at gmail.com Thu Jan 3 08:28:15 2013


From: terry.cheema at gmail.com (Terry Cheema)
Date: Fri, 4 Jan 2013 00:28:15 +1100
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <BLU174-W135B28071F9C3411896663D2210@phx.gbl>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
<81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
<5FB65336-EDDF-46A4-AFB2-DDD95D0A2D3F@gmail.com>
<BLU174-W8123B4C672C665F3898B6D2210@phx.gbl>
<38B85D43-C2BF-41B9-9432-F4AAB6E18898@gmail.com>
<BLU174-W135B28071F9C3411896663D2210@phx.gbl>
Message-ID: <BF7A14DC-23EE-48F8-8BF6-D77DE8BBD9E9@gmail.com>

If you have tried the recovery disk already then I think you may not have much
options left. You would probably try rebuilding the server with the procedure TAC
is recommending.

Since you are restoring on subscriber only, even if you restore from 6th December
backup, dbreplication should take care for the rest. Is TAC recommending this way?
How bad is your dbreplication, its just bad on this server, rest two have good
status??

If not already given, ask TAC to give you a precise action plan and follow that
closely. That may be your best bet.

Good luck with that, keep us posted !!

Terry

Sent from my iPhone

On 04/01/2013, at 12:09 AM, costas georgiou <ckos1976 at hotmail.com> wrote:

> Cheers Terry,


>
> We tried the recovery disk yesterday, it stated that it was successful and then
we were getting the same errors. I sent the errors over to TAC and they came back
with rebuilding from backup, but the earliest backup we have is Dec 6th.
>
> Regards
>
> Costas
>
> Subject: Re: [cisco-voip] No access to Publisher
> From: terry.cheema at gmail.com
> Date: Thu, 3 Jan 2013 23:56:36 +1100
> To: ckos1976 at hotmail.com
>
> Hi Costas,
>
> Not a problem. Few things i would suggest.
>
> 1) First of all try if you can recover the servers using recovery disk. Once you
can access the servers and verify dbreplication (repair, reboot if you nned to) is
correct then take a good backup and move ahead with rebuild. Now if you question,
why to rebuild if everything is good - because it will again go into read only mode
or start having dbreplication issues or file system errors in a week or two.
>
> 2) Regards to your question of backup restore, if possible best approach would be
to restore from backup. Thats how Cisco recommends, in the doc, if you go to
replacing a subscriber section. That works fine.
>
> 3) And for your server accesibilty and errors, I would suggest you to run a
recovery disk and recover your server first. It would require a reboot.
>
> 4) In the end, if you are not able to recover your server by all means, then
consult with TAC and rebuild the server and let dbreplication do the work, if you
dont have a recent good backup. But again I would say if you must do this way get
full consultation from TAC first.
>
> When I ran into this first time, TAC recommended to first recover the server to
normal to minimize any risk. Everything went fine with that approach.
>
>
>
> Terry
>
>
>
> Sent from my iPhone
>
> On 03/01/2013, at 11:21 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
>
> Hi Terry,
>
> Thanks for the info, appreciate it. I was going to rebuild then let replication
do its thing, do you suggest restoring with a backup? Currently replication is not
working, I was going to rebuild the subscriber then do a reboot on all servers
probably on Monday to sort out replication. The reason for this is because I have
top raise a change request, I have only joined this company and found the server
down when I downloaded RTMT. Also, just to let you know, I cannot access the
faulty sub, i get to the CLI enter username and password then get lots of error
messages and it hangs. Cisco recommended the rebuild.
>
> Regards
> Costas
>
> Subject: Re: [cisco-voip] No access to Publisher
> From: terry.cheema at gmail.com
> Date: Thu, 3 Jan 2013 23:15:04 +1100
> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
>
> To add further to below mail:
>
> Once you record all information. Take a backup of your system.
> Shut down the server and rebuild the new server with information at your hand.
> In the end restore back up data to this node.
>
> Terry
>
> Sent from my iPhone
>
> On 03/01/2013, at 10:54 PM, Terry Cheema <terry.cheema at gmail.com> wrote:
>
> Hi Costas,
>
> While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.
>
> Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.
>
>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml
>
> I have done this few times, and in one case eventually I had to rebuild the whole
cluster. Whats the hardware? I had done this on MCS servers, but process will be
almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.
>
> I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:
>
> 1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)
>
> 2) Record your administrator login/pwd
>
> 3) Record application login/pwd
>
> 4) run and record output from cli - show network eth0
> It will give you ip address, subnet, default gateway, duplex, dns etc all network
related info
>
> 5) run and record output from cli - utils ntp status. Will give all ntp servers
>
> 6) run and record output command show status from CLI, will show hostname,
license mac etc.
>
> 7) Record all device information etc from RTMT device summary
> prior and match the same post rebuilt.
>
> 8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize
>
> Hope that helps and let us know if you have any other query.
>
> Terry
>
> PS : excuse fonts from iphone notes :)
>
> Sent from my iPhone
>
> On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
>
> Hi All,
>
> I have been informed by Cisco that I have to rebuild my subscriber (version 8.5),
are there any good Cisco docs out there on rebuilds?
>
> Regards
>
> Cos
>
> From: salamka at gmail.com
> Date: Thu, 20 Dec 2012 16:05:35 +0530
> Subject: Re: [cisco-voip] No access to Publisher
> To: ckos1976 at hotmail.com
> CC: davidytk at netvigator.com; cisco-voip at puck.nether.net
>
> You got a remote console , like iLO or Vsphere ?
>
>
>
> ---AS
>
>
>
> On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com> wrote:
> Hi,
>
> Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.
>
> From: davidytk at netvigator.com
> To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] No access to Publisher
> Date: Thu, 20 Dec 2012 17:39:11 +0800
>
>
> Try to restart the Tomcat service in Pub & Sub
>
> Util service restart Cisco Tomcat
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of costas georgiou
> Sent: Thursday, December 20, 2012 5:32 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] No access to Publisher
>
> Hi All,
>
> I was wondering whether anyone has come across this before. I have just started
at a new company and they have a CUCM cluster running 8.5.1, they have one pub and
two subs. I downloaded RTMT and noticed that one of the subs was not accessible, I
can ping the IP address, but cannot access it via SSH or URL, someone should be
going to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.
>
> Any Ideas.
>
> Regards
>
> Costas
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/89856006/attachment.html>

From VanMarenNP at ldschurch.org Thu Jan 3 09:45:01 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Thu, 3 Jan 2013 14:45:01 +0000
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CALNfFTE=hH3mQroMKhWqDpd6Ytbg7xgwO451NCwmXArew3qU3A@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
<44547C16-7070-4462-9213-8661B44DBD8B@gmail.com>
<CALNfFTE=hH3mQroMKhWqDpd6Ytbg7xgwO451NCwmXArew3qU3A@mail.gmail.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E42E71@W12112.ldschurch.org>

Yes they do. Old school 7940/7960 do not.


From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Robert Hass
Sent: Thursday, January 03, 2013 6:14 AM
To: Erick B
Cc: cisco-voip
Subject: Re: [cisco-voip] Call Recording on CUCM

We mostly have 7941 and 7945 ip phones. Are these both models have build-in
bridge ?

Rob

On Thursday, January 3, 2013, Erick B wrote:


Yes, you'll need zoom or another 3rd party recording application.

On recent cucm versions, you enable built in bridge on newer model phones then
assign a recording profile to the DN on the phone you want to record. The recording
has the IP address of recording server (sip trunk) the phone will send the audio
to.

You can do it the old way with span ports to on switches, depends on recording
application you are using and where the phones are if span works easily or not.

Sent from my iPhone

On Jan 2, 2013, at 7:47 PM, Robert Hass <robhass at gmail.com<javascript:;>> wrote:

> Hi
> My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM without
Contact Center).
> We considering two options of call recording
> a) record all voice calls
> b) record voice calls on demand - user can turn on/off recording via xml
application of softkey on the phone
>
> My question : Are above scenarios of call recording are possible on CUCM ? What
else I need - probably server for call-recording with big amount of storange and
some additional software (Zoom ? Cisco ?)
>
> thanks for help
>
> Rob
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<javascript:;>
> https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/ef1e1324/attachment.html>

From Edward.Countryman at presencehealth.org Thu Jan 3 10:15:24 2013


From: Edward.Countryman at presencehealth.org (Countryman, Edward)
Date: Thu, 3 Jan 2013 09:15:24 -0600
Subject: [cisco-voip] wireless phone network authentication
Message-ID: <3E508304295FC04988DFEEA1A2F177C347085E@AEXMV22.phnet.phroot.local>

Just curious how other folks handle deployment and subsequent device
management of wireless phone authentication on your networks?

It appears Cisco publishes a best practice of using 802.1x


authentication rather than PSK's. Given this, do most folks use A/D
accounts? Do you use individual accounts per telephone of share an
account across many devices?

Does anyone use the BD utility and have an open provisioning network
setup? How is that working out?

I am potentially looking at over a thousand devices and want to


establish our internal process for managing them. Any thoughts or
input is appreciated.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/22f3a108/attachment.html>

From ckos1976 at hotmail.com Thu Jan 3 10:53:57 2013


From: ckos1976 at hotmail.com (costas georgiou)
Date: Thu, 3 Jan 2013 15:53:57 +0000
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <BF7A14DC-23EE-48F8-8BF6-D77DE8BBD9E9@gmail.com>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
<81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
<5FB65336-EDDF-46A4-AFB2-DDD95D0A2D3F@gmail.com>
<BLU174-W8123B4C672C665F3898B6D2210@phx.gbl>
<38B85D43-C2BF-41B9-9432-F4AAB6E18898@gmail.com>
<BLU174-W135B28071F9C3411896663D2210@phx.gbl>,
<BF7A14DC-23EE-48F8-8BF6-D77DE8BBD9E9@gmail.com>
Message-ID: <BLU174-W422A2557D0879D4AE967E9D2210@phx.gbl>

Hi Terry,

Thanks for the info. Cisco are recommending I rebuild the server as if it were a
fresh install on CUCM, the Publisher will then push the configuration to the
Subscriber once added to the cluster again.
Thanks

Cos

CC: cisco-voip at puck.nether.net


From: terry.cheema at gmail.com
Subject: Re: [cisco-voip] No access to Publisher
Date: Fri, 4 Jan 2013 00:28:15 +1100
To: ckos1976 at hotmail.com

If you have tried the recovery disk already then I think you may not have much
options left. You would probably try rebuilding the server with the procedure TAC
is recommending.

Since you are restoring on subscriber only, even if you restore from 6th December
backup, dbreplication should take care for the rest. Is TAC recommending this way?
How bad is your dbreplication, its just bad on this server, rest two have good
status??

If not already given, ask TAC to give you a precise action plan and follow that
closely. That may be your best bet.

Good luck with that, keep us posted !!

Terry

Sent from my iPhone

On 04/01/2013, at 12:09 AM, costas georgiou <ckos1976 at hotmail.com> wrote:

Cheers Terry,

We tried the recovery disk yesterday, it stated that it was successful and then we
were getting the same errors. I sent the errors over to TAC and they came back
with rebuilding from backup, but the earliest backup we have is Dec 6th.

Regards

Costas
Subject: Re: [cisco-voip] No access to Publisher
From: terry.cheema at gmail.com
Date: Thu, 3 Jan 2013 23:56:36 +1100
To: ckos1976 at hotmail.com

Hi Costas,

Not a problem. Few things i would suggest.

1) First of all try if you can recover the servers using recovery disk. Once you
can access the servers and verify dbreplication (repair, reboot if you nned to) is
correct then take a good backup and move ahead with rebuild. Now if you question,
why to rebuild if everything is good - because it will again go into read only mode
or start having dbreplication issues or file system errors in a week or two.

2) Regards to your question of backup restore, if possible best approach would be


to restore from backup. Thats how Cisco recommends, in the doc, if you go to
replacing a subscriber section. That works fine.

3) And for your server accesibilty and errors, I would suggest you to run a
recovery disk and recover your server first. It would require a reboot.

4) In the end, if you are not able to recover your server by all means, then
consult with TAC and rebuild the server and let dbreplication do the work, if you
dont have a recent good backup. But again I would say if you must do this way get
full consultation from TAC first.

When I ran into this first time, TAC recommended to first recover the server to
normal to minimize any risk. Everything went fine with that approach.

Terry

Sent from my iPhone

On 03/01/2013, at 11:21 PM, costas georgiou <ckos1976 at hotmail.com> wrote:


Hi Terry,

Thanks for the info, appreciate it. I was going to rebuild then let replication do
its thing, do you suggest restoring with a backup? Currently replication is not
working, I was going to rebuild the subscriber then do a reboot on all servers
probably on Monday to sort out replication. The reason for this is because I have
top raise a change request, I have only joined this company and found the server
down when I downloaded RTMT. Also, just to let you know, I cannot access the
faulty sub, i get to the CLI enter username and password then get lots of error
messages and it hangs. Cisco recommended the rebuild.

Regards
Costas

Subject: Re: [cisco-voip] No access to Publisher


From: terry.cheema at gmail.com
Date: Thu, 3 Jan 2013 23:15:04 +1100
To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net

To add further to below mail:

Once you record all information. Take a backup of your system.


Shut down the server and rebuild the new server with information at your hand.
In the end restore back up data to this node.

Terry

Sent from my iPhone

On 03/01/2013, at 10:54 PM, Terry Cheema <terry.cheema at gmail.com> wrote:

Hi Costas,

While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.

Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml
I have done this few times, and in one case eventually I had to rebuild the whole
cluster. Whats the hardware? I had done this on MCS servers, but process will be
almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.

I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:

1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)

2) Record your administrator login/pwd

3) Record application login/pwd

4) run and record output from cli - show network eth0


It will give you ip address, subnet, default gateway, duplex, dns etc all network
related info

5) run and record output from cli - utils ntp status. Will give all ntp servers

6) run and record output command show status from CLI, will show hostname, license
mac etc.

7) Record all device information etc from RTMT device summary


prior and match the same post rebuilt.

8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize

Hope that helps and let us know if you have any other query.

Terry

PS : excuse fonts from iphone notes :)


Sent from my iPhone

On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com> wrote:


Hi All,

I have been informed by Cisco that I have to rebuild my subscriber (version 8.5),
are there any good Cisco docs out there on rebuilds?

Regards

Cos

From: salamka at gmail.com


Date: Thu, 20 Dec 2012 16:05:35 +0530
Subject: Re: [cisco-voip] No access to Publisher
To: ckos1976 at hotmail.com
CC: davidytk at netvigator.com; cisco-voip at puck.nether.net

You got a remote console , like iLO or Vsphere ?

---AS

On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at hotmail.com> wrote:

Hi,

Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.

From: davidytk at netvigator.com


To: ckos1976 at hotmail.com; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] No access to Publisher
Date: Thu, 20 Dec 2012 17:39:11 +0800
Try to restart the Tomcat service in Pub & Sub

Util service restart Cisco Tomcat

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of costas georgiou
Sent: Thursday, December 20, 2012 5:32 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] No access to Publisher

Hi All,

I was wondering whether anyone has come across this before. I have just started at
a new company and they have a CUCM cluster running 8.5.1, they have one pub and two
subs. I downloaded RTMT and noticed that one of the subs was not accessible, I can
ping the IP address, but cannot access it via SSH or URL, someone should be going
to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.

Any Ideas.

Regards

Costas

__________ Information from ESET NOD32 Antivirus, version of virus signature


database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature


database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/48f6995f/attachment.html>

From chrward at cisco.com Thu Jan 3 11:15:17 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Thu, 3 Jan 2013 16:15:17 +0000
Subject: [cisco-voip] No access to Publisher
In-Reply-To: <BLU174-W422A2557D0879D4AE967E9D2210@phx.gbl>
References: <BLU174-W3DD4536E1CF5AD7768B1FD2370@phx.gbl>
<006901cdde95$ddc4ad80$994e0880$@com>
<BLU174-W11BBB4BF5838982980836ED2370@phx.gbl>
<CAKav0XS31BFuyEjFykKRx5r5fWr2cT-f5d67KpwMK1MO5PfMOg@mail.gmail.com>
<BLU174-W132F70007E327A7F9A38F4D2210@phx.gbl>
<81490114-72D1-4F33-AD06-292E8C5516A6@gmail.com>
<5FB65336-EDDF-46A4-AFB2-DDD95D0A2D3F@gmail.com>
<BLU174-W8123B4C672C665F3898B6D2210@phx.gbl>
<38B85D43-C2BF-41B9-9432-F4AAB6E18898@gmail.com>
<BLU174-W135B28071F9C3411896663D2210@phx.gbl>,
<BF7A14DC-23EE-48F8-8BF6-D77DE8BBD9E9@gmail.com>
<BLU174-W422A2557D0879D4AE967E9D2210@phx.gbl>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1CB1DF@xmb-rcd-x13.cisco.com>

Without a DRS restore there are certain things that won't be automatically pushed
back to a rebuilt subscriber:

1) Service Activations

2) TFTP Files

3) Non-standard or COP installed phone firmware

4) MOH Files

5) Server certificates
There may be some other but just be aware of these things that you will have to
manually correct.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of costas georgiou
Sent: Thursday, January 03, 2013 10:54 AM
To: terry.cheema at gmail.com
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] No access to Publisher

Hi Terry,

Thanks for the info. Cisco are recommending I rebuild the server as if it were a
fresh install on CUCM, the Publisher will then push the configuration to the
Subscriber once added to the cluster again.

Thanks
Cos

________________________________
CC: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
From: terry.cheema at gmail.com<mailto:terry.cheema at gmail.com>
Subject: Re: [cisco-voip] No access to Publisher
Date: Fri, 4 Jan 2013 00:28:15 +1100
To: ckos1976 at hotmail.com<mailto:ckos1976 at hotmail.com>
If you have tried the recovery disk already then I think you may not have much
options left. You would probably try rebuilding the server with the procedure TAC
is recommending.

Since you are restoring on subscriber only, even if you restore from 6th December
backup, dbreplication should take care for the rest. Is TAC recommending this way?
How bad is your dbreplication, its just bad on this server, rest two have good
status??

If not already given, ask TAC to give you a precise action plan and follow that
closely. That may be your best bet.

Good luck with that, keep us posted !!

Terry

Sent from my iPhone

On 04/01/2013, at 12:09 AM, costas georgiou <ckos1976 at


hotmail.com<mailto:ckos1976 at hotmail.com>> wrote:
Cheers Terry,

We tried the recovery disk yesterday, it stated that it was successful and then we
were getting the same errors. I sent the errors over to TAC and they came back
with rebuilding from backup, but the earliest backup we have is Dec 6th.

Regards

Costas

________________________________
Subject: Re: [cisco-voip] No access to Publisher
From: terry.cheema at gmail.com<mailto:terry.cheema at gmail.com>
Date: Thu, 3 Jan 2013 23:56:36 +1100
To: ckos1976 at hotmail.com<mailto:ckos1976 at hotmail.com>
Hi Costas,

Not a problem. Few things i would suggest.

1) First of all try if you can recover the servers using recovery disk. Once you
can access the servers and verify dbreplication (repair, reboot if you nned to) is
correct then take a good backup and move ahead with rebuild. Now if you question,
why to rebuild if everything is good - because it will again go into read only mode
or start having dbreplication issues or file system errors in a week or two.

2) Regards to your question of backup restore, if possible best approach would be


to restore from backup. Thats how Cisco recommends, in the doc, if you go to
replacing a subscriber section. That works fine.

3) And for your server accesibilty and errors, I would suggest you to run a
recovery disk and recover your server first. It would require a reboot.

4) In the end, if you are not able to recover your server by all means, then
consult with TAC and rebuild the server and let dbreplication do the work, if you
dont have a recent good backup. But again I would say if you must do this way get
full consultation from TAC first.

When I ran into this first time, TAC recommended to first recover the server to
normal to minimize any risk. Everything went fine with that approach.

Terry

Sent from my iPhone

On 03/01/2013, at 11:21 PM, costas georgiou <ckos1976 at


hotmail.com<mailto:ckos1976 at hotmail.com>> wrote:
Hi Terry,

Thanks for the info, appreciate it. I was going to rebuild then let replication do
its thing, do you suggest restoring with a backup? Currently replication is not
working, I was going to rebuild the subscriber then do a reboot on all servers
probably on Monday to sort out replication. The reason for this is because I have
top raise a change request, I have only joined this company and found the server
down when I downloaded RTMT. Also, just to let you know, I cannot access the
faulty sub, i get to the CLI enter username and password then get lots of error
messages and it hangs. Cisco recommended the rebuild.

Regards
Costas

________________________________
Subject: Re: [cisco-voip] No access to Publisher
From: terry.cheema at gmail.com<mailto:terry.cheema at gmail.com>
Date: Thu, 3 Jan 2013 23:15:04 +1100
To: ckos1976 at hotmail.com<mailto:ckos1976 at hotmail.com>; cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net>
To add further to below mail:

Once you record all information. Take a backup of your system.


Shut down the server and rebuild the new server with information at your hand.
In the end restore back up data to this node.

Terry

Sent from my iPhone

On 03/01/2013, at 10:54 PM, Terry Cheema <terry.cheema at


gmail.com<mailto:terry.cheema at gmail.com>> wrote:
Hi Costas,

While rebuiding servers most critical thing is you need to record info from old
servers and enter the same information in new servers.

Please refer to the below document and read carefully. It has all the pre-
checklists and post check lists. The pre-checklist has all the information you
need to gather before you start the rebuild, which is very critical.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_5_1/cluster/clstr851.h
tml

I have done this few times, and in one case eventually I had to rebuild the whole
cluster. Whats the hardware? I had done this on MCS servers, but process will be
almost same even if you have UCS, where you can simply create a new VM. But you
need to gather and record all information before you start the rebuild. When you
rebuild, all the information on server being rebuilt should be exactly same as per
original server.

I will try to quickly summarize the info you would need to collect before you
start, but still i will highly encourage you to go through the above link, its best
resource. Below information you will be asked when you are rebuilding the server:

1) Get your security password for the cluster (very important, reqd for
dbreplication, you have to be 200% sure, if you are not sure, go ahead and first
change it on all servers - i think you can do from recovery disk, if you dont know
the security pwd, if i correctly remember, and you need to restart all servers
after changing)

2) Record your administrator login/pwd

3) Record application login/pwd

4) run and record output from cli - show network eth0


It will give you ip address, subnet, default gateway, duplex, dns etc all network
related info

5) run and record output from cli - utils ntp status. Will give all ntp servers

6) run and record output command show status from CLI, will show hostname, license
mac etc.

7) Record all device information etc from RTMT device summary


prior and match the same post rebuilt.

8) After rebuilt make sure dbreplication is good, may take abt 15-20 mins to
syncronize

Hope that helps and let us know if you have any other query.

Terry

PS : excuse fonts from iphone notes :)

Sent from my iPhone

On 03/01/2013, at 9:43 PM, costas georgiou <ckos1976 at hotmail.com<mailto:ckos1976


at hotmail.com>> wrote:
Hi All,

I have been informed by Cisco that I have to rebuild my subscriber (version 8.5),
are there any good Cisco docs out there on rebuilds?

Regards

Cos
________________________________
From: salamka at gmail.com<mailto:salamka at gmail.com>
Date: Thu, 20 Dec 2012 16:05:35 +0530
Subject: Re: [cisco-voip] No access to Publisher
To: ckos1976 at hotmail.com<mailto:ckos1976 at hotmail.com>
CC: davidytk at netvigator.com<mailto:davidytk at netvigator.com>; cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net>
You got a remote console , like iLO or Vsphere ?

---AS

On Thu, Dec 20, 2012 at 3:15 PM, costas georgiou <ckos1976 at


hotmail.com<mailto:ckos1976 at hotmail.com>> wrote:
Hi,

Thanks for getting back to me. I tried restarting Tomcat on the pub and I can
access it for a while then I can't. Tomcat service on the Sub, i cannot restart
yet as I cannot access the server. DO you think these problems are due to the Sub
being down? I think this server has been down for a few days.

________________________________
From: davidytk at netvigator.com<mailto:davidytk at netvigator.com>
To: ckos1976 at hotmail.com<mailto:ckos1976 at hotmail.com>; cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] No access to Publisher
Date: Thu, 20 Dec 2012 17:39:11 +0800

Try to restart the Tomcat service in Pub & Sub

Util service restart Cisco Tomcat

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of costas georgiou
Sent: Thursday, December 20, 2012 5:32 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] No access to Publisher

Hi All,

I was wondering whether anyone has come across this before. I have just started at
a new company and they have a CUCM cluster running 8.5.1, they have one pub and two
subs. I downloaded RTMT and noticed that one of the subs was not accessible, I can
ping the IP address, but cannot access it via SSH or URL, someone should be going
to the site today to re-boot. The day after, I could no longer access the
Publisher, this server I can access via SSH, but cannot access via URL or RMTM, I
stopped and started the Tomcat service and it came back for a while, but after a
while i cannot access again.

Any Ideas.

Regards

Costas
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com<http://www.eset.com/>

__________ Information from ESET NOD32 Antivirus, version of virus signature


database 7819 (20121220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com<http://www.eset.com/>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/517bb909/attachment.html>

From svoll.voip at gmail.com Thu Jan 3 14:03:23 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Thu, 3 Jan 2013 11:03:23 -0800
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
Message-ID: <CAHgd+3_mp35-QojV+-RZFeiNfCb20XQ3EJMat9XgvUPy4Q4p_g@mail.gmail.com>

As others have already stated. you will need a 3rd party app. We ended up
with CallRex. It has a Great Web interface for the end users and API's if
you want to build a app to interface with it.

As a added benefit, if you end up using Extension Mobility you don't have
to associated phones to the Call Recording application. you just associate
extMob profiles. That way if your not recording All phone in your org, you
don't have to worry about associating the right phones.

YMMV

Scott

On Wed, Jan 2, 2013 at 5:47 PM, Robert Hass <robhass at gmail.com> wrote:

> Hi
> My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM
> without Contact Center).
> We considering two options of call recording
> a) record all voice calls
> b) record voice calls on demand - user can turn on/off recording via xml
> application of softkey on the phone
>
> My question : Are above scenarios of call recording are possible on CUCM ?
> What else I need - probably server for call-recording with big amount of
> storange and some additional software (Zoom ? Cisco ?)
>
> thanks for help
>
> Rob
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/61c06b36/attachment.html>

From svoll.voip at gmail.com Thu Jan 3 14:05:22 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Thu, 3 Jan 2013 11:05:22 -0800
Subject: [cisco-voip] Calling Party Transformation Patterns on CUCM 8.x
In-Reply-To: <F8E0CC3253A10C4CB137F12F568DAD061A96F325B9@GBLONZ-PMSGEM02.emrsn.org>
References: <F8E0CC3253A10C4CB137F12F568DAD061A96F325B9@GBLONZ-PMSGEM02.emrsn.org>
Message-ID: <CAHgd+3-bMYHATsZMmf3GsyX9LRvPwwfUcUa_FJBPhaVzbUxu3Q@mail.gmail.com>

Can you just set it on the line and pass it through to the sip trunk?

Scott

On Thu, Jan 3, 2013 at 4:38 AM, <Zoltan.Kelemen at emerson.com> wrote:

> Hi and a Happy New Year!****


>
> ** **
>
> CUCM 8.5.1 and I?m trying to globalize calling numbers of outgoing calls
> on a specific SIP trunk.****
>
> ** **
>
> My problem is, there are more than one DID ranges, i.e.:****
>
> 1XXX numbers would have +40 345 671 XXX****
>
> 2XXX numbers would have +40 341 232 XXX****
>
> ** **
>
> I want to make sure to set the proper caller ID/calling number on outgoing
> calls. (I can do that since it?s an internal SIP trunk, so any callerID is
> ok)****
>
> ** **
>
> So I?ve created a partition and a CSS for transformations and added a
> Calling Party Transformation Pattern (Call Routing > Transformation >
> Transformation Pattern > Calling Party Transformation Pattern), applied it
> properly to the SIP trunk etc.****
>
> ** **
>
> For testing I have created a single test pattern, with my own extension:
> 2356****
>
> This matched and applied the transformations I was expecting. I tested it
> with changing the transformations, it kept working.****
>
> ** **
>
> However, when I rewrote the pattern to 2XXX it stopped matching. Basically
> it seems that I?m unable to use any non-specific pattern to match the
> calling party number. (neither 2!, nor 235X nor anything else that I?ve
> tried seems to match)****
>
> ** **
>
> Any ideas?****
>
> ** **
>
> Thanks,****
>
> *Zoltan Kelemen**
> *Emerson****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/5f6499fe/attachment.html>

From erickbee at gmail.com Thu Jan 3 14:25:09 2013


From: erickbee at gmail.com (Erick B.)
Date: Thu, 3 Jan 2013 13:25:09 -0600
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CAHgd+3_mp35-QojV+-RZFeiNfCb20XQ3EJMat9XgvUPy4Q4p_g@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
<CAHgd+3_mp35-QojV+-RZFeiNfCb20XQ3EJMat9XgvUPy4Q4p_g@mail.gmail.com>
Message-ID: <CAHSnBQymi0iW4ieZbkQ9UH=vtki8_iJ19QHyoCCqavo8tC0xRQ@mail.gmail.com>

To chime in on what others have said, with the built in bridge you enable
recording per DN. There is a option to record call calls or have it user or
application controlled on the CUCM side also. I haven't done it that way
yet. I tried user controlled on a 9971 but had problems with the record
button working.
The 3rd party applications all vary in way they operate and features, etc.
With some you can tell the 3rd party app what extensions to record, what
time, and just inbound calls or outbound, etc.

On Thu, Jan 3, 2013 at 1:03 PM, Scott Voll <svoll.voip at gmail.com> wrote:

> As others have already stated. you will need a 3rd party app. We ended up
> with CallRex. It has a Great Web interface for the end users and API's if
> you want to build a app to interface with it.
>
> As a added benefit, if you end up using Extension Mobility you don't have
> to associated phones to the Call Recording application. you just associate
> extMob profiles. That way if your not recording All phone in your org, you
> don't have to worry about associating the right phones.
>
> YMMV
>
> Scott
>
>
> On Wed, Jan 2, 2013 at 5:47 PM, Robert Hass <robhass at gmail.com> wrote:
>
>> Hi
>> My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM
>> without Contact Center).
>> We considering two options of call recording
>> a) record all voice calls
>> b) record voice calls on demand - user can turn on/off recording via xml
>> application of softkey on the phone
>>
>> My question : Are above scenarios of call recording are possible on CUCM
>> ? What else I need - probably server for call-recording with big amount of
>> storange and some additional software (Zoom ? Cisco ?)
>>
>> thanks for help
>>
>> Rob
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/1ebc6b19/attachment.html>
From jsteinberg at gmail.com Thu Jan 3 15:30:00 2013
From: jsteinberg at gmail.com (Justin Steinberg)
Date: Thu, 3 Jan 2013 15:30:00 -0500
Subject: [cisco-voip] VG350 support in 8.5 ?
Message-ID: <CACCAghbsbxC4mtObcUNh8EJo3-T-w4MzfbVVRgcdJCNfoHh=wQ@mail.gmail.com>

Does anyone know if CM 8.5.1su5 will support the VG350 ?

The VG350 release notes say 8.62a and 9.0.1, but in the 8.5.1su5 release
notes it mentions a resolved caveat around the VG350.

CSCtu07982 : QED changes to add support for VG350 gateways and service
modules

I am curious whether that means full support for the new gateway on 8.5.

Thanks.

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/426b747d/attachment.html>

From rratliff at cisco.com Thu Jan 3 15:41:20 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Thu, 3 Jan 2013 15:41:20 -0500
Subject: [cisco-voip] VG350 support in 8.5 ?
In-Reply-To: <CACCAghbsbxC4mtObcUNh8EJo3-T-w4MzfbVVRgcdJCNfoHh=wQ@mail.gmail.com>
References: <CACCAghbsbxC4mtObcUNh8EJo3-T-w4MzfbVVRgcdJCNfoHh=wQ@mail.gmail.com>
Message-ID: <E79BBD61-3E38-4D9A-8A02-E31F9E61290A@cisco.com>

QED is what we call the stuff that adds device support to CCMAdmin. A device pack
or SU that's later than any version that bug is fixed in will get you VG350
support.

-Ryan

On Jan 3, 2013, at 3:30 PM, Justin Steinberg <jsteinberg at gmail.com> wrote:

Does anyone know if CM 8.5.1su5 will support the VG350 ?

The VG350 release notes say 8.62a and 9.0.1, but in the 8.5.1su5 release notes it
mentions a resolved caveat around the VG350.

CSCtu07982 : QED changes to add support for VG350 gateways and service modules

I am curious whether that means full support for the new gateway on 8.5.

Thanks.

Justin
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/aff494d3/attachment.html>

From jsteinberg at gmail.com Thu Jan 3 15:56:22 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Thu, 3 Jan 2013 15:56:22 -0500
Subject: [cisco-voip] VG350 support in 8.5 ?
In-Reply-To: <E79BBD61-3E38-4D9A-8A02-E31F9E61290A@cisco.com>
References: <CACCAghbsbxC4mtObcUNh8EJo3-T-w4MzfbVVRgcdJCNfoHh=wQ@mail.gmail.com>
<E79BBD61-3E38-4D9A-8A02-E31F9E61290A@cisco.com>
Message-ID: <CACCAghYCnqdgF=fFEj5euFxaPy_ZxVmnh16CpDO5Wrg1tt5MLw@mail.gmail.com>

Great, thanks.

On Thu, Jan 3, 2013 at 3:41 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> QED is what we call the stuff that adds device support to CCMAdmin. A
> device pack or SU that's later than any version that bug is fixed in will
> get you VG350 support.
>
> -Ryan
>
> On Jan 3, 2013, at 3:30 PM, Justin Steinberg <jsteinberg at gmail.com> wrote:
>
> Does anyone know if CM 8.5.1su5 will support the VG350 ?
>
> The VG350 release notes say 8.62a and 9.0.1, but in the 8.5.1su5 release
> notes it mentions a resolved caveat around the VG350.
>
> CSCtu07982 : QED changes to add support for VG350 gateways and service
> modules
>
> I am curious whether that means full support for the new gateway on 8.5.
>
> Thanks.
>
> Justin
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/a2cdc0fa/attachment.html>

From Dennis.Heim at wwt.com Thu Jan 3 16:55:04 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Thu, 3 Jan 2013 15:55:04 -0600
Subject: [cisco-voip] SIP SRST Configuration
Message-ID: <0CC57FCAB07CEB4595526952471493D316F234407F@PRODCMS1.wwt.local>

Does anyone have a sip srst configuration I could look at?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/0de42477/attachment.html>

From VanMarenNP at ldschurch.org Thu Jan 3 18:20:59 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Thu, 3 Jan 2013 23:20:59 +0000
Subject: [cisco-voip] SIP SRST Configuration
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F234407F@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F234407F@PRODCMS1.wwt.local>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E44421@W12112.ldschurch.org>

SIP SRST

voice service voip

sip

registrar server

voice register global

Mode SRST

system message Blah

max-dn 100

max-pool 1

source-address 10.10.32.254 port 5060

voice register pool 1

translation-profile incoming SRST-IN

id network 0.0.0.0 mask 0.0.0.0

voice translation-rule 30

rule 1 /^\(1..\)/ /62144\1/

rule 1 /^\(19..\)/ /+15115115138\1/

voice translation-profile SRST-IN

translate called 30

interface Loopback10
ip address 192.168.255.255 255.255.255.255

call-manager-fallback

max-conferences 8 gain -6

transfer-system full-consult

ip source-address 10.19.13.5 port 2000

max-ephones 58

max-dn 10 octo-line

moh flash0:/MOH-MOTAB.wav

multicast moh 239.1.1.1 port 16384 route 192.168.255.255 10.1.68.268

ccm-manager music-on-hold

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Heim, Dennis
Sent: Thursday, January 03, 2013 2:55 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] SIP SRST Configuration

Does anyone have a sip srst configuration I could look at?

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/85d2754a/attachment.html>

From JOrr at parknationalbank.com Thu Jan 3 20:54:49 2013


From: JOrr at parknationalbank.com (Orr, Jeff B.)
Date: Fri, 4 Jan 2013 01:54:49 +0000
Subject: [cisco-voip] Call Recording on CUCM
In-Reply-To: <CALNfFTHLmMJeiUTcSyWBP9PfmReg4WWKOMRa2HMsz1E-_4q14w@mail.gmail.com>
References: <CALNfFTG7BKtQ6dQqoLpp4Va8WP+=qsC5-094GP9_Vws6TzTvPQ@mail.gmail.com>
<72FE638DB23C1049AA265B28B5F87F3364A56940@prk-alford-mbx1.PRK.LOCAL>,
<CALNfFTHLmMJeiUTcSyWBP9PfmReg4WWKOMRa2HMsz1E-_4q14w@mail.gmail.com>
Message-ID: <FB3FA53C-BA3E-4740-93A6-CF3EC100FCB7@parknationalbank.com>

I am only doing selected DNs in a call center, and a group that has regulatory
requirements for calls to be recorded. Zoom?s on-demand feature allows the user to
select a call to be ?recorded? either during the call, or up to 30 minutes after it
is completed. This is done by an XML service on the call-recording server accessed
by a subscribed service on those users? phones.

With the ?pre-record? feature, all calls on line are recorded, but discarded after
a time period unless the user requests the call to be saved.

Jeff

Sent from my iPad

On Jan 3, 2013, at 8:27 AM, "Robert Hass" <robhass at gmail.com<mailto:robhass at


gmail.com>> wrote:

Thanks for info


Are you recording allcalls or only selected DNs ?
Is it possible to on/off recording by user using some XML application or soft key
on user's phone ?

Rob

On Thursday, January 3, 2013, Orr, Jeff B. wrote:


Hi Rob,

I just went through this for our environment. Call manager will provide the backend
requirements to do recordings. However, you will need a 3rd party software to
actually record and store the calls.

We evaluated several options and went with Zoom. It is a nice, Linux based
recording software. It fully supports spanless recordings and can function as
record all the time or on-demand recording. It does this by actually recording
every call, and then allowing a user to press a service button to record a call
that occurred earlier.

Jeff

____________________________________
Jeff Orr
Technical Services - Network Engineer
Park National Corporation (AMEX: PRK)

This message is confidential and is intended only for the named recipients, and may
contain information that is privileged, or exempt from disclosure under applicable
law. If you are not the intended recipients of the email, you are hereby notified
that the dissemination, distribution or copying of this e-mail or its contents is
strictly prohibited. If you received this e-mail in error, please notify the sender
at either the e-mail address or the phone number above and delete this e-mail from
your computer.

From: cisco-voip-bounces at puck.nether.net<javascript:_e({},%20'cvml',%20'cisco-


voip-bounces at puck.nether.net');> [mailto:cisco-voip-bounces at
puck.nether.net<javascript:_e({},%20'cvml',%20'cisco-voip-bounces at
puck.nether.net');>] On Behalf Of Robert Hass
Sent: Wednesday, January 02, 2013 8:47 PM
To: cisco-voip
Subject: [cisco-voip] Call Recording on CUCM
Hi
My boss asked if we can enable call recording on our CUCM 8.6 (just CUCM without
Contact Center).
We considering two options of call recording
a) record all voice calls
b) record voice calls on demand - user can turn on/off recording via xml
application of softkey on the phone

My question : Are above scenarios of call recording are possible on CUCM ? What
else I need - probably server for call-recording with big amount of storange and
some additional software (Zoom ? Cisco ?)

thanks for help

Rob

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/d580a8a7/attachment.html>

From Robin.Clayton at rrfa.org.uk Fri Jan 4 05:41:17 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 4 Jan 2013 10:41:17 +0000
Subject: [cisco-voip] adding multiple speed dial buttons to 7915
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3B99B15@SV-C-EXCHMB-
01.richardrose.internal>

CCM 7.x

How can one bulk add speed dials to a 7915?

Every time I go to modify buttons I can only select SD once?

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/35fd1665/attachment.html>

From Robin.Clayton at rrfa.org.uk Fri Jan 4 07:12:29 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 4 Jan 2013 12:12:29 +0000
Subject: [cisco-voip] adding multiple speed dial buttons to 7915
In-Reply-To: <883574BD6A83B04EAA11A5B54F4DFFE3B99B15@SV-C-EXCHMB-
01.richardrose.internal>
References: <883574BD6A83B04EAA11A5B54F4DFFE3B99B15@SV-C-EXCHMB-
01.richardrose.internal>
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3B99B4A@SV-C-EXCHMB-
01.richardrose.internal>

Sorted....

Created a new phone template with 54 buttons.

Now to remember how to use bat...

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Robin Clayton
Sent: 04 January 2013 10:41
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] adding multiple speed dial buttons to 7915

CCM 7.x

How can one bulk add speed dials to a 7915?

Every time I go to modify buttons I can only select SD once?


Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.
The Richard Rose Federation<http://www.rrfa.org.uk>

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/4d5e5c6c/attachment.html>

From rkulagow at gmail.com Fri Jan 4 09:35:41 2013


From: rkulagow at gmail.com (Robert Kulagowski)
Date: Fri, 4 Jan 2013 08:35:41 -0600
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
Message-ID: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
Since no one who knows anything for real is probably going to say
anything for now, are there any mitigating factors that I can start
thinking about once management sees the following article?

http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite

From ealeatherman at gmail.com Fri Jan 4 10:00:26 2013


From: ealeatherman at gmail.com (Ed Leatherman)
Date: Fri, 4 Jan 2013 10:00:26 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
Message-ID: <CAFC4dsoeSVQZ86+MnC1nxmbDzuCZAPbiPapUcU=A8ZtEdCpG4A@mail.gmail.com>

Hah i just had someone ask me about this same article this morning. There
was a article on it in IEEE Spectrum also - neither article seemed to give
enough info for customers to take specific action on.

On Fri, Jan 4, 2013 at 9:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:

> Since no one who knows anything for real is probably going to say
> anything for now, are there any mitigating factors that I can start
> thinking about once management sees the following article?
>
>
> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/2d7b0324/attachment.html>

From svoll.voip at gmail.com Fri Jan 4 10:02:45 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Fri, 4 Jan 2013 07:02:45 -0800
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
Message-ID: <CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>

Lelio sent this out a week or two ago.


http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-vulnerable
Check out the video.

We are a closed facility, so the attacker would have to either be inside,


or take a phone off the wall in a reception area AND have SSH access.
I talked to my SE and he said:
Workaround = Restrict SSH and CLI access to trusted users only.
Administrators may consider leveraging 802.1x device authentication to
prevent unauthorized devices or systems from accessing the voice network.

Ang accomplished this by first gaining access to the device via SSH and
utilizing TFTP to pull down a malicious binary that is designed to exploit
the insufficient validation issue of the affected System Calls. He ran this
from the user context on the device which performed the exploit. The
caveats of this particular issue are that an attacker would need to have
Authenticated Access either via SSH (Which would need to be enabled, it is
not enabled by default), or local access via the Serial port. The attacker
would also need to be able to point the device at an attacker-controlled
TFTP server to retrieve the payload.

YMMV

Scott

On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:

> Since no one who knows anything for real is probably going to say
> anything for now, are there any mitigating factors that I can start
> thinking about once management sees the following article?
>
>
> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/d21519a5/attachment.html>

From chrward at cisco.com Fri Jan 4 10:22:22 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Fri, 4 Jan 2013 15:22:22 +0000
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1CC1D7@xmb-rcd-x13.cisco.com>

Also, this does NOT affect 7940s and 7960s as they don't run linux which is basis
of the exploit.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Scott Voll
Sent: Friday, January 04, 2013 10:03 AM
To: Robert Kulagowski
Cc: Cisco VOIP
Subject: Re: [cisco-voip] Cisco phones vulnerable to hack / remote access?

Lelio sent this out a week or two ago.


http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-vulnerable
Check out the video.

We are a closed facility, so the attacker would have to either be inside, or take a
phone off the wall in a reception area AND have SSH access.

I talked to my SE and he said:


Workaround = Restrict SSH and CLI access to trusted users only. Administrators may
consider leveraging 802.1x device authentication to prevent unauthorized devices or
systems from accessing the voice network.

Ang accomplished this by first gaining access to the device via SSH and utilizing
TFTP to pull down a malicious binary that is designed to exploit the insufficient
validation issue of the affected System Calls. He ran this from the user context on
the device which performed the exploit. The caveats of this particular issue are
that an attacker would need to have Authenticated Access either via SSH (Which
would need to be enabled, it is not enabled by default), or local access via the
Serial port. The attacker would also need to be able to point the device at an
attacker-controlled TFTP server to retrieve the payload.
YMMV
Scott

On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski <rkulagow at


gmail.com<mailto:rkulagow at gmail.com>> wrote:
Since no one who knows anything for real is probably going to say
anything for now, are there any mitigating factors that I can start
thinking about once management sees the following article?

http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/83980435/attachment.html>

From Robin.Clayton at rrfa.org.uk Fri Jan 4 10:37:53 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 4 Jan 2013 15:37:53 +0000
Subject: [cisco-voip] Adding Speed Dials to 7915 using BAT ??
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3B99C14@SV-C-EXCHMB-
01.richardrose.internal>

Guys...

CCM 7.1.5.33900-10
I have been bashing my head on this one all afternoon

I have one phone with 2 7915's

I am trying to add 50 speed dials but can't get it to work.

I followed a Cisco guide which used "insert specific phone details" and only
succeeded in wiping the phone config apart from those detail ( and some template
details).

I have tried update but that finds no records in my csv file???

Anyone got a real world working example to update BLF SD's

Cheers

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/79ec74d6/attachment.html>

From Robin.Clayton at rrfa.org.uk Fri Jan 4 10:40:09 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 4 Jan 2013 15:40:09 +0000
Subject: [cisco-voip] Adding Speed Dials to 7915 using BAT ??
In-Reply-To: <883574BD6A83B04EAA11A5B54F4DFFE3B99C14@SV-C-EXCHMB-
01.richardrose.internal>
References: <883574BD6A83B04EAA11A5B54F4DFFE3B99C14@SV-C-EXCHMB-
01.richardrose.internal>
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3B99C25@SV-C-EXCHMB-
01.richardrose.internal>

Sorry

Using BAT import/update...

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Robin Clayton
Sent: 04 January 2013 15:38
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Adding Speed Dials to 7915 using BAT ??

Guys...

CCM 7.1.5.33900-10

I have been bashing my head on this one all afternoon

I have one phone with 2 7915's

I am trying to add 50 speed dials but can't get it to work.

I followed a Cisco guide which used "insert specific phone details" and only
succeeded in wiping the phone config apart from those detail ( and some template
details).

I have tried update but that finds no records in my csv file???

Anyone got a real world working example to update BLF SD's

Cheers

Rob

=========================
Robin Clayton
Senior I.T. Technician
Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.
The Richard Rose Federation<http://www.rrfa.org.uk>

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/5ba6a258/attachment.html>

From matthnick at gmail.com Fri Jan 4 10:47:55 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Fri, 4 Jan 2013 10:47:55 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAFC4dsoeSVQZ86+MnC1nxmbDzuCZAPbiPapUcU=A8ZtEdCpG4A@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAFC4dsoeSVQZ86+MnC1nxmbDzuCZAPbiPapUcU=A8ZtEdCpG4A@mail.gmail.com>
Message-ID: <CAM-K-NrV9ZF8K6j6Ni9uQV=pcVW0MpgC5ChJovu6wVru++Y=EQ@mail.gmail.com>

This may help:


https://psirt.cisco.com/PSIRThot/7900KernelSysCall

Particularly that they need physical access or the user authentication


details for this attack to happen.

-nick

On Fri, Jan 4, 2013 at 10:00 AM, Ed Leatherman <ealeatherman at gmail.com>wrote:

> Hah i just had someone ask me about this same article this morning. There
> was a article on it in IEEE Spectrum also - neither article seemed to give
> enough info for customers to take specific action on.
>
>
> On Fri, Jan 4, 2013 at 9:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:
>
>> Since no one who knows anything for real is probably going to say
>> anything for now, are there any mitigating factors that I can start
>> thinking about once management sees the following article?
>>
>>
>> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
>
> --
> Ed Leatherman
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/e50da6f7/attachment.html>

From blake at pfankuch.me Fri Jan 4 13:44:24 2013


From: blake at pfankuch.me (Blake Pfankuch)
Date: Fri, 4 Jan 2013 18:44:24 +0000
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAM-K-NrV9ZF8K6j6Ni9uQV=pcVW0MpgC5ChJovu6wVru++Y=EQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAFC4dsoeSVQZ86+MnC1nxmbDzuCZAPbiPapUcU=A8ZtEdCpG4A@mail.gmail.com>
<CAM-K-NrV9ZF8K6j6Ni9uQV=pcVW0MpgC5ChJovu6wVru++Y=EQ@mail.gmail.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C840109D47A4A@SHSBS.shenrons-house.local>

Uhhhhh....

[blake at shlt01-centos ~]# host psirt.cisco.com


psirt.cisco.com has address 172.18.104.137

I see a problem...

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Nick Matthews
Sent: Friday, January 04, 2013 8:48 AM
To: Ed Leatherman
Cc: Cisco VOIP
Subject: Re: [cisco-voip] Cisco phones vulnerable to hack / remote access?

This may help:


https://psirt.cisco.com/PSIRThot/7900KernelSysCall
Particularly that they need physical access or the user authentication details for
this attack to happen.
-nick

On Fri, Jan 4, 2013 at 10:00 AM, Ed Leatherman <ealeatherman at


gmail.com<mailto:ealeatherman at gmail.com>> wrote:
Hah i just had someone ask me about this same article this morning. There was a
article on it in IEEE Spectrum also - neither article seemed to give enough info
for customers to take specific action on.

On Fri, Jan 4, 2013 at 9:35 AM, Robert Kulagowski <rkulagow at


gmail.com<mailto:rkulagow at gmail.com>> wrote:
Since no one who knows anything for real is probably going to say
anything for now, are there any mitigating factors that I can start
thinking about once management sees the following article?

http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

--
Ed Leatherman

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/7499f32d/attachment.html>

From lisa.notarianni at scranton.edu Fri Jan 4 14:00:52 2013


From: lisa.notarianni at scranton.edu (Lisa Notarianni)
Date: Fri, 4 Jan 2013 19:00:52 +0000
Subject: [cisco-voip] Hunt Group Question
Message-ID:
<B1D1594F698E684DB83C15828D282DD856920284@SN2PRD0310MB359.namprd03.prod.outlook.com
>
We currently do not have any groups on campus using hunt groups but have a possible
need to.
Out Financial Aid office has peak busy times when they would like to use a hunt
group. Is anyone out there familiar with the details of using them? I have some
questions I would appreciate help with:

1. Is there a tool for an administrator or office manager to use to see who


is logged into the hunt group?

2. Can we choose which phone to start sending the incoming calls to? (Main
receptionist first and then whoever else is available in the hunt group) - note -
they will all be answering the same DN.

3. If someone is logged in and a call is sent to their phone but they cannot
answer it, can you control how many times it will ring before going to the next
person in line to answer a call?

4. If someone is available - but it is not their turn to answer the call -


but they want to answer the call - can they?

5. Can you be logged into more than 1 hunt group?

6. Is there a report that shows which phone answered X number of calls,


etc...?

7. Our goal is to eventually integrate UCCX. If you have UCCX - can the
calls go from there to a hunt group?
Thank you in advance!

[LisaNotarianniSignature]

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/5d169fe3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 10828 bytes
Desc: image001.gif
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/5d169fe3/attachment.gif>

From ealeatherman at gmail.com Fri Jan 4 14:11:24 2013


From: ealeatherman at gmail.com (Ed Leatherman)
Date: Fri, 4 Jan 2013 14:11:24 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
Message-ID: <CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>

I completely missed the video at the top of the IEEE article the first time
i read it.. i think my brain saw it as an advertisement and just ignored it.

The researchers full presentation is here also:


http://www.youtube.com/watch?v=f3zUOZcewtA&feature=youtu.be

On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip at gmail.com> wrote:

> Lelio sent this out a week or two ago.


> http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-vulnerable
Check out the video.
>
> We are a closed facility, so the attacker would have to either be inside,
> or take a phone off the wall in a reception area AND have SSH access.
>
> I talked to my SE and he said:
> Workaround = Restrict SSH and CLI access to trusted users only.
> Administrators may consider leveraging 802.1x device authentication to
> prevent unauthorized devices or systems from accessing the voice network.
>
> Ang accomplished this by first gaining access to the device via SSH and
> utilizing TFTP to pull down a malicious binary that is designed to exploit
> the insufficient validation issue of the affected System Calls. He ran this
> from the user context on the device which performed the exploit. The
> caveats of this particular issue are that an attacker would need to have
> Authenticated Access either via SSH (Which would need to be enabled, it is
> not enabled by default), or local access via the Serial port. The attacker
> would also need to be able to point the device at an attacker-controlled
> TFTP server to retrieve the payload.
>
> YMMV
>
> Scott
>
>
>
>
>
> On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:
>
>> Since no one who knows anything for real is probably going to say
>> anything for now, are there any mitigating factors that I can start
>> thinking about once management sees the following article?
>>
>>
>> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/125d7df9/attachment.html>

From jsteinberg at gmail.com Fri Jan 4 14:21:39 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Fri, 4 Jan 2013 14:21:39 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
<CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
Message-ID: <CACCAghZZzjvXbDRoiwQ6ND5NuqELg4Vcsy12i3w+RDt_ped9kQ@mail.gmail.com>

Nick's link seems like an internal site. I don't see anything on the
public psirt page.

http://tools.cisco.com/security/center/publicationListing.x#~CiscoSecurityAdvisory

On Fri, Jan 4, 2013 at 2:11 PM, Ed Leatherman <ealeatherman at gmail.com>wrote:

> I completely missed the video at the top of the IEEE article the first
> time i read it.. i think my brain saw it as an advertisement and just
> ignored it.
>
> The researchers full presentation is here also:
> http://www.youtube.com/watch?v=f3zUOZcewtA&feature=youtu.be
>
>
> On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip at gmail.com> wrote:
>
>> Lelio sent this out a week or two ago.
>> http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-vulnerable
Check out the video.
>>
>> We are a closed facility, so the attacker would have to either be inside,
>> or take a phone off the wall in a reception area AND have SSH access.
>>
>> I talked to my SE and he said:
>> Workaround = Restrict SSH and CLI access to trusted users only.
>> Administrators may consider leveraging 802.1x device authentication to
>> prevent unauthorized devices or systems from accessing the voice network.
>>
>> Ang accomplished this by first gaining access to the device via SSH and
>> utilizing TFTP to pull down a malicious binary that is designed to exploit
>> the insufficient validation issue of the affected System Calls. He ran this
>> from the user context on the device which performed the exploit. The
>> caveats of this particular issue are that an attacker would need to have
>> Authenticated Access either via SSH (Which would need to be enabled, it is
>> not enabled by default), or local access via the Serial port. The attacker
>> would also need to be able to point the device at an attacker-controlled
>> TFTP server to retrieve the payload.
>>
>> YMMV
>>
>> Scott
>>
>>
>>
>>
>>
>> On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:
>>
>>> Since no one who knows anything for real is probably going to say
>>> anything for now, are there any mitigating factors that I can start
>>> thinking about once management sees the following article?
>>>
>>>
>>> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> Ed Leatherman
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/ae7108be/attachment.html>

From afrankel at cisco.com Fri Jan 4 14:24:57 2013


From: afrankel at cisco.com (Adam Frankel)
Date: Fri, 04 Jan 2013 14:24:57 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
<CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
Message-ID: <50E72C89.9050400@cisco.com>

PSIRT will be including all updated information related to this on the


defect, CSCuc83860.

Adam
------------------------------------------------------------------------
*From:* Ed Leatherman <ealeatherman at gmail.com>
*Sent:* Fri, Jan 04, 2013 2:11:24 PM
*To:* Scott Voll <svoll.voip at gmail.com>
*CC:* Cisco VOIP <cisco-voip at puck.nether.net>
*Subject:* Re: [cisco-voip] Cisco phones vulnerable to hack / remote access?

> I completely missed the video at the top of the IEEE article the first
> time i read it.. i think my brain saw it as an advertisement and just
> ignored it.
>
> The researchers full presentation is here also:
> http://www.youtube.com/watch?v=f3zUOZcewtA&feature=youtu.be
>
>
> On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip at gmail.com
> <mailto:svoll.voip at gmail.com>> wrote:
>
> Lelio sent this out a week or two ago.
> http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-
vulnerable
> Check out the video.
>
> We are a closed facility, so the attacker would have to either be
> inside, or take a phone off the wall in a reception area AND have
> SSH access.
>
> I talked to my SE and he said:
> Workaround = Restrict SSH and CLI access to trusted users only.
> Administrators may consider leveraging 802.1x device
> authentication to prevent unauthorized devices or systems from
> accessing the voice network.
>
> Ang accomplished this by first gaining access to the device via
> SSH and utilizing TFTP to pull down a malicious binary that is
> designed to exploit the insufficient validation issue of the
> affected System Calls. He ran this from the user context on the
> device which performed the exploit. The caveats of this particular
> issue are that an attacker would need to have Authenticated Access
> either via SSH (Which would need to be enabled, it is not enabled
> by default), or local access via the Serial port. The attacker
> would also need to be able to point the device at an
> attacker-controlled TFTP server to retrieve the payload.
>
> YMMV
>
> Scott
>
>
>
>
> On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski
> <rkulagow at gmail.com <mailto:rkulagow at gmail.com>> wrote:
>
> Since no one who knows anything for real is probably going to say
> anything for now, are there any mitigating factors that I can
> start
> thinking about once management sees the following article?
>
> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-
phones-vulnerable-to-eavesdropping-hack-researchers-say?lite
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> --
> Ed Leatherman
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/5cf02fba/attachment.html>

From thomaslemay at comcast.net Fri Jan 4 14:40:21 2013


From: thomaslemay at comcast.net (Thomas LeMay)
Date: Fri, 4 Jan 2013 14:40:21 -0500
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
Message-ID: <002401cdeab3$5566d2e0$003478a0$@comcast.net>

We have recently received several boxes of new 7962 phone sets from the
Cisco factory. We are running call manager version 7.1.5.34900-7 on MCS
servers (Linux). When we take several of these new 7962 phone sets and plug
them into the network port they will pull a TAPS number successfully but
fail the authentication and software upgrade portion for phone load
SCCP4.2.9-2-1S.. Is there a known work around or middle firmware version we
need to load on a TFTP server to update the phone sets? Thank you in
advance.

Tom

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/e2cc64dc/attachment.html>

From rratliff at cisco.com Fri Jan 4 14:54:22 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Fri, 4 Jan 2013 14:54:22 -0500
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
In-Reply-To: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
References: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
Message-ID: <9588778D-E912-4CB5-9B9E-C34C27D67941@cisco.com>

What load is coming on them? If it's old enough it can't go straight to 9-2-1 and
has to hit an interim first.
See
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/firmware/9_2_1/english/release
/notes/7900_921.html#wp42493.

-Ryan

On Jan 4, 2013, at 2:40 PM, Thomas LeMay <thomaslemay at comcast.net> wrote:

We have recently received several boxes of new 7962 phone sets from the Cisco
factory. We are running call manager version 7.1.5.34900-7 on MCS servers (Linux).
When we take several of these new 7962 phone sets and plug them into the network
port they will pull a TAPS number successfully but fail the authentication and
software upgrade portion for phone load SCCP4.2.9-2-1S.. Is there a known work
around or middle firmware version we need to load on a TFTP server to update the
phone sets? Thank you in advance.

Tom
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/e78bd57d/attachment.html>

From florian.kroessbacher at gmail.com Fri Jan 4 15:01:34 2013


From: florian.kroessbacher at gmail.com (Florian Kroessbacher)
Date: Fri, 4 Jan 2013 21:01:34 +0100
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
In-Reply-To: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
References: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
Message-ID: <BA0F7185-481F-4C44-B912-50B1C240BC73@gmail.com>

Hy

mabe your hardware is very very new than u can hit this

read here for

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7900_series/firmware/9_3_1SR1/
release_notes/P790_BK_R4E1E768_00_rn-9_3_1_sr1-7900-
series_chapter_00.html#P790_RF_F4EA96A6_00

Features Available with Firmware Release


The following sections describe the features available in the firmware.
Hardware Updates
Hardware Updates
The hardware updates improve the compatibility of internal phone components.
The following table lists the updated hardware versions that require this release.
Phone
Hardware Version
Cisco Unified Wireless IP Phone 7942G
15.0 and higher
Cisco Unified Wireless IP Phone 7962G
15.0 and higher
Cisco Unified Wireless IP Phone 7945G
13.0 and higher
Cisco Unified Wireless IP Phone 7965G
13.0 and higher
Cisco Unified Wireless IP Phone 7975G
12.0 and higher
Phones manufactured with these hardware versions must run Firmware Release
9.3(1)SR1 or later. The phone firmware does not allow the phone to be downgraded to
releases earlier than Release 9.3(1)SR1.

--
Florian Kroessbacher
gmail: florian.kroessbacher at gmail.com

Am 04.01.2013 um 20:40 schrieb "Thomas LeMay" <thomaslemay at comcast.net>:

> We have recently received several boxes of new 7962 phone sets from the Cisco
factory. We are running call manager version 7.1.5.34900-7 on MCS servers (Linux).
When we take several of these new 7962 phone sets and plug them into the network
port they will pull a TAPS number successfully but fail the authentication and
software upgrade portion for phone load SCCP4.2.9-2-1S.. Is there a known work
around or middle firmware version we need to load on a TFTP server to update the
phone sets? Thank you in advance.
>
> Tom
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/1bbe5f5b/attachment.html>

From chrward at cisco.com Fri Jan 4 15:06:27 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Fri, 4 Jan 2013 20:06:27 +0000
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
In-Reply-To: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
References: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1CC6FF@xmb-rcd-x13.cisco.com>

What's the current load on the phone? There was an old issue where 8.3.2 and
earlier couldn't upgrade directly to 8.5.1 or later without an interim release. If
you move them to something like an 8.4.4 first or 8.3.3 first, that would work
around this issue.

https://supportforums.cisco.com/docs/DOC-24326

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Thomas LeMay
Sent: Friday, January 04, 2013 2:40 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication

We have recently received several boxes of new 7962 phone sets from the Cisco
factory. We are running call manager version 7.1.5.34900-7 on MCS servers (Linux).
When we take several of these new 7962 phone sets and plug them into the network
port they will pull a TAPS number successfully but fail the authentication and
software upgrade portion for phone load SCCP4.2.9-2-1S.. Is there a known work
around or middle firmware version we need to load on a TFTP server to update the
phone sets? Thank you in advance.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/48d2f7da/attachment.html>

From thomaslemay at comcast.net Fri Jan 4 15:18:15 2013


From: thomaslemay at comcast.net (Thomas LeMay)
Date: Fri, 4 Jan 2013 15:18:15 -0500
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA1CC6FF@xmb-rcd-x13.cisco.com>
References: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
<C3D1FCA271936B48839E081F898E17AA1CC6FF@xmb-rcd-x13.cisco.com>
Message-ID: <003e01cdeab8$a11c7050$e35550f0$@comcast.net>

Hi, Chris,

The current load for SCCP 7962 is SCCP42.9-2-1S.

Tom

From: Chris Ward (chrward) [mailto:chrward at cisco.com]


Sent: Friday, January 04, 2013 3:06 PM
To: thomaslemay at comcast.net; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] 7962 Phone Sets Failing Authentication

What's the current load on the phone? There was an old issue where 8.3.2 and
earlier couldn't upgrade directly to 8.5.1 or later without an interim
release. If you move them to something like an 8.4.4 first or 8.3.3 first,
that would work around this issue.

https://supportforums.cisco.com/docs/DOC-24326

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Thomas LeMay
Sent: Friday, January 04, 2013 2:40 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication

We have recently received several boxes of new 7962 phone sets from the
Cisco factory. We are running call manager version 7.1.5.34900-7 on MCS
servers (Linux). When we take several of these new 7962 phone sets and plug
them into the network port they will pull a TAPS number successfully but
fail the authentication and software upgrade portion for phone load
SCCP4.2.9-2-1S.. Is there a known work around or middle firmware version we
need to load on a TFTP server to update the phone sets? Thank you in
advance.

Tom

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/ec51661b/attachment.html>

From rratliff at cisco.com Fri Jan 4 15:26:18 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Fri, 4 Jan 2013 15:26:18 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
Message-ID: <01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>

To close the loop on this the restriction was added in 8.6 (when refresh upgrade
came in) because we don't test this upgrade between major versions and the fact
that we started having to do OS reinstalls (refresh) for some combinations made the
likelihood of failure too high.

It is not documented, and that will remedied in the Release Notes for 9.1 shortly
and in the Upgrade/Install docs at some point in the future (they can't be changed
as fast as release notes).

-Ryan
On Jan 2, 2013, at 4:34 PM, Matthew Loraditch <MLoraditch at
heliontechnologies.com> wrote:

Well that?s good, I can just put a PUT order in edelivery and get it. Let?s see if
it works.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Wednesday, January 02, 2013 4:22 PM
To: Tim Frazee
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.

To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.

-Ryan

On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in the
day......

In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.

Thanks for digging Ryan.

On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.
Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?

On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in the
trash and try with a real 9.0 build (I'm going to start this now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media

On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:
I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/0db64ddf/attachment.html>

From matthnick at gmail.com Fri Jan 4 15:47:08 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Fri, 4 Jan 2013 15:47:08 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <CACCAghZZzjvXbDRoiwQ6ND5NuqELg4Vcsy12i3w+RDt_ped9kQ@mail.gmail.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
<CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
<CACCAghZZzjvXbDRoiwQ6ND5NuqELg4Vcsy12i3w+RDt_ped9kQ@mail.gmail.com>
Message-ID: <CAM-K-Nq5__KvT-dg7w3m1-t+Xr-SicF0S3z0bme1Y7GAPYtVjg@mail.gmail.com>

Apologies for that, thought it was a public PSIRT. Looks like these release
notes are about the same as what I was looking at:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?
method=fetchBugDetails&bugId=CSCuc83860

On Fri, Jan 4, 2013 at 2:21 PM, Justin Steinberg <jsteinberg at gmail.com>wrote:

> Nick's link seems like an internal site. I don't see anything on the
> public psirt page.
>
>
>
http://tools.cisco.com/security/center/publicationListing.x#~CiscoSecurityAdvisory
>
>
>
> On Fri, Jan 4, 2013 at 2:11 PM, Ed Leatherman <ealeatherman at gmail.com>wrote:
>
>> I completely missed the video at the top of the IEEE article the first
>> time i read it.. i think my brain saw it as an advertisement and just
>> ignored it.
>>
>> The researchers full presentation is here also:
>> http://www.youtube.com/watch?v=f3zUOZcewtA&feature=youtu.be
>>
>>
>> On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip at gmail.com> wrote:
>>
>>> Lelio sent this out a week or two ago.
>>> http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-
vulnerable Check out the video.
>>>
>>> We are a closed facility, so the attacker would have to either be
>>> inside, or take a phone off the wall in a reception area AND have SSH
>>> access.
>>>
>>> I talked to my SE and he said:
>>> Workaround = Restrict SSH and CLI access to trusted users only.
>>> Administrators may consider leveraging 802.1x device authentication to
>>> prevent unauthorized devices or systems from accessing the voice network.
>>>
>>> Ang accomplished this by first gaining access to the device via SSH and
>>> utilizing TFTP to pull down a malicious binary that is designed to exploit
>>> the insufficient validation issue of the affected System Calls. He ran this
>>> from the user context on the device which performed the exploit. The
>>> caveats of this particular issue are that an attacker would need to have
>>> Authenticated Access either via SSH (Which would need to be enabled, it is
>>> not enabled by default), or local access via the Serial port. The attacker
>>> would also need to be able to point the device at an attacker-controlled
>>> TFTP server to retrieve the payload.
>>>
>>> YMMV
>>>
>>> Scott
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski <rkulagow at gmail.com>wrote:
>>>
>>>> Since no one who knows anything for real is probably going to say
>>>> anything for now, are there any mitigating factors that I can start
>>>> thinking about once management sees the following article?
>>>>
>>>>
>>>> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> Ed Leatherman
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/1dd13835/attachment.html>

From jason.aarons at dimensiondata.com Fri Jan 4 15:55:47 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Fri, 4 Jan 2013 15:55:47 -0500
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication
In-Reply-To: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
References: <002401cdeab3$5566d2e0$003478a0$@comcast.net>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C5EFC39@USISPCLEXDB01.na.didata.local>

What load do they have out of the box? Below SCCP 8.5.x you need to upgrade to
8.5.x before you can upgrade to 9.2.1S.

Check the release notes for SCCP 8.5 loads.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Thomas LeMay
Sent: Friday, January 04, 2013 2:40 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 7962 Phone Sets Failing Authentication

We have recently received several boxes of new 7962 phone sets from the Cisco
factory. We are running call manager version 7.1.5.34900-7 on MCS servers (Linux).
When we take several of these new 7962 phone sets and plug them into the network
port they will pull a TAPS number successfully but fail the authentication and
software upgrade portion for phone load SCCP4.2.9-2-1S.. Is there a known work
around or middle firmware version we need to load on a TFTP server to update the
phone sets? Thank you in advance.

Tom

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/5926a5e9/attachment.html>

From mail at darioquiroz.com Fri Jan 4 16:08:22 2013


From: mail at darioquiroz.com (Dario Quiroz)
Date: Fri, 4 Jan 2013 18:08:22 -0300
Subject: [cisco-voip] MWI blinking but voicemail service is not activated on
DN
Message-ID: <CAHuYCEEcD6SnJhYEQrDX9+JwR95ib+Hv=xDvgOSnc1OmggYYxw@mail.gmail.com>

HI all! We have a little problem with a CUCM 8.5.1 and Unity connection.
The MWI is blinking in some 7911 phones, but these DN doesn't have the
voice mail service activated.
Someone know why are they blinking and what is the solution for that?
Thanks in advance

--
Atenciosamente,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/d77323cb/attachment.html>

From VanMarenNP at ldschurch.org Fri Jan 4 17:10:14 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Fri, 4 Jan 2013 22:10:14 +0000
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
<01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E45C37@W12112.ldschurch.org>

This just causes trouble for rebuilding/ adding new servers to an existing cluster.
Because you have to install the same version that is running on the cluster.

-Nate
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Friday, January 04, 2013 1:26 PM
To: Matthew Loraditch
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

To close the loop on this the restriction was added in 8.6 (when refresh upgrade
came in) because we don't test this upgrade between major versions and the fact
that we started having to do OS reinstalls (refresh) for some combinations made the
likelihood of failure too high.

It is not documented, and that will remedied in the Release Notes for 9.1 shortly
and in the Upgrade/Install docs at some point in the future (they can't be changed
as fast as release notes).

-Ryan

On Jan 2, 2013, at 4:34 PM, Matthew Loraditch <MLoraditch at


heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>> wrote:

Well that's good, I can just put a PUT order in edelivery and get it. Let's see if
it works.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:voip-bounces
at puck.nether.net>] On Behalf Of Ryan Ratliff
Sent: Wednesday, January 02, 2013 4:22 PM
To: Tim Frazee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.

To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.

-Ryan

On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in the
day......

In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.

Thanks for digging Ryan.


On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at
cisco.com<mailto:rratliff at cisco.com>> wrote:
Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.
Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?
On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com<mailto:rratliff
at cisco.com>> wrote:
9.0.0.99101-22<tel:9.0.0.99101-22> is not a 9.0 ES, it's a pre-release build of
9.1. Throw it in the trash and try with a real 9.0 build (I'm going to start this
now).

-Ryan

On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at


gmail.com>> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media
On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at
ldschurch.org<mailto:VanMarenNP at ldschurch.org>> wrote:
I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com<mailto:tfrazee at
gmail.com>> wrote:
I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/b0e1dddf/attachment.html>

From svoll.voip at gmail.com Fri Jan 4 18:34:33 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Fri, 4 Jan 2013 15:34:33 -0800
Subject: [cisco-voip] Jabber 9.1 non-domain computer
Message-ID: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>

How do you setup Jabber to see the Domain contacts when it's not a Domain
PC. (example. Home end user PC).

TIA

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/c26289dd/attachment.html>

From drucker.mark at gmail.com Fri Jan 4 18:39:00 2013


From: drucker.mark at gmail.com (Mark Drucker)
Date: Fri, 4 Jan 2013 15:39:00 -0800
Subject: [cisco-voip] Jabber 9.1 non-domain computer
In-Reply-To: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>
References: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>
Message-ID: <CABUeUByvWfo-1kBZVfzpO4+e5oDeYy1_0W9Ohx43mr8J+heFfg@mail.gmail.com>

Hi Scott,

You can install the app with the below command string:

msiexec.exe /i CiscoJabberSetup.msi TYPE=WEBEX SSO_ORG_DOMAIN=DOMAIN.com


/quiet

Mark

On Fri, Jan 4, 2013 at 3:34 PM, Scott Voll <svoll.voip at gmail.com> wrote:

> How do you setup Jabber to see the Domain contacts when it's not a Domain
> PC. (example. Home end user PC).
>
> TIA
>
> Scott
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
Mark Drucker
(925) 321-5791
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130104/8727d132/attachment.html>

From jsteinberg at gmail.com Sat Jan 5 10:31:35 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Sat, 5 Jan 2013 10:31:35 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E45C37@W12112.ldschurch.org>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
<01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>
<2F143E71016CA34C924BF4C33AEF211056E45C37@W12112.ldschurch.org>
Message-ID: <CACCAghbG-_Md1iWCNLgBS3LrqVzHKU6k0ZZ8TKu1sAbo4s+vOg@mail.gmail.com>

Agreed. Especially when you can download the non-bootable upgrade ISO to
go from 9.0 to 9.1. Then if a subscriber fails, you have to get with TAC
to get a bootable 9.1 (hours), or go through the edelivery (days) all over
again. This is a time consuming process.

On Fri, Jan 4, 2013 at 5:10 PM, Nate VanMaren <VanMarenNP at ldschurch.org>wrote:

> ** **
>
> This just causes trouble for rebuilding/ adding new servers to an existing
> cluster. Because you have to install the same version that is running on
> the cluster.****
>
> ** **
>
> -Nate****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ryan Ratliff
> *Sent:* Friday, January 04, 2013 1:26 PM
> *To:* Matthew Loraditch
>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>
> ** **
>
> To close the loop on this the restriction was added in 8.6 (when refresh
> upgrade came in) because we don't test this upgrade between major versions
> and the fact that we started having to do OS reinstalls (refresh) for some
> combinations made the likelihood of failure too high.****
>
> ** **
>
> It is not documented, and that will remedied in the Release Notes for 9.1
> shortly and in the Upgrade/Install docs at some point in the future (they
> can't be changed as fast as release notes).****
>
> ** **
>
> -Ryan ****
>
> ** **
>
> On Jan 2, 2013, at 4:34 PM, Matthew Loraditch <
> MLoraditch at heliontechnologies.com> wrote:****
>
> ** **
>
> Well that?s good, I can just put a PUT order in edelivery and get it.
> Let?s see if it works.****
>
> ****
>
> ****
>
> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
> ****
>
> ****
>
> ****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:cisco-
> voip-bounces at puck.nether.net] *On Behalf Of *Ryan Ratliff
> *Sent:* Wednesday, January 02, 2013 4:22 PM
> *To:* Tim Frazee
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>
> ****
>
> I was told this restriction was added around 8.5 but I'm still waiting on
> some other folks to comment.****
>
> ****
>
> To get to 9.1 you either do a fresh install or you upgrade, same as any
> other version. I understand the release of 9.1 has immediately replaced
> 9.0 on new 9.x orders (much like 8.6 did for 8.5) so any 9.x media kit
> ordered today will be sent 9.1 bootable media.****
>
> ****
>
> -Ryan****
>
> ****
>
> On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com> wrote:****
>
>
> I could see that.
>
> But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do
> back in the day......
>
> In short, you say that the only way currently to get to 9.1 is upgrade
> from an already installed support version, not during the install process.
>
>
>
> for the record and I know its not supported, I did try the hack of
> grabbing the boot info file from 9.0 and pushing it into the 9.1 iso. The
> install process failed post installing everything.
>
> Thanks for digging Ryan.
>
>
>
> ****
>
> On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:*
> ***
>
> Confirmed I see it here in the lab and it looks to be intentional, though
> I'm still digging. ****
>
> Initial word is for a while now upgrade-during-install is only supported
> to the same major/minor version. ****
>
> ****
>
> Anything beyond that requires a separate upgrade after install.****
>
> ****
>
> -Ryan****
>
> ****
>
> On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:****
>
>
> I did just that. after I tried with the pre-release, I used my NFR iso.
> Same result.
>
> I only used the pre-release because it was already on my datastore and i
> was feeling a bit lazy over vacation. After I attempted the same procedure
> with 9.0(1) -37 iso, I received the exact same error.
>
> Ryan, should I be able to boot off of 9.0 and upgrade-during-install with
> 9.1?****
>
> On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:**
> **
>
> 9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw
> it in the trash and try with a real 9.0 build (I'm going to start this
> now). ****
>
> ****
>
> -Ryan****
>
> ****
>
> On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:****
>
>
> I didnt test to see if the 9.1 from CCO is bootable. In the past they
> havent been.
>
> attached is a screenshoot of the error I received when I tried to feed the
> 9.1 via CCO during a booted-from-nfr9.0 media****
>
> On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org>
> wrote:****
>
> I had lots of problems doing upgrade during installs with 9.0 ESs. The
> ESs are usually bootable so I just gave up and installed fresh. Is the 9.1
> download bootable?****
>
> ****
>
> ****
>
> ****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tim Frazee
> *Sent:* Monday, December 31, 2012 3:50 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] upgrade during install from 9.0 to 9.1****
>
> ****
>
> This was for UCM and Unity Connection. didnt try anything else.
>
>
> ****
>
> On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:****
>
> I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.
>
> I'm getting an error if I feed the 9.1 iso to the 9.0 install process that
> i want to upgrade during the install process. I've been able to do this
> many times in the past with never a problem like this.
>
> Anyone have any ideas?****
>
> ****
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.****
>
> ****
>
> ****
>
> <temp.png>_______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ** **
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.****
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130105/22a07ffc/attachment.html>

From jsteinberg at gmail.com Sat Jan 5 10:34:10 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Sat, 5 Jan 2013 10:34:10 -0500
Subject: [cisco-voip] Jabber 9.1 non-domain computer
In-Reply-To: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>
References: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>
Message-ID: <CACCAghb1qrT4RCWsiub4RSxeFnkgVVd3TAN0zU4c76b8BrRepg@mail.gmail.com>

Two options, depending on what directory method you are using:

1) UDS - this is the easiest, since Jabber queries CUCM enduser table for
directory searches. This must be enabled in the jabber-config.xml file.
UDS is a service on CUCM, available starting in 8.6
2) EDI - this is the default Jabber directory search, and as you mention,
queries AD directly. This is a problem for non domain PCs. You can edit
the jabber-config.xml file and hard code AD domain controller IPs and
credentials for Jabber to authenticate to query AD.

For a 8.6+ cluster that is LDAP integrated to your AD, I would just use the
UDS method. It is easier.

On Fri, Jan 4, 2013 at 6:34 PM, Scott Voll <svoll.voip at gmail.com> wrote:

> How do you setup Jabber to see the Domain contacts when it's not a Domain
> PC. (example. Home end user PC).
>
> TIA
>
> Scott
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130105/fd21175c/attachment.html>

From member at linkedin.com Sun Jan 6 21:14:21 2013


From: member at linkedin.com (Thilan Jayathilake via LinkedIn)
Date: Mon, 7 Jan 2013 02:14:21 +0000 (UTC)
Subject: [cisco-voip] Invitation to connect on LinkedIn
Message-ID: <598039155.55364253.1357524861267.JavaMail.app@ela4-app2317.prod>

LinkedIn
------------

Thilan Jayathilake requested to add you as a connection on LinkedIn:

------------------------------------------

Ray,

Find out why I use LinkedIn. Stay in touch and build your professional network.

- Thilan

Accept invitation from Thilan Jayathilake


http://www.linkedin.com/e/6mrtb0-hbmz92rq-41/H2MsQd1jS6Z70hLZmjMP5c-
Q5YrI0nyXrVBZemsV/blk/I499238028_9/e39SrCAJoS5vrCAJoyRJtCVFnSRJrScJr6RBfnhv9ClRsDgZ
p6lQs6lzoQ5AomZIpn8_elYUcz0UcP8Vejh9bRhdpiRiqCYTbPsRd3wVcPAUdz4LrCBxbOYWrSlI/eml-
comm_invm-b-in_ac-inv28/?hs=false&tok=1F4qecana6f5A1

View profile of Thilan Jayathilake


http://www.linkedin.com/e/6mrtb0-hbmz92rq-
41/rso/32167167/nPEo/name/1296620_I499238028_9/?hs=false&tok=3a-4oemWe6f5A1
------------------------------------------
You are receiving Invitation emails.

This email was intended for Ray Burkholder.


Learn why this is included: http://www.linkedin.com/e/6mrtb0-hbmz92rq-41/plh/http
%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?
hs=false&tok=3dGD9wmje6f5A1

(c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/a6586003/attachment.html>

From Zoltan.Kelemen at emerson.com Mon Jan 7 04:22:38 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Mon, 7 Jan 2013 09:22:38 +0000
Subject: [cisco-voip] Calling Party Transformation Patterns on CUCM 8.x
In-Reply-To: <CAHgd+3-bMYHATsZMmf3GsyX9LRvPwwfUcUa_FJBPhaVzbUxu3Q@mail.gmail.com>
References: <F8E0CC3253A10C4CB137F12F568DAD061A96F325B9@GBLONZ-PMSGEM02.emrsn.org>
<CAHgd+3-bMYHATsZMmf3GsyX9LRvPwwfUcUa_FJBPhaVzbUxu3Q@mail.gmail.com>
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061A96F32FEB@GBLONZ-PMSGEM02.emrsn.org>

I could set external phone number mask on the line of course and send that through
the trunk, but that changes what's displayed on the phone.
Also, it may require changes to a large number of phones, whereas this meant much
less change.

Or were you referring to something else?

Cheers,

Zoltan Kelemen
Emerson

From: Scott Voll [mailto:svoll.voip at gmail.com]


Sent: Thursday, January 03, 2013 9:05 PM
To: Kelemen, Zoltan [CORP/RO]
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Calling Party Transformation Patterns on CUCM 8.x

Can you just set it on the line and pass it through to the sip trunk?

Scott

On Thu, Jan 3, 2013 at 4:38 AM, <Zoltan.Kelemen at


emerson.com<mailto:Zoltan.Kelemen at emerson.com>> wrote:
Hi and a Happy New Year!

CUCM 8.5.1 and I'm trying to globalize calling numbers of outgoing calls on a
specific SIP trunk.

My problem is, there are more than one DID ranges, i.e.:
1XXX numbers would have +40 345 671 XXX
2XXX numbers would have +40 341 232 XXX

I want to make sure to set the proper caller ID/calling number on outgoing calls.
(I can do that since it's an internal SIP trunk, so any callerID is ok)

So I've created a partition and a CSS for transformations and added a Calling Party
Transformation Pattern (Call Routing > Transformation > Transformation Pattern >
Calling Party Transformation Pattern), applied it properly to the SIP trunk etc.

For testing I have created a single test pattern, with my own extension: 2356
This matched and applied the transformations I was expecting. I tested it with
changing the transformations, it kept working.

However, when I rewrote the pattern to 2XXX it stopped matching. Basically it seems
that I'm unable to use any non-specific pattern to match the calling party number.
(neither 2!, nor 235X nor anything else that I've tried seems to match)

Any ideas?

Thanks,
Zoltan Kelemen
Emerson
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/b167b85b/attachment.html>

From ciscovoipuser at gmail.com Mon Jan 7 05:41:41 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Mon, 7 Jan 2013 10:41:41 +0000
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
Message-ID: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>

Hi,

We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on


MCS.

I understand the upgrade process but the customer has thrown us a curve
ball by asking that in order to mitigate downtime on their solution we use
a spare MCS server and rebuild it as a Publisher before upgrading to 6.1(4)
then 8.6 ready for the DRS backup and restore onto UCS.

They have around 50 x license files which have been added incrementally
over the last few years.

My question is whether I'll need to get each license file rehosted to the
spare MCS server's MAC or whether I can simply apply for a rollup license
from TAC when it's eventually restored on the UCS?

Has anybody been through a similar upgrade experience?

Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/7d294305/attachment.html>

From gwenzit at gmail.com Mon Jan 7 06:37:16 2013


From: gwenzit at gmail.com (gwenzit)
Date: Mon, 07 Jan 2013 06:37:16 -0500
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
Message-ID: <4g3c1hov4uecgod1h936by3j.1357558636395@email.android.com>

i have done most of my upgrades this way and used all licenses on the final
version.?

Sent from my Galaxy S?III

-------- Original message --------


From: Boon <ciscovoipuser at gmail.com>
Date:
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
Hi,

We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.
?
I understand the upgrade process but the customer has thrown us a curve ball by
asking that in order to mitigate downtime on their solution we use a spare MCS
server and rebuild it as a Publisher before upgrading to 6.1(4) then 8.6 ready for
the DRS backup and restore onto UCS.
?
They have around 50 x license files which have been added incrementally over the
last few years.
?
My question is whether I'll need to get each license file rehosted?to the spare?MCS
server's MAC?or whether I can simply apply for a rollup license from TAC when it's
eventually restored on the UCS?
?
Has anybody been through a similar upgrade?experience?
?
Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/3d41cb58/attachment.html>

From abbaseo at gmail.com Mon Jan 7 08:38:30 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Mon, 7 Jan 2013 13:38:30 +0000
Subject: [cisco-voip] cisco phones for visually imparied user
Message-ID: <CAFdHCp7VOz3NL2xFkC-cLYtU+C92jzG5PeE5LHEjO0MQVVvuDA@mail.gmail.com>

Hi,

can we add/modify anything to help the visually impaired users i.e.


increase the font size on cisco 79XX ??

thanks

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/36e47cbe/attachment.html>

From Chris_kauffman at eloyalty.com Mon Jan 7 07:47:09 2013


From: Chris_kauffman at eloyalty.com (Kauffman, Christopher)
Date: Mon, 7 Jan 2013 12:47:09 +0000
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <4g3c1hov4uecgod1h936by3j.1357558636395@email.android.com>
References: <4g3c1hov4uecgod1h936by3j.1357558636395@email.android.com>
Message-ID: <929AADA2-4DA1-4789-9BBD-CE80F22B171A@eloyalty.com>

I have done these upgrades both ways. You could open a TAC case for licensing and
in cases like this they have rekeyed all the files into one file for upgrade. This
has the added benefit of streamlining your license files from the point of upgrade
since you should now only need the new license and the upgrade license file.

Chris
Sent from my mobile.

On Jan 7, 2013, at 6:40 AM, "gwenzit" <gwenzit at gmail.com<mailto:gwenzit at


gmail.com>> wrote:

i have done most of my upgrades this way and used all licenses on the final
version.

Sent from my Galaxy S?III

-------- Original message --------


From: Boon <ciscovoipuser at gmail.com<mailto:ciscovoipuser at gmail.com>>
Date:
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question

Hi,

We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.

I understand the upgrade process but the customer has thrown us a curve ball by
asking that in order to mitigate downtime on their solution we use a spare MCS
server and rebuild it as a Publisher before upgrading to 6.1(4) then 8.6 ready for
the DRS backup and restore onto UCS.

They have around 50 x license files which have been added incrementally over the
last few years.

My question is whether I'll need to get each license file rehosted to the spare MCS
server's MAC or whether I can simply apply for a rollup license from TAC when it's
eventually restored on the UCS?

Has anybody been through a similar upgrade experience?

Thanks in advance
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

From rratliff at cisco.com Mon Jan 7 11:21:47 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 7 Jan 2013 11:21:47 -0500
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <CACCAghbG-_Md1iWCNLgBS3LrqVzHKU6k0ZZ8TKu1sAbo4s+vOg@mail.gmail.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
<01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>
<2F143E71016CA34C924BF4C33AEF211056E45C37@W12112.ldschurch.org>
<CACCAghbG-_Md1iWCNLgBS3LrqVzHKU6k0ZZ8TKu1sAbo4s+vOg@mail.gmail.com>
Message-ID: <6FD3C6EF-3CE5-4D6B-AE71-287BCDD5251E@cisco.com>

Is there any way you can be entitled to the upgrade and not request media either be
mailed to you or downloaded via e-delivery?

Successful planning for DRS and an upgrade is itself a time consuming process.
Adding an extra line item to that checklist to get the correct media is going to be
much less time consuming than having to troubleshoot a failure in the middle of a
maintenance window that could be caused by any number of component interaction
issues that aren't tested by anybody.

-Ryan

On Jan 5, 2013, at 10:31 AM, Justin Steinberg <jsteinberg at gmail.com> wrote:

Agreed. Especially when you can download the non-bootable upgrade ISO to go from
9.0 to 9.1. Then if a subscriber fails, you have to get with TAC to get a
bootable 9.1 (hours), or go through the edelivery (days) all over again. This is
a time consuming process.

On Fri, Jan 4, 2013 at 5:10 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:

This just causes trouble for rebuilding/ adding new servers to an existing cluster.
Because you have to install the same version that is running on the cluster.

-Nate

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Friday, January 04, 2013 1:26 PM
To: Matthew Loraditch

Cc: cisco-voip at puck.nether.net


Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

To close the loop on this the restriction was added in 8.6 (when refresh upgrade
came in) because we don't test this upgrade between major versions and the fact
that we started having to do OS reinstalls (refresh) for some combinations made the
likelihood of failure too high.

It is not documented, and that will remedied in the Release Notes for 9.1 shortly
and in the Upgrade/Install docs at some point in the future (they can't be changed
as fast as release notes).
-Ryan

On Jan 2, 2013, at 4:34 PM, Matthew Loraditch <MLoraditch at


heliontechnologies.com> wrote:

Well that?s good, I can just put a PUT order in edelivery and get it. Let?s see if
it works.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Wednesday, January 02, 2013 4:22 PM
To: Tim Frazee
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.

To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.

-Ryan

On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com> wrote:


I could see that.

But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in the
day......

In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.

for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.

Thanks for digging Ryan.

On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

Confirmed I see it here in the lab and it looks to be intentional, though I'm still
digging.

Initial word is for a while now upgrade-during-install is only supported to the


same major/minor version.

Anything beyond that requires a separate upgrade after install.

-Ryan

On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.

I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.

Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?

On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in the
trash and try with a real 9.0 build (I'm going to start this now).

-Ryan
On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:

I didnt test to see if the 9.1 from CCO is bootable. In the past they havent been.

attached is a screenshoot of the error I received when I tried to feed the 9.1 via
CCO during a booted-from-nfr9.0 media

On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:

I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Tim Frazee
Sent: Monday, December 31, 2012 3:50 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1

This was for UCM and Unity Connection. didnt try anything else.

On Mon, Dec 31, 2012 at 1:04 PM, Tim Frazee <tfrazee at gmail.com> wrote:

I have the 9.0 NFR and the 9.1 upgrade iso pulled from CCO.

I'm getting an error if I feed the 9.1 iso to the 9.0 install process that i want
to upgrade during the install process. I've been able to do this many times in the
past with never a problem like this.

Anyone have any ideas?

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

<temp.png>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/3dd562a2/attachment.html>

From garrett at skjelstad.org Mon Jan 7 11:48:40 2013


From: garrett at skjelstad.org (Garrett Skjelstad)
Date: Mon, 7 Jan 2013 08:48:40 -0800
Subject: [cisco-voip] upgrade during install from 9.0 to 9.1
In-Reply-To: <6FD3C6EF-3CE5-4D6B-AE71-287BCDD5251E@cisco.com>
References: <CABzsfHzzCaVfCCGnvfC4zMOCGgbGZ0qd7aCVcFwV8MqSEAYQKQ@mail.gmail.com>
<CABzsfHwc83EgNK9VyYLmHUwi7Y+CS529Lc7JAWwB16=x8NYQDQ@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E3DF45@W12112.ldschurch.org>
<CABzsfHw09OgbA+cqnRu2UhHJ4QaprXt8xm8N7uJ+RFcQB_evbA@mail.gmail.com>
<A458AAAC-818A-4A61-9D41-E2C167C8D8BB@cisco.com>
<CABzsfHz51PpnrFoorNbtNRVPLJ-7UNT9JK+t=dYPZawE7KejpQ@mail.gmail.com>
<00C7D131-EDB3-4404-A37A-02C434617D89@cisco.com>
<CABzsfHz0Km6uPom_mhLkU9iMiZMawubm2JXAG1+uaJ+_wKACug@mail.gmail.com>
<5992A434-99D1-406D-894A-02F51A195AA7@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E298311081C47@PHANES.helion.local>
<01373FBF-B7E2-4803-89CB-4F47569A181E@cisco.com>
<2F143E71016CA34C924BF4C33AEF211056E45C37@W12112.ldschurch.org>
<CACCAghbG-_Md1iWCNLgBS3LrqVzHKU6k0ZZ8TKu1sAbo4s+vOg@mail.gmail.com>
<6FD3C6EF-3CE5-4D6B-AE71-287BCDD5251E@cisco.com>
Message-ID: <96456C98-ED5A-4F51-B888-DE816FB95A19@skjelstad.org>

Back are the days of voice consultants carrying around binders of DVDs for every
single version they could run across... As they are usually called when someone
didn't do DRS planning that well...
Sent from my iPhone 5

On Jan 7, 2013, at 8:21, Ryan Ratliff <rratliff at cisco.com> wrote:

> Is there any way you can be entitled to the upgrade and not request media either
be mailed to you or downloaded via e-delivery?
>
> Successful planning for DRS and an upgrade is itself a time consuming process.
Adding an extra line item to that checklist to get the correct media is going to be
much less time consuming than having to troubleshoot a failure in the middle of a
maintenance window that could be caused by any number of component interaction
issues that aren't tested by anybody.
>
>
> -Ryan
>
> On Jan 5, 2013, at 10:31 AM, Justin Steinberg <jsteinberg at gmail.com> wrote:
>
> Agreed. Especially when you can download the non-bootable upgrade ISO to go from
9.0 to 9.1. Then if a subscriber fails, you have to get with TAC to get a
bootable 9.1 (hours), or go through the edelivery (days) all over again. This is
a time consuming process.
>
> On Fri, Jan 4, 2013 at 5:10 PM, Nate VanMaren <VanMarenNP at ldschurch.org>
wrote:
>>
>>
>> This just causes trouble for rebuilding/ adding new servers to an existing
cluster. Because you have to install the same version that is running on the
cluster.
>>
>>
>>
>> -Nate
>>
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Ryan Ratliff
>> Sent: Friday, January 04, 2013 1:26 PM
>> To: Matthew Loraditch
>>
>>
>> Cc: cisco-voip at puck.nether.net
>> Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1
>>
>>
>>
>> To close the loop on this the restriction was added in 8.6 (when refresh upgrade
came in) because we don't test this upgrade between major versions and the fact
that we started having to do OS reinstalls (refresh) for some combinations made the
likelihood of failure too high.
>>
>>
>>
>> It is not documented, and that will remedied in the Release Notes for 9.1
shortly and in the Upgrade/Install docs at some point in the future (they can't be
changed as fast as release notes).
>>
>>
>>
>> -Ryan
>>
>>
>>
>> On Jan 2, 2013, at 4:34 PM, Matthew Loraditch <MLoraditch at
heliontechnologies.com> wrote:
>>
>>
>>
>> Well that?s good, I can just put a PUT order in edelivery and get it. Let?s see
if it works.
>>
>>
>>
>>
>>
>> Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA
>>
>> 1965 Greenspring Drive
>> Timonium, MD 21093
>>
>> voice. 410.252.8830
>> fax. 410.252.9284
>>
>> Twitter | Facebook | Website | Email Support
>>
>>
>>
>>
>>
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Ryan Ratliff
>> Sent: Wednesday, January 02, 2013 4:22 PM
>> To: Tim Frazee
>> Cc: cisco-voip at puck.nether.net
>> Subject: Re: [cisco-voip] upgrade during install from 9.0 to 9.1
>>
>>
>>
>> I was told this restriction was added around 8.5 but I'm still waiting on some
other folks to comment.
>>
>>
>>
>> To get to 9.1 you either do a fresh install or you upgrade, same as any other
version. I understand the release of 9.1 has immediately replaced 9.0 on new 9.x
orders (much like 8.6 did for 8.5) so any 9.x media kit ordered today will be sent
9.1 bootable media.
>>
>>
>>
>> -Ryan
>>
>>
>>
>> On Jan 2, 2013, at 4:12 PM, Tim Frazee <tfrazee at gmail.com> wrote:
>>
>>
>> I could see that.
>>
>> But tell that to my 8.5 upgrade from an 8.0 boot disk I was able to do back in
the day......
>>
>> In short, you say that the only way currently to get to 9.1 is upgrade from an
already installed support version, not during the install process.
>>
>>
>>
>> for the record and I know its not supported, I did try the hack of grabbing the
boot info file from 9.0 and pushing it into the 9.1 iso. The install process failed
post installing everything.
>>
>> Thanks for digging Ryan.
>>
>>
>>
>>
>> On Wed, Jan 2, 2013 at 12:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>> Confirmed I see it here in the lab and it looks to be intentional, though I'm
still digging.
>>
>> Initial word is for a while now upgrade-during-install is only supported to the
same major/minor version.
>>
>>
>>
>> Anything beyond that requires a separate upgrade after install.
>>
>>
>>
>> -Ryan
>>
>>
>>
>> On Jan 2, 2013, at 11:18 AM, Tim Frazee <tfrazee at gmail.com> wrote:
>>
>>
>> I did just that. after I tried with the pre-release, I used my NFR iso. Same
result.
>>
>> I only used the pre-release because it was already on my datastore and i was
feeling a bit lazy over vacation. After I attempted the same procedure with 9.0(1)
-37 iso, I received the exact same error.
>>
>> Ryan, should I be able to boot off of 9.0 and upgrade-during-install with 9.1?
>>
>> On Wed, Jan 2, 2013 at 9:47 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>> 9.0.0.99101-22 is not a 9.0 ES, it's a pre-release build of 9.1. Throw it in
the trash and try with a real 9.0 build (I'm going to start this now).
>>
>>
>>
>> -Ryan
>>
>>
>>
>> On Jan 2, 2013, at 9:50 AM, Tim Frazee <tfrazee at gmail.com> wrote:
>>
>>
>> I didnt test to see if the 9.1 from CCO is bootable. In the past they havent
been.
>>
>> attached is a screenshoot of the error I received when I tried to feed the 9.1
via CCO during a booted-from-nfr9.0 media
>>
>> On Mon, Dec 31, 2012 at 5:02 PM, Nate VanMaren <VanMarenNP at ldschurch.org>
wrote:
>>
>> I had lots of problems doing upgrade during installs with 9.0 ESs. The ESs are
usually bootable so I just gave up and installed fresh. Is the 9.1 download
bootable?
>>
>>
>>
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/f08f297a/attachment.html>

From erickbee at gmail.com Mon Jan 7 14:04:49 2013


From: erickbee at gmail.com (Erick B.)
Date: Mon, 7 Jan 2013 13:04:49 -0600
Subject: [cisco-voip] Check constraint error adding home/mobile phone to
personal address book
Message-ID: <CAHSnBQze_sDFvH+MgXbA2ynhYtsQiqJOC3gkqn6gh1zuKYCSUg@mail.gmail.com>

Anyone seen this before?

Not finding any bug for this at moment.

When a user tries to add a home/mobile to their personal address book via
web page they get the following error. They can do this fine on the phone
itself. This user has over 100 entries in their PAB, any limitation on
that?

Update failed. Check constraint


(informix.cc_personalphonebook_personalfastdialindex) failed

Version is 6.1.2.1000-13 (I know its old and needs upgrading).

Thanks,
Erick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/44038221/attachment.html>

From me at go0se.com Mon Jan 7 15:07:55 2013


From: me at go0se.com (me at go0se.com)
Date: Mon, 7 Jan 2013 13:07:55 -0700
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
Message-ID: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>

I've searched and don't seem to find any threads regarding this. I have
ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
respective ISOs for my various products. I attempted to upgrade my
callmanager publisher and I get the following message:

"Name matches a filter which indicates the name does not represent a
signed file. Upgrade requires signed files."

I do not see that I can download a signed file from Cisco. I read on the
cisco support forums someone suggested adding the "sgn" to the iso file
name but this seems unwise. I went ahead and added the sgn and reattempted
to start the upgrade. Callmanager no longer complains and it appears to be
happy with the new file. I'm afraid to proceed with the upgrade.

What have I done wrong?

Any assistance is appreciated.

Thanks,

Goose
http://atc.go0se.com

==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

From VanMarenNP at ldschurch.org Mon Jan 7 15:11:09 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Mon, 7 Jan 2013 20:11:09 +0000
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
In-Reply-To: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
References: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>

There must have been an accidental file rename in the flow.

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of me at go0se.com
Sent: Monday, January 07, 2013 1:08 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9

I've searched and don't seem to find any threads regarding this. I have
ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
respective ISOs for my various products. I attempted to upgrade my
callmanager publisher and I get the following message:

"Name matches a filter which indicates the name does not represent a
signed file. Upgrade requires signed files."
I do not see that I can download a signed file from Cisco. I read on the
cisco support forums someone suggested adding the "sgn" to the iso file
name but this seems unwise. I went ahead and added the sgn and reattempted
to start the upgrade. Callmanager no longer complains and it appears to be
happy with the new file. I'm afraid to proceed with the upgrade.

What have I done wrong?

Any assistance is appreciated.

Thanks,

Goose
http://atc.go0se.com

==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

From mikeeo at msn.com Mon Jan 7 15:24:50 2013


From: mikeeo at msn.com (Mike Olivere)
Date: Mon, 7 Jan 2013 15:24:50 -0500
Subject: [cisco-voip] VG 224 sip example conf
Message-ID: <BLU0-SMTP169D6CF7559A9447B0617E3C5250@phx.gbl>

Does anyone have a example config? I'm thinking its just like a sip router config
correct?

Thanks
Mike

Sent from my iPhone

From rratliff at cisco.com Mon Jan 7 16:02:03 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 7 Jan 2013 16:02:03 -0500
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>
References: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
<2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>
Message-ID: <21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>

What browser did you use to download the ISOs? I seem to recall an issue a while
back where one browser (IE I think) would strip file extensions like that. If you
want to be sure make sure the filename you have on your PC matches the link you
downloaded it from and run an md5sum. If that checks out then you are good to go.

The "disk check" option at the beginning of the install also will do an md5
verification using the md5 we build into the ISO itself so you can run that as
well.

-Ryan

On Jan 7, 2013, at 3:11 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:

There must have been an accidental file rename in the flow.

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of me at go0se.com
Sent: Monday, January 07, 2013 1:08 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9

I've searched and don't seem to find any threads regarding this. I have
ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
respective ISOs for my various products. I attempted to upgrade my
callmanager publisher and I get the following message:

"Name matches a filter which indicates the name does not represent a
signed file. Upgrade requires signed files."

I do not see that I can download a signed file from Cisco. I read on the
cisco support forums someone suggested adding the "sgn" to the iso file
name but this seems unwise. I went ahead and added the sgn and reattempted
to start the upgrade. Callmanager no longer complains and it appears to be
happy with the new file. I'm afraid to proceed with the upgrade.

What have I done wrong?

Any assistance is appreciated.

Thanks,

Goose
http://atc.go0se.com

==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/e7d9d43d/attachment.html>

From me at go0se.com Mon Jan 7 16:18:39 2013


From: me at go0se.com (me at go0se.com)
Date: Mon, 7 Jan 2013 14:18:39 -0700
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
In-Reply-To: <21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>
References: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
<2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>
<21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>
Message-ID: <703c47b7d6bdd7546327c2a38a0b3c7d.squirrel@go0se.com>

Oddly enough I used Firefox.

Thanks,

Goose
http://atc.go0se.com

==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

> What browser did you use to download the ISOs? I seem to recall an issue
> a while back where one browser (IE I think) would strip file extensions
> like that. If you want to be sure make sure the filename you have on
> your PC matches the link you downloaded it from and run an md5sum. If
> that checks out then you are good to go.
>
> The "disk check" option at the beginning of the install also will do an
> md5 verification using the md5 we build into the ISO itself so you can run
> that as well.
>
> -Ryan
>
> On Jan 7, 2013, at 3:11 PM, Nate VanMaren <VanMarenNP at ldschurch.org>
> wrote:
>
> There must have been an accidental file rename in the flow.
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of me at go0se.com
> Sent: Monday, January 07, 2013 1:08 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
>
> I've searched and don't seem to find any threads regarding this. I have
> ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
> respective ISOs for my various products. I attempted to upgrade my
> callmanager publisher and I get the following message:
>
> "Name matches a filter which indicates the name does not represent a
> signed file. Upgrade requires signed files."
>
> I do not see that I can download a signed file from Cisco. I read on the
> cisco support forums someone suggested adding the "sgn" to the iso file
> name but this seems unwise. I went ahead and added the sgn and reattempted
> to start the upgrade. Callmanager no longer complains and it appears to be
> happy with the new file. I'm afraid to proceed with the upgrade.
>
> What have I done wrong?
>
> Any assistance is appreciated.
>
> Thanks,
>
> Goose
> http://atc.go0se.com
>
> ==================================
> Help those less fortunate than you
> http://www.hopegivers.org
> ==================================
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisc

From MLoraditch at heliontechnologies.com Mon Jan 7 16:19:49 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Mon, 7 Jan 2013 21:19:49 +0000
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
In-Reply-To: <21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>
References: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
<2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>
<21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E29831108D66D@PHANES.helion.local>

I can't recall 100% but I believe the bootable versions of the ISOs from edelivery
don't have sgn in the file name. I have added it in the past and it worked as you
described.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Monday, January 07, 2013 4:02 PM
To: me at go0se.com
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] iso file for upgrading from 8.6 to 9

What browser did you use to download the ISOs? I seem to recall an issue a while
back where one browser (IE I think) would strip file extensions like that. If you
want to be sure make sure the filename you have on your PC matches the link you
downloaded it from and run an md5sum. If that checks out then you are good to go.

The "disk check" option at the beginning of the install also will do an md5
verification using the md5 we build into the ISO itself so you can run that as
well.

-Ryan

On Jan 7, 2013, at 3:11 PM, Nate VanMaren <VanMarenNP at


ldschurch.org<mailto:VanMarenNP at ldschurch.org>> wrote:

There must have been an accidental file rename in the flow.

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at
puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:voip-bounces
at puck.nether.net>] On Behalf Of me at go0se.com<mailto:me at go0se.com>
Sent: Monday, January 07, 2013 1:08 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9

I've searched and don't seem to find any threads regarding this. I have
ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
respective ISOs for my various products. I attempted to upgrade my
callmanager publisher and I get the following message:

"Name matches a filter which indicates the name does not represent a
signed file. Upgrade requires signed files."

I do not see that I can download a signed file from Cisco. I read on the
cisco support forums someone suggested adding the "sgn" to the iso file
name but this seems unwise. I went ahead and added the sgn and reattempted
to start the upgrade. Callmanager no longer complains and it appears to be
happy with the new file. I'm afraid to proceed with the upgrade.

What have I done wrong?

Any assistance is appreciated.

Thanks,

Goose
http://atc.go0se.com
==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/12f9dfbe/attachment.html>

From terry.cheema at gmail.com Mon Jan 7 16:34:09 2013


From: terry.cheema at gmail.com (Terry Cheema)
Date: Tue, 8 Jan 2013 08:34:09 +1100
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
Message-ID: <7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>

Liaise with Cisco licensing team (licensing at cisco.com). They will rehost and
consolidate all license files into one, So during the migration you will need to
upload just one license file.

Once you do a DRS restore it will also restore those old license files as well. I
have been deleting all the old license files and then upload new license file. It
cleans up the new system from obsolete license files.

You can list and delete all the old license files before you upload new from cli by
below command:

File list license *

And to delete:

file delete license * noconfirm

By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.

Sent from my iPhone

On 07/01/2013, at 9:41 PM, Boon <ciscovoipuser at gmail.com> wrote:


> Hi,
>
> We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.
>
> I understand the upgrade process but the customer has thrown us a curve ball by
asking that in order to mitigate downtime on their solution we use a spare MCS
server and rebuild it as a Publisher before upgrading to 6.1(4) then 8.6 ready for
the DRS backup and restore onto UCS.
>
> They have around 50 x license files which have been added incrementally over the
last few years.
>
> My question is whether I'll need to get each license file rehosted to the spare
MCS server's MAC or whether I can simply apply for a rollup license from TAC when
it's eventually restored on the UCS?
>
> Has anybody been through a similar upgrade experience?
>
> Thanks in advance
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/f6bac1c8/attachment.html>

From rratliff at cisco.com Mon Jan 7 17:00:07 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 7 Jan 2013 17:00:07 -0500
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E29831108D66D@PHANES.helion.local>
References: <26214250391bb95e30f1e312dc82fa80.squirrel@go0se.com>
<2F143E71016CA34C924BF4C33AEF211056E4DA80@W12112.ldschurch.org>
<21D4BE5A-8F13-4081-A0D4-B899E4EDEC32@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E29831108D66D@PHANES.helion.local>
Message-ID: <7EAF5181-4E1C-4589-8953-2CB4D3967A5A@cisco.com>

Correct, the bootable ISOs don't end in .sgn. The upgrade ISOs are signed files
and will end in .sgn.

I don't think you can just rename the bootable iso with a .sgn and have it work for
an upgrade. The media kit for 9.0 would have to come with a separate upgrade disk
or you'd just have to burn/mount the ISO as a disk for the upgrade to see it.

-Ryan

On Jan 7, 2013, at 4:19 PM, Matthew Loraditch <MLoraditch at


heliontechnologies.com> wrote:

I can?t recall 100% but I believe the bootable versions of the ISOs from edelivery
don?t have sgn in the file name. I have added it in the past and it worked as you
described.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA


1965 Greenspring Drive
Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Monday, January 07, 2013 4:02 PM
To: me at go0se.com
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] iso file for upgrading from 8.6 to 9

What browser did you use to download the ISOs? I seem to recall an issue a while
back where one browser (IE I think) would strip file extensions like that. If you
want to be sure make sure the filename you have on your PC matches the link you
downloaded it from and run an md5sum. If that checks out then you are good to go.

The "disk check" option at the beginning of the install also will do an md5
verification using the md5 we build into the ISO itself so you can run that as
well.

-Ryan

On Jan 7, 2013, at 3:11 PM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:

There must have been an accidental file rename in the flow.

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Ofme at go0se.com
Sent: Monday, January 07, 2013 1:08 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] iso file for upgrading from 8.6 to 9

I've searched and don't seem to find any threads regarding this. I have
ordered my upgrades from 8.6 to 9 from the PUT tool, and downloaded the
respective ISOs for my various products. I attempted to upgrade my
callmanager publisher and I get the following message:

"Name matches a filter which indicates the name does not represent a
signed file. Upgrade requires signed files."

I do not see that I can download a signed file from Cisco. I read on the
cisco support forums someone suggested adding the "sgn" to the iso file
name but this seems unwise. I went ahead and added the sgn and reattempted
to start the upgrade. Callmanager no longer complains and it appears to be
happy with the new file. I'm afraid to proceed with the upgrade.

What have I done wrong?

Any assistance is appreciated.

Thanks,
Goose
http://atc.go0se.com

==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/70f769ec/attachment.html>

From svoll.voip at gmail.com Mon Jan 7 17:08:18 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Mon, 7 Jan 2013 14:08:18 -0800
Subject: [cisco-voip] Jabber 9.1 non-domain computer
In-Reply-To: <CACCAghb1qrT4RCWsiub4RSxeFnkgVVd3TAN0zU4c76b8BrRepg@mail.gmail.com>
References: <CAHgd+3_vys=A8J5_DXzXrtsUe0QJ4fHUb_r27krPSKwDm9SstA@mail.gmail.com>
<CACCAghb1qrT4RCWsiub4RSxeFnkgVVd3TAN0zU4c76b8BrRepg@mail.gmail.com>
Message-ID: <CAHgd+38ottVhzJ1_zaTN9iRV0GOxRfjn_Di8VfePP+3b+5OBzw@mail.gmail.com>

OK... I setup the jabber-config.xml file and uploaded it to the TFTP server
and restarted the TFTP server. I'm still not able to search for AD users
in Jabber. anyother ideas?

Scott

On Sat, Jan 5, 2013 at 7:34 AM, Justin Steinberg <jsteinberg at gmail.com>wrote:

> jabber-config.xml file


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/eb37166f/attachment.html>

From rratliff at cisco.com Mon Jan 7 17:16:00 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 7 Jan 2013 17:16:00 -0500
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
Message-ID: <3511834A-0880-41A9-983B-2930C17174F1@cisco.com>

I'd highly recommend getting up to SU2 or wherever you are going to end up on 8.6
(surely you aren't going to stick with 8.6 base...?) before deleting licenses. I
believe there were some bugs specific to early 8.6 in this area.

-Ryan

On Jan 7, 2013, at 4:34 PM, Terry Cheema <terry.cheema at gmail.com> wrote:

Liaise with Cisco licensing team (licensing at cisco.com). They will rehost and
consolidate all license files into one, So during the migration you will need to
upload just one license file.

Once you do a DRS restore it will also restore those old license files as well. I
have been deleting all the old license files and then upload new license file. It
cleans up the new system from obsolete license files.

You can list and delete all the old license files before you upload new from cli by
below command:

File list license *

And to delete:

file delete license * noconfirm

By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.

Sent from my iPhone

On 07/01/2013, at 9:41 PM, Boon <ciscovoipuser at gmail.com> wrote:

> Hi,
>
> We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.
>
> I understand the upgrade process but the customer has thrown us a curve ball by
asking that in order to mitigate downtime on their solution we use a spare MCS
server and rebuild it as a Publisher before upgrading to 6.1(4) then 8.6 ready for
the DRS backup and restore onto UCS.
>
> They have around 50 x license files which have been added incrementally over the
last few years.
>
> My question is whether I'll need to get each license file rehosted to the spare
MCS server's MAC or whether I can simply apply for a rollup license from TAC when
it's eventually restored on the UCS?
>
> Has anybody been through a similar upgrade experience?
>
> Thanks in advance
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/8407f2ec/attachment.html>

From MLoraditch at heliontechnologies.com Mon Jan 7 17:20:29 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Mon, 7 Jan 2013 22:20:29 +0000
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
<3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>

I concur I hit these multiple times and TAC root was needed to clean things up. Not
pleasant, nor part of my plans.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Monday, January 07, 2013 5:16 PM
To: Boon
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question

I'd highly recommend getting up to SU2 or wherever you are going to end up on 8.6
(surely you aren't going to stick with 8.6 base...?) before deleting licenses. I
believe there were some bugs specific to early 8.6 in this area.

-Ryan

On Jan 7, 2013, at 4:34 PM, Terry Cheema <terry.cheema at


gmail.com<mailto:terry.cheema at gmail.com>> wrote:
Liaise with Cisco licensing team (licensing at cisco.com<mailto:licensing at
cisco.com>). They will rehost and consolidate all license files into one, So during
the migration you will need to upload just one license file.

Once you do a DRS restore it will also restore those old license files as well. I
have been deleting all the old license files and then upload new license file. It
cleans up the new system from obsolete license files.

You can list and delete all the old license files before you upload new from cli by
below command:

File list license *

And to delete:

file delete license * noconfirm

By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.

Sent from my iPhone

On 07/01/2013, at 9:41 PM, Boon <ciscovoipuser at gmail.com<mailto:ciscovoipuser at


gmail.com>> wrote:

Hi,

We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.

I understand the upgrade process but the customer has thrown us a curve ball by
asking that in order to mitigate downtime on their solution we use a spare MCS
server and rebuild it as a Publisher before upgrading to 6.1(4) then 8.6 ready for
the DRS backup and restore onto UCS.

They have around 50 x license files which have been added incrementally over the
last few years.

My question is whether I'll need to get each license file rehosted to the spare MCS
server's MAC or whether I can simply apply for a rollup license from TAC when it's
eventually restored on the UCS?

Has anybody been through a similar upgrade experience?

Thanks in advance
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/6a4db21d/attachment.html>
From terry.cheema at gmail.com Mon Jan 7 18:39:59 2013
From: terry.cheema at gmail.com (Terry Cheema)
Date: Tue, 8 Jan 2013 10:39:59 +1100
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
<3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>
Message-ID: <CAPjJVx4JV4mCCN8oQQtk54-E43NsfxDiwxkX74Bbti_suQs6jw@mail.gmail.com>

Thanks Ryan and Matthew. Agree, If there's any bug you can skip
deleting the old files.

Quick one, which specific version is affected by this and does it give
any error when you try to delete the files or causes any other trouble
as well.....

On Tue, Jan 8, 2013 at 9:20 AM, Matthew Loraditch


<MLoraditch at heliontechnologies.com> wrote:
> I concur I hit these multiple times and TAC root was needed to clean things
> up. Not pleasant, nor part of my plans.
>
>
>
>
>
> Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA
>
> 1965 Greenspring Drive
> Timonium, MD 21093
>
> voice. 410.252.8830
> fax. 410.252.9284
>
> Twitter | Facebook | Website | Email Support
>
>
>
>
>
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
> Sent: Monday, January 07, 2013 5:16 PM
> To: Boon
> Cc: cisco-voip voyp list
> Subject: Re: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
>
>
>
> I'd highly recommend getting up to SU2 or wherever you are going to end up
> on 8.6 (surely you aren't going to stick with 8.6 base...?) before deleting
> licenses. I believe there were some bugs specific to early 8.6 in this
> area.
>
>
>
>
>
> -Ryan
>
>
>
> On Jan 7, 2013, at 4:34 PM, Terry Cheema <terry.cheema at gmail.com> wrote:
>
>
>
> Liaise with Cisco licensing team (licensing at cisco.com). They will rehost and
> consolidate all license files into one, So during the migration you will
> need to upload just one license file.
>
>
>
> Once you do a DRS restore it will also restore those old license files as
> well. I have been deleting all the old license files and then upload new
> license file. It cleans up the new system from obsolete license files.
>
>
>
> You can list and delete all the old license files before you upload new from
> cli by below command:
>
>
>
> File list license *
>
>
>
> And to delete:
>
>
>
> file delete license * noconfirm
>
>
>
> By using wildcard * you dont have to delete files one by one, With no
> confirm option you dont have to confirm everytime.
>
>
> Sent from my iPhone
>
> On 07/01/2013, at 9:41 PM, Boon <ciscovoipuser at gmail.com> wrote:
>
>
> Hi,
>
>
>
> We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.
>
>
>
> I understand the upgrade process but the customer has thrown us a curve ball
> by asking that in order to mitigate downtime on their solution we use a
> spare MCS server and rebuild it as a Publisher before upgrading to 6.1(4)
> then 8.6 ready for the DRS backup and restore onto UCS.
>
>
>
> They have around 50 x license files which have been added incrementally over
> the last few years.
>
>
>
> My question is whether I'll need to get each license file rehosted to the
> spare MCS server's MAC or whether I can simply apply for a rollup license
> from TAC when it's eventually restored on the UCS?
>
>
>
> Has anybody been through a similar upgrade experience?
>
>
>
> Thanks in advance
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

From Vinnie at tdnetwork.com Tue Jan 8 01:28:45 2013


From: Vinnie at tdnetwork.com (Vincent)
Date: Mon, 7 Jan 2013 22:28:45 -0800
Subject: [cisco-voip] upgrade PBX to Cisco call manager
Message-ID: <B24430C6A8BC4742AF022BC8C548112A@xw8200>

HI All,

I would like to know more info about upgrading my existing BPX to Cisco Call
Manager or Unified. would someone please guide me how to achieve this goal.
I know how to configure the call manager, but upgrading is a brand new thing
for me. Also, could you please guide me the cost for what i have to pay,
like license, which is yearly for the phone and what other fee. Will Cisco
Call save me money over the PBX system?

Thank you very much for your help and very appreciated.
.........People First..........

Best Regards,

Vincent Dao

From svoll.voip at gmail.com Tue Jan 8 02:00:51 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Mon, 7 Jan 2013 23:00:51 -0800
Subject: [cisco-voip] upgrade PBX to Cisco call manager
In-Reply-To: <B24430C6A8BC4742AF022BC8C548112A@xw8200>
References: <B24430C6A8BC4742AF022BC8C548112A@xw8200>
Message-ID: <CAHgd+38QBz5G2C+k1fg9y_TFkVgzjwumD8Z45mTA3L8ce13gNQ@mail.gmail.com>

Vincent--

your leaving out a lot of info. What version CM do you currently have?
What version are you going to. The doc's should be on cisco.com. If you
have more specific questions, please post.

As for licensing, you might want to contact your Cisco Account team. this
depends on whether your setup as CUWL licensing or alacart.

As for as Cisco saving you money, there are too many questions that would
need to be asked. again talking to your account team they should be able
to help you with RIO and the in's and outs so you can figure that out.

Scott

On Mon, Jan 7, 2013 at 10:28 PM, Vincent <Vinnie at tdnetwork.com> wrote:

> HI All,
>
>
> I would like to know more info about upgrading my existing BPX to Cisco
> Call Manager or Unified. would someone please guide me how to achieve this
> goal. I know how to configure the call manager, but upgrading is a brand
> new thing for me. Also, could you please guide me the cost for what i have
> to pay, like license, which is yearly for the phone and what other fee.
> Will Cisco Call save me money over the PBX system?
>
> Thank you very much for your help and very appreciated.
>
>
> .........People First..........
>
>
> Best Regards,
>
> Vincent Dao
>
> ______________________________**_________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/cisco-
voip<https://puck.nether.net/mailman/listinfo/cisco-voip>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/175eecd7/attachment.html>

From Vinnie at tdnetwork.com Tue Jan 8 03:16:17 2013


From: Vinnie at tdnetwork.com (Vincent)
Date: Tue, 8 Jan 2013 00:16:17 -0800
Subject: [cisco-voip] upgrade PBX to Cisco call manager
References: <B24430C6A8BC4742AF022BC8C548112A@xw8200>
<CAHgd+38QBz5G2C+k1fg9y_TFkVgzjwumD8Z45mTA3L8ce13gNQ@mail.gmail.com>
Message-ID: <3433C2DF00DB45EB9ACB406A54BCDBFD@xw8200>

Thanks Scott for a reply,

i have only about 20 to 30 users and right now using a PBX system with voice
mail, Couple DID with lots of extensions. basicly, should i replace the
whole PBX system with a Call Manager, or coexist with PBX. I have to keep
the same numbers though. with CM version, i am flexible on the software
side, could be 7 or 8.

.........People First..........

Best Regards,

Vincent Dao
----- Original Message -----
From: "Scott Voll" <svoll.voip at gmail.com>
To: "Vincent" <Vinnie at tdnetwork.com>
Cc: <cisco-voip at puck.nether.net>
Sent: Monday, January 07, 2013 11:00 PM
Subject: Re: [cisco-voip] upgrade PBX to Cisco call manager

> Vincent--
>
> your leaving out a lot of info. What version CM do you currently have?
> What version are you going to. The doc's should be on cisco.com. If you
> have more specific questions, please post.
>
> As for licensing, you might want to contact your Cisco Account team. this
> depends on whether your setup as CUWL licensing or alacart.
>
> As for as Cisco saving you money, there are too many questions that would
> need to be asked. again talking to your account team they should be able
> to help you with RIO and the in's and outs so you can figure that out.
>
> Scott
>
>
> On Mon, Jan 7, 2013 at 10:28 PM, Vincent <Vinnie at tdnetwork.com> wrote:
>
>> HI All,
>>
>>
>> I would like to know more info about upgrading my existing BPX to Cisco
>> Call Manager or Unified. would someone please guide me how to achieve
>> this
>> goal. I know how to configure the call manager, but upgrading is a brand
>> new thing for me. Also, could you please guide me the cost for what i
>> have
>> to pay, like license, which is yearly for the phone and what other fee.
>> Will Cisco Call save me money over the PBX system?
>>
>> Thank you very much for your help and very appreciated.
>>
>>
>> .........People First..........
>>
>>
>> Best Regards,
>>
>> Vincent Dao
>>
>> ______________________________**_________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/cisco-
voip<https://puck.nether.net/mailman/listinfo/cisco-voip>
>>
>

From abbaseo at gmail.com Tue Jan 8 05:41:03 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 8 Jan 2013 10:41:03 +0000
Subject: [cisco-voip] RTMT alerts interpretation
Message-ID: <CAFdHCp4DLPogh1eQBJYP96=+ySwxq5araHCAw+AWnH_O1mAUBw@mail.gmail.com>

Folks,

just opened the morning emails to find weird alerts from RTMT as below -
doesn't make any sense can some one help where and how to interpret alerts
from RTMT.

At Tue Jan 08 07:24:16 GMT 2013 on node 172.30.213.75, the following


SyslogSeverityMatchFound events generated:

SeverityMatch : Alert

MatchedEvent : Jan 8 07:23:20 NCCHQ-CCM-SUB3 local7 1 ccm: 3215524:


NCCHQ-CCM-SUB3.nottinghamcity.gov.uk: Jan 08 2013 07:23:20.374 UTC :
%UC_CALLMANAGER-1-SDLLinkOOS:
%[LocalNodeId=4][LocalApplicationID=100][RemoteIPAddress=172.29.2.10]
[RemoteNodeID=1][RemoteApplicationID=100][LinkID=4:100:1:100][AppID=Cisco
CallManager][ClusterID=StandAloneCluster][NodeID=NCCHQ-CCM-SUB3]: SDL link
to remote application is out of service AppID : Cisco Syslog Agent
ClusterID :

NodeID : NCCHQ-CCM-SUB3

TimeStamp : Tue Jan 08 07:23:20 GMT 2013


SeverityMatch : Alert

MatchedEvent : Jan 8 07:23:55 NCCWG-CCM-SUB4 syslog 1 nbslogpd[6222]: 8


messages were dropped

AppID : Cisco Syslog Agent

ClusterID :

NodeID : NCCWG-CCM-SUB4

TimeStamp : Tue Jan 08 07:23:56 GMT+00:00 2013

At Tue Jan 08 07:24:45 GMT 2013 on node 172.30.213.13, the following


SyslogSeverityMatchFound events generated:

SeverityMatch : Alert

MatchedEvent : Jan 8 07:24:07 NCCHQ-CCM-TFTP local7 1 clm[14942]: 155:


NCCHQ-CCM-TFTP: Jan 08 2013 07:24:07.791 UTC :
%UC_CLUSTERMANAGER-1-CLM_MsgIntChkError:
%[NodeIP=0.0.0.0][AppID=Cisco Cluster
Manager][ClusterID=][NodeID=NCCHQ-CCM-TFTP]: ClusterMgr message integrity
check error.

AppID : Cisco Syslog Agent

ClusterID :

NodeID : NCCHQ-CCM-TFTP

TimeStamp : Tue Jan 08 07:24:07 GMT+00:00 2013

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/78beb086/attachment.html>

From salamka at gmail.com Tue Jan 8 06:15:10 2013


From: salamka at gmail.com (Abdul Salam)
Date: Tue, 8 Jan 2013 16:45:10 +0530
Subject: [cisco-voip] RTMT alerts interpretation
In-Reply-To: <CAFdHCp4DLPogh1eQBJYP96=+ySwxq5araHCAw+AWnH_O1mAUBw@mail.gmail.com>
References: <CAFdHCp4DLPogh1eQBJYP96=+ySwxq5araHCAw+AWnH_O1mAUBw@mail.gmail.com>
Message-ID: <EF643CE7-125E-4477-AF75-BD98641027DB@gmail.com>

Many are documented in cucm system error message guide

Sent from my iPhone

On 08-Jan-2013, at 4:11 PM, abbas Wali <abbaseo at gmail.com> wrote:

> Folks,
>
> just opened the morning emails to find weird alerts from RTMT as below - doesn't
make any sense can some one help where and how to interpret alerts from RTMT.
>
> At Tue Jan 08 07:24:16 GMT 2013 on node 172.30.213.75, the following
SyslogSeverityMatchFound events generated:
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:23:20 NCCHQ-CCM-SUB3 local7 1 ccm: 3215524: NCCHQ-CCM-
SUB3.nottinghamcity.gov.uk: Jan 08 2013 07:23:20.374 UTC : %UC_CALLMANAGER-1-
SDLLinkOOS: %[LocalNodeId=4][LocalApplicationID=100][RemoteIPAddress=172.29.2.10]
[RemoteNodeID=1][RemoteApplicationID=100][LinkID=4:100:1:100][AppID=Cisco
CallManager][ClusterID=StandAloneCluster][NodeID=NCCHQ-CCM-SUB3]: SDL link to
remote application is out of service AppID : Cisco Syslog Agent ClusterID :
>
> NodeID : NCCHQ-CCM-SUB3
>
> TimeStamp : Tue Jan 08 07:23:20 GMT 2013
>
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:23:55 NCCWG-CCM-SUB4 syslog 1 nbslogpd[6222]: 8 messages
were dropped
>
> AppID : Cisco Syslog Agent
>
> ClusterID :
>
> NodeID : NCCWG-CCM-SUB4
>
> TimeStamp : Tue Jan 08 07:23:56 GMT+00:00 2013
>
>
>
>
> At Tue Jan 08 07:24:45 GMT 2013 on node 172.30.213.13, the following
SyslogSeverityMatchFound events generated:
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:24:07 NCCHQ-CCM-TFTP local7 1 clm[14942]: 155: NCCHQ-
CCM-TFTP: Jan 08 2013 07:24:07.791 UTC : %UC_CLUSTERMANAGER-1-CLM_MsgIntChkError:
%[NodeIP=0.0.0.0][AppID=Cisco Cluster Manager][ClusterID=][NodeID=NCCHQ-CCM-TFTP]:
ClusterMgr message integrity check error.
>
> AppID : Cisco Syslog Agent
>
> ClusterID :
>
> NodeID : NCCHQ-CCM-TFTP
>
> TimeStamp : Tue Jan 08 07:24:07 GMT+00:00 2013
>
>
>
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/d499d3f7/attachment.html>

From salamka at gmail.com Tue Jan 8 06:37:05 2013


From: salamka at gmail.com (Abdul Salam .)
Date: Tue, 8 Jan 2013 17:07:05 +0530
Subject: [cisco-voip] RTMT alerts interpretation
In-Reply-To: <CAFdHCp4DLPogh1eQBJYP96=+ySwxq5araHCAw+AWnH_O1mAUBw@mail.gmail.com>
References: <CAFdHCp4DLPogh1eQBJYP96=+ySwxq5araHCAw+AWnH_O1mAUBw@mail.gmail.com>
Message-ID: <CAKav0XS9QG3HXhgOhcAby_6wq3wxyREJvZ6HZM-1+e7usCwxyA@mail.gmail.com>

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/err_msgs/8_x/ccmalarms801.html

*---AS*

On Tue, Jan 8, 2013 at 4:11 PM, abbas Wali <abbaseo at gmail.com> wrote:

> Folks,
>
> just opened the morning emails to find weird alerts from RTMT as below -
> doesn't make any sense can some one help where and how to interpret alerts
> from RTMT.
>
> At Tue Jan 08 07:24:16 GMT 2013 on node 172.30.213.75, the following
> SyslogSeverityMatchFound events generated:
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:23:20 NCCHQ-CCM-SUB3 local7 1 ccm: 3215524:
> NCCHQ-CCM-SUB3.nottinghamcity.gov.uk: Jan 08 2013 07:23:20.374 UTC :
%UC_CALLMANAGER-1-SDLLinkOOS:
> %[LocalNodeId=4][LocalApplicationID=100][RemoteIPAddress=172.29.2.10]
[RemoteNodeID=1][RemoteApplicationID=100][LinkID=4:100:1:100][AppID=Cisco
> CallManager][ClusterID=StandAloneCluster][NodeID=NCCHQ-CCM-SUB3]: SDL link
> to remote application is out of service AppID : Cisco Syslog Agent
> ClusterID :
>
> NodeID : NCCHQ-CCM-SUB3
>
> TimeStamp : Tue Jan 08 07:23:20 GMT 2013
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:23:55 NCCWG-CCM-SUB4 syslog 1 nbslogpd[6222]: 8
> messages were dropped
>
> AppID : Cisco Syslog Agent
>
> ClusterID :
>
> NodeID : NCCWG-CCM-SUB4
>
> TimeStamp : Tue Jan 08 07:23:56 GMT+00:00 2013
>
>
>
> At Tue Jan 08 07:24:45 GMT 2013 on node 172.30.213.13, the following
> SyslogSeverityMatchFound events generated:
>
> SeverityMatch : Alert
>
> MatchedEvent : Jan 8 07:24:07 NCCHQ-CCM-TFTP local7 1 clm[14942]: 155:
> NCCHQ-CCM-TFTP: Jan 08 2013 07:24:07.791 UTC : %UC_CLUSTERMANAGER-1-
CLM_MsgIntChkError:
> %[NodeIP=0.0.0.0][AppID=Cisco Cluster
> Manager][ClusterID=][NodeID=NCCHQ-CCM-TFTP]: ClusterMgr message integrity
> check error.
>
> AppID : Cisco Syslog Agent
>
> ClusterID :
>
> NodeID : NCCHQ-CCM-TFTP
>
> TimeStamp : Tue Jan 08 07:24:07 GMT+00:00 2013
>
>
> --
> @bbas..
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/77cdf4db/attachment.html>

From ckos1976 at hotmail.com Tue Jan 8 07:22:14 2013


From: ckos1976 at hotmail.com (costas georgiou)
Date: Tue, 8 Jan 2013 12:22:14 +0000
Subject: [cisco-voip] ARC
Message-ID: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>

HI All,

Does any one if ARC 5.1.2 is supported with CUCM 8.5.1?

Regards

Cos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/fef73a56/attachment.html>
From abbaseo at gmail.com Tue Jan 8 08:41:57 2013
From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 8 Jan 2013 13:41:57 +0000
Subject: [cisco-voip] ARC
In-Reply-To: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>
References: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>
Message-ID: <CAFdHCp4GwvW3k-=HxNBR_gBKuTn5RF0twwk6MG-8-qMXfWYt+w@mail.gmail.com>

yes. we are currently using 8.5.1 with ARC 5.1.2 [connect admin, voice
server and connect ct server]

On 8 January 2013 12:22, costas georgiou <ckos1976 at hotmail.com> wrote:

> HI All,
>
> Does any one if ARC 5.1.2 is supported with CUCM 8.5.1?
>
> Regards
>
> Cos
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/e22e2183/attachment.html>

From jamgale at cisco.com Tue Jan 8 09:26:00 2013


From: jamgale at cisco.com (Jamie Gale -X (jamgale - Arc Solutions at Cisco))
Date: Tue, 8 Jan 2013 14:26:00 +0000
Subject: [cisco-voip] ARC
In-Reply-To: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>
References: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>
Message-ID: <DBBB1EC53EEAD849B38428C0342C8E310D94B290@xmb-aln-x13.cisco.com>

Hi Costas,

You can find a compatibility chart at the following link:

http://www.arcsolutions.com/north_america/services/technicaldocumententerprise.aspx

Kind Regards

Jamie Gale
Technical Marketing Engineer, Cisco Unified Attendant Consoles
Arc Solutions, onsite at Cisco
jamgale at cisco.com
D +1 919 392 4671
M +1 919 699 4910
Find our new Cisco Unified Attendant Console End User training videos at
http://www.arcsolutions.com/north_america/solutions/products/cisco_oem_consoles.asp
x or https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs%3D

Join the Cisco Unified Attendant Console Forum at Arc Solutions!


http://forum.arcsolutions.com/forumdisplay.php?f=4

On Jan 8, 2013, at 7:22 AM, costas georgiou <ckos1976 at hotmail.com>


wrote:

HI All,

Does any one if ARC 5.1.2 is supported with CUCM 8.5.1?

Regards

Cos
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/f25a95d4/attachment.html>

From ckos1976 at hotmail.com Tue Jan 8 09:45:15 2013


From: ckos1976 at hotmail.com (costas georgiou)
Date: Tue, 8 Jan 2013 14:45:15 +0000
Subject: [cisco-voip] ARC
In-Reply-To: <DBBB1EC53EEAD849B38428C0342C8E310D94B290@xmb-aln-x13.cisco.com>
References: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>,
<DBBB1EC53EEAD849B38428C0342C8E310D94B290@xmb-aln-x13.cisco.com>
Message-ID: <BLU174-W795749A98DF5659F1284AD2240@phx.gbl>

Thanks All.

From: jamgale at cisco.com


To: ckos1976 at hotmail.com
CC: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] ARC
Date: Tue, 8 Jan 2013 14:26:00 +0000

Hi Costas,

You can find a compatibility chart at the following link:

http://www.arcsolutions.com/north_america/services/technicaldocumententerprise.aspx
Kind Regards

Jamie Gale
Technical Marketing Engineer, Cisco Unified Attendant Consoles
Arc Solutions, onsite at Cisco
jamgale at cisco.com
D +1 919 392 4671
M +1 919 699 4910

Find our new Cisco Unified Attendant Console End User training videos at
http://www.arcsolutions.com/north_america/solutions/products/cisco_oem_consoles.asp
x or https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs%3D

Join the Cisco Unified Attendant Console Forum at Arc Solutions!


http://forum.arcsolutions.com/forumdisplay.php?f=4

On Jan 8, 2013, at 7:22 AM, costas georgiou <ckos1976 at hotmail.com>


wrote:

HI All,

Does any one if ARC 5.1.2 is supported with CUCM 8.5.1?

Regards

Cos
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/4944a925/attachment.html>

From rratliff at cisco.com Tue Jan 8 10:02:33 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 8 Jan 2013 10:02:33 -0500
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <CAPjJVx4JV4mCCN8oQQtk54-E43NsfxDiwxkX74Bbti_suQs6jw@mail.gmail.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
<3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>
<CAPjJVx4JV4mCCN8oQQtk54-E43NsfxDiwxkX74Bbti_suQs6jw@mail.gmail.com>
Message-ID: <7C4A7BE1-25D6-43D6-8B8B-2653DBF983D2@cisco.com>

IIRC CSCtc59039 is the bug I was thinking of but it affected 8.5 and was fixed in
8.6.2. Basically the licenses were removed from the file system but left in the
database and root access was required to clean them up.

-Ryan
On Jan 7, 2013, at 6:39 PM, Terry Cheema <terry.cheema at gmail.com> wrote:

Thanks Ryan and Matthew. Agree, If there's any bug you can skip
deleting the old files.

Quick one, which specific version is affected by this and does it give
any error when you try to delete the files or causes any other trouble
as well.....

On Tue, Jan 8, 2013 at 9:20 AM, Matthew Loraditch


<MLoraditch at heliontechnologies.com> wrote:
> I concur I hit these multiple times and TAC root was needed to clean things
> up. Not pleasant, nor part of my plans.
>
>
>
>
>
> Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA
>
> 1965 Greenspring Drive
> Timonium, MD 21093
>
> voice. 410.252.8830
> fax. 410.252.9284
>
> Twitter | Facebook | Website | Email Support
>
>
>
>
>
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
> Sent: Monday, January 07, 2013 5:16 PM
> To: Boon
> Cc: cisco-voip voyp list
> Subject: Re: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
>
>
>
> I'd highly recommend getting up to SU2 or wherever you are going to end up
> on 8.6 (surely you aren't going to stick with 8.6 base...?) before deleting
> licenses. I believe there were some bugs specific to early 8.6 in this
> area.
>
>
>
>
>
> -Ryan
>
>
>
> On Jan 7, 2013, at 4:34 PM, Terry Cheema <terry.cheema at gmail.com> wrote:
>
>
>
> Liaise with Cisco licensing team (licensing at cisco.com). They will rehost and
> consolidate all license files into one, So during the migration you will
> need to upload just one license file.
>
>
>
> Once you do a DRS restore it will also restore those old license files as
> well. I have been deleting all the old license files and then upload new
> license file. It cleans up the new system from obsolete license files.
>
>
>
> You can list and delete all the old license files before you upload new from
> cli by below command:
>
>
>
> File list license *
>
>
>
> And to delete:
>
>
>
> file delete license * noconfirm
>
>
>
> By using wildcard * you dont have to delete files one by one, With no
> confirm option you dont have to confirm everytime.
>
>
> Sent from my iPhone
>
> On 07/01/2013, at 9:41 PM, Boon <ciscovoipuser at gmail.com> wrote:
>
>
> Hi,
>
>
>
> We are planning to upgrade a customer to CUCM 8.6 on UCS from 6.1(3) on MCS.
>
>
>
> I understand the upgrade process but the customer has thrown us a curve ball
> by asking that in order to mitigate downtime on their solution we use a
> spare MCS server and rebuild it as a Publisher before upgrading to 6.1(4)
> then 8.6 ready for the DRS backup and restore onto UCS.
>
>
>
> They have around 50 x license files which have been added incrementally over
> the last few years.
>
>
>
> My question is whether I'll need to get each license file rehosted to the
> spare MCS server's MAC or whether I can simply apply for a rollup license
> from TAC when it's eventually restored on the UCS?
>
>
>
> Has anybody been through a similar upgrade experience?
>
>
>
> Thanks in advance
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/645c4e24/attachment.html>

From voip at mrga.ch Tue Jan 8 10:18:50 2013


From: voip at mrga.ch (Reto Gassmann)
Date: Tue, 8 Jan 2013 16:18:50 +0100
Subject: [cisco-voip] Cisco UCCE Outbound dialer
Message-ID: <CAL4H0Z41b3wbZHL_fLB=Pf1gLGHN68qdK7oBx59TgxSdRCH4vw@mail.gmail.com>

Hello Group

Perhaps someone knows the difference between the two outbound SIP dialer
configurations "SIP Dialer with SIP Proxy" and "SIP Dialer with no SIP
Proxy".
We have a UCCE 8.0 and plan to Upgrade to 9.0 and move to UCS. For this we
have to change our dialer from sccp to SIP. We plan to have two ISR 3945
with dsp and pri Interfaces (E1). We also have a CUBE with a SIP Trunk to
our carrier. However Cube is not supported with outbound dialer.

Tank for feedback


Regards Reto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/72ad3f7e/attachment.html>

From ciscovoipuser at gmail.com Tue Jan 8 10:46:52 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Tue, 8 Jan 2013 15:46:52 +0000
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <7C4A7BE1-25D6-43D6-8B8B-2653DBF983D2@cisco.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
<3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>
<CAPjJVx4JV4mCCN8oQQtk54-E43NsfxDiwxkX74Bbti_suQs6jw@mail.gmail.com>
<7C4A7BE1-25D6-43D6-8B8B-2653DBF983D2@cisco.com>
Message-ID: <CACue4Ghp=HQKXJeS=V2cc2ZM8FU1LPf6Rh-p8iyZuTwG1vWhKw@mail.gmail.com>

Thanks for the info all.

One further question. The customer has multiple branch locations each with
a voice gateway containing IOS Enhanced Media Resources for transcoder,
conf bridge, MTP and also SRST.

The CUCM IOS Compatibility matrix states that the minimum supported IOS is
15.1(4)M1. This is to provide SRST version 8x and SCCP ccm version 8x.

More than half of their gateways do not have enough DRAM and Flash to
support 15.1(4)M1. The requirements is 512/128.

To upgrade all of these gateways it will cost a considerable amount of


money.

Is it crucial that they're upgraded prior to the upgrade? Will the media
resources be affected if left on the current IOS with only 6.1(3) support?

I think I know the answer but would like a 2nd opinion.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/83f3573a/attachment.html>

From PedersenE at bennettjones.com Tue Jan 8 11:16:45 2013


From: PedersenE at bennettjones.com (Eric Pedersen)
Date: Tue, 8 Jan 2013 16:16:45 +0000
Subject: [cisco-voip] ARC
In-Reply-To: <DBBB1EC53EEAD849B38428C0342C8E310D94B290@xmb-aln-x13.cisco.com>
References: <BLU174-W3211E7CADF9D21932C246FD2240@phx.gbl>
<DBBB1EC53EEAD849B38428C0342C8E310D94B290@xmb-aln-x13.cisco.com>
Message-ID: <C77DDA7FB9437841BD08707193E420330F7CD85C@cv-exsvr2.Legal.bjlocal>

Hi Jamie,
Do you have a target date for CUEAC support with CUCM 9.1?

Thanks,
Eric

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Jamie Gale -X (jamgale - Arc Solutions at Cisco)
Sent: 08 January 2013 7:26 AM
To: costas georgiou
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] ARC

Hi Costas,

You can find a compatibility chart at the following link:

http://www.arcsolutions.com/north_america/services/technicaldocumententerprise.aspx

Kind Regards

Jamie Gale
Technical Marketing Engineer, Cisco Unified Attendant Consoles
Arc Solutions, onsite at Cisco
jamgale at cisco.com<mailto:jamgale at cisco.com>
D +1 919 392 4671
M +1 919 699 4910

Find our new Cisco Unified Attendant Console End User training videos at
http://www.arcsolutions.com/north_america/solutions/products/cisco_oem_consoles.asp
x or https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs%3D

Join the Cisco Unified Attendant Console Forum at Arc Solutions!


http://forum.arcsolutions.com/forumdisplay.php?f=4

On Jan 8, 2013, at 7:22 AM, costas georgiou <ckos1976 at


hotmail.com<mailto:ckos1976 at hotmail.com>>
wrote:

HI All,

Does any one if ARC 5.1.2 is supported with CUCM 8.5.1?

Regards

Cos
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

The contents of this message may contain confidential and/or privileged


subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/73ab94d3/attachment.html>
From rratliff at cisco.com Tue Jan 8 11:38:36 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 8 Jan 2013 11:38:36 -0500
Subject: [cisco-voip] CUCM6 MCS to 8.6 UCS bridged upgrade Question
In-Reply-To: <CACue4Ghp=HQKXJeS=V2cc2ZM8FU1LPf6Rh-p8iyZuTwG1vWhKw@mail.gmail.com>
References: <CACue4GgUO92Rx9wbQMxXY-0Ft4JaFEwQ6C2ZrR+JNnTXA44U+Q@mail.gmail.com>
<7D4B06B7-0093-43A7-A801-EC2DFDE2D89B@gmail.com>
<3511834A-0880-41A9-983B-2930C17174F1@cisco.com>
<C75AF2AD9308C246AFBDDB994E3E29831108DA71@PHANES.helion.local>
<CAPjJVx4JV4mCCN8oQQtk54-E43NsfxDiwxkX74Bbti_suQs6jw@mail.gmail.com>
<7C4A7BE1-25D6-43D6-8B8B-2653DBF983D2@cisco.com>
<CACue4Ghp=HQKXJeS=V2cc2ZM8FU1LPf6Rh-p8iyZuTwG1vWhKw@mail.gmail.com>
Message-ID: <98FD6109-5D01-4DE0-9D69-5E9E7ECBFCDC@cisco.com>

> Is it crucial that they're upgraded prior to the upgrade? Will the media
resources be affected if left on the current IOS with only 6.1(3) support?

Best-case: IOS configured for 6.x DSPfarm and works with no issues.
2nd Best-case: They don't register at all.
Worst-case: They register, appear to work, but leak calls randomly due to version
incompatibility and/or bugs.

Your customer is going to be in a pinch either way. Hopefully they can re-examine
the need for local DSP resources on all of these gateways with the upgraded UCM and
find that they are no longer required for their call flow OR you/they can do some
testing to confirm that they can register successfully to the newer UCM and run
just fine.

-Ryan

On Jan 8, 2013, at 10:46 AM, Boon <ciscovoipuser at gmail.com> wrote:

Thanks for the info all.

One further question. The customer has multiple branch locations each with a voice
gateway containing IOS Enhanced Media Resources for transcoder, conf bridge, MTP
and also SRST.

The CUCM IOS Compatibility matrix states that the minimum supported IOS is
15.1(4)M1. This is to provide SRST version 8x and SCCP ccm version 8x.

More than half of their gateways do not have enough DRAM and Flash to support
15.1(4)M1. The requirements is 512/128.

To upgrade all of these gateways it will cost a considerable amount of money.

Is it crucial that they're upgraded prior to the upgrade? Will the media resources
be affected if left on the current IOS with only 6.1(3) support?

I think I know the answer but would like a 2nd opinion.

Thanks
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/2f7ba269/attachment.html>

From msaskin at gmail.com Tue Jan 8 12:35:50 2013


From: msaskin at gmail.com (Matthew Saskin)
Date: Tue, 8 Jan 2013 12:35:50 -0500
Subject: [cisco-voip] Cisco UCCE Outbound dialer
In-Reply-To: <CAL4H0Z41b3wbZHL_fLB=Pf1gLGHN68qdK7oBx59TgxSdRCH4vw@mail.gmail.com>
References: <CAL4H0Z41b3wbZHL_fLB=Pf1gLGHN68qdK7oBx59TgxSdRCH4vw@mail.gmail.com>
Message-ID: <CAMSV-mtUH765fn2-ontWrrSoh_3N8LbzdViJ2PCNf4ctXnhcgg@mail.gmail.com>

In short, it comes down to levels of redundancy. With a SIP proxy in


place, you would configure your dialer processes to route calls outbound
via the CUSP, and use routing rules on the CUSP to distribute calls as
appropriate to your outbound gateways. Without CUSP need to send calls
direct from the dialer process to the gateways. The issue is that the
outbound dialer process only allows setting a single IP address to route
calls, so without a CUSP there's no way to set up any redundancy.

Without CUSP, the closest you can get is having the A side dialer point to
a gateway and the B side dialer point to another gateway, which is better
than nothing I suppose.

-matthew

On Tue, Jan 8, 2013 at 10:18 AM, Reto Gassmann <voip at mrga.ch> wrote:

> We have a UCCE 8.0 and plan to Upgrade to 9.0 and move to UCS. For this we
> have to change our dialer from sccp to SIP. We plan to have two ISR 3945
> with dsp and pri Interfaces (E1). We also have a CUBE with a SIP Trunk to
> our carrier. However Cube is not supported with outbound dialer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/3738b4db/attachment.html>

From Zoltan.Kelemen at emerson.com Wed Jan 9 05:45:20 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Wed, 9 Jan 2013 10:45:20 +0000
Subject: [cisco-voip] Calling Party Transformation Patterns on CUCM 8.x
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061A96F8C9D6@GBLONZ-PMSGEM02.emrsn.org>

Hi,

For future reference, if anybody would ever hit this issue:

While I don't completely understand why it behaved as it did, the root of the
problem was, that the CSS for the Transformation Patterns included other partitions
as well besides the partition dedicated for transformations.

Cheers,

Zoltan Kelemen
Emerson

From: Kelemen, Zoltan [CORP/RO]


Sent: Thursday, January 03, 2013 2:39 PM
To: 'cisco-voip at puck.nether.net'
Subject: Calling Party Transformation Patterns on CUCM 8.x

Hi and a Happy New Year!

CUCM 8.5.1 and I'm trying to globalize calling numbers of outgoing calls on a
specific SIP trunk.

My problem is, there are more than one DID ranges, i.e.:
1XXX numbers would have +40 345 671 XXX
2XXX numbers would have +40 341 232 XXX

I want to make sure to set the proper caller ID/calling number on outgoing calls.
(I can do that since it's an internal SIP trunk, so any callerID is ok)

So I've created a partition and a CSS for transformations and added a Calling Party
Transformation Pattern (Call Routing > Transformation > Transformation Pattern >
Calling Party Transformation Pattern), applied it properly to the SIP trunk etc.

For testing I have created a single test pattern, with my own extension: 2356
This matched and applied the transformations I was expecting. I tested it with
changing the transformations, it kept working.

However, when I rewrote the pattern to 2XXX it stopped matching. Basically it seems
that I'm unable to use any non-specific pattern to match the calling party number.
(neither 2!, nor 235X nor anything else that I've tried seems to match)

Any ideas?

Thanks,
Zoltan Kelemen
Emerson

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/036e3167/attachment.html>

From Robert.Bellerose at analog.com Wed Jan 9 08:00:39 2013


From: Robert.Bellerose at analog.com (Bellerose, Robert)
Date: Wed, 9 Jan 2013 08:00:39 -0500
Subject: [cisco-voip] cucm rel 8.6
Message-ID: <48531C74FED6D149B9BE27996038EDFA01EFD1888536@NWD2CMBX1.ad.analog.com>

Anyone ever see issues with Phones 7965 not registering using Taps on this release.
Found out you have to apply config then save for the phones to register. TAC is
looking to this..

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/6b30809b/attachment.html>

From wsisk at cisco.com Wed Jan 9 11:59:10 2013


From: wsisk at cisco.com (Wes Sisk)
Date: Wed, 9 Jan 2013 11:59:10 -0500
Subject: [cisco-voip] Check constraint error adding home/mobile phone to
personal address book
In-Reply-To: <CAHSnBQze_sDFvH+MgXbA2ynhYtsQiqJOC3gkqn6gh1zuKYCSUg@mail.gmail.com>
References: <CAHSnBQze_sDFvH+MgXbA2ynhYtsQiqJOC3gkqn6gh1zuKYCSUg@mail.gmail.com>
Message-ID: <9DD4B67A-0C44-4DCD-8163-43F3FE592C5D@cisco.com>

Cryptic but looks resolved by CSCso80710. Something about constraints on the number
of entries enforced both in PAB java code and the database.

on casual inspection it looks like use fewer entries or upgrade.

I had to update the bug so it will take 24 hours to appear in Bug Toolkit.

/wes

On Jan 7, 2013, at 2:04 PM, Erick B. wrote:

Anyone seen this before?

Not finding any bug for this at moment.

When a user tries to add a home/mobile to their personal address book via web page
they get the following error. They can do this fine on the phone itself. This user
has over 100 entries in their PAB, any limitation on that?

Update failed. Check constraint


(informix.cc_personalphonebook_personalfastdialindex) failed

Version is 6.1.2.1000-13 (I know its old and needs upgrading).

Thanks,
Erick

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/7a08c8d5/attachment.html>

From wsisk at cisco.com Wed Jan 9 13:38:21 2013


From: wsisk at cisco.com (Wes Sisk)
Date: Wed, 9 Jan 2013 13:38:21 -0500
Subject: [cisco-voip] cucm rel 8.6
In-Reply-To: <48531C74FED6D149B9BE27996038EDFA01EFD1888536@NWD2CMBX1.ad.analog.com>
References: <48531C74FED6D149B9BE27996038EDFA01EFD1888536@NWD2CMBX1.ad.analog.com>
Message-ID: <E654D60A-A143-4235-8929-9E5C7B55B7EA@cisco.com>

Nothing offhand.

Change notification being completely down/offline/lost during the bulk insert would
cause what you describe. If it was indeed change notification then a one time
restart of ccm service should bring realtime memory in line with configuration in
the database.

/wes

On Jan 9, 2013, at 8:00 AM, Bellerose, Robert wrote:


Anyone ever see issues with Phones 7965 not registering using Taps on this release.
Found out you have to apply config then save for the phones to register. TAC is
looking to this..

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/362ed0d7/attachment.html>

From erickbee at gmail.com Wed Jan 9 13:51:36 2013


From: erickbee at gmail.com (Erick B)
Date: Wed, 9 Jan 2013 12:51:36 -0600
Subject: [cisco-voip] Check constraint error adding home/mobile phone to
personal address book
In-Reply-To: <9DD4B67A-0C44-4DCD-8163-43F3FE592C5D@cisco.com>
References: <CAHSnBQze_sDFvH+MgXbA2ynhYtsQiqJOC3gkqn6gh1zuKYCSUg@mail.gmail.com>
<9DD4B67A-0C44-4DCD-8163-43F3FE592C5D@cisco.com>
Message-ID: <435B974B-63B9-4FD3-91DF-4B705359A9AD@gmail.com>

Thanks Wes.

Yes, I've asked them to reduce number of entries. The user id also has a hyphen in
it. I was able to add entries with another user fine but that user only had a dozen
entries and the problem user has 163. It updates via phone service on phone.

Sent from my iPhone

On Jan 9, 2013, at 10:59 AM, Wes Sisk <wsisk at cisco.com> wrote:

> Cryptic but looks resolved by CSCso80710. Something about constraints on the
number of entries enforced both in PAB java code and the database.
>
> on casual inspection it looks like use fewer entries or upgrade.
>
> I had to update the bug so it will take 24 hours to appear in Bug Toolkit.
>
> /wes
>
> On Jan 7, 2013, at 2:04 PM, Erick B. wrote:
>
> Anyone seen this before?
>
> Not finding any bug for this at moment.
>
> When a user tries to add a home/mobile to their personal address book via web
page they get the following error. They can do this fine on the phone itself. This
user has over 100 entries in their PAB, any limitation on that?
>
> Update failed. Check constraint
(informix.cc_personalphonebook_personalfastdialindex) failed
>
> Version is 6.1.2.1000-13 (I know its old and needs upgrading).
>
> Thanks,
> Erick
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/9b48c9c6/attachment.html>

From Dennis.Heim at wwt.com Wed Jan 9 13:54:53 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Wed, 9 Jan 2013 12:54:53 -0600
Subject: [cisco-voip] Diversion Headers
Message-ID: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>

We have Verizon sip trunks and require unique codes based on the spoke site that is
calling. For example if we dial cisco it should be sent as 777-1-800-553-2447 for
site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the diversion
in cube as Verizon requires. How are other accomplishing this? One thought was to
set the diversion header based on the subnet of the calling device.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/0cad99ff/attachment.html>

From VanMarenNP at ldschurch.org Wed Jan 9 14:25:41 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Wed, 9 Jan 2013 19:25:41 +0000
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E52C78@W12112.ldschurch.org>

I would assume it would be better to set the header based upon the number being
called, if you were wanting virtual TEHO. That could be done by matching different
dial-peers?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Heim, Dennis
Sent: Wednesday, January 09, 2013 11:55 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Diversion Headers

We have Verizon sip trunks and require unique codes based on the spoke site that is
calling. For example if we dial cisco it should be sent as 777-1-800-553-2447 for
site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the diversion
in cube as Verizon requires. How are other accomplishing this? One thought was to
set the diversion header based on the subnet of the calling device.

Thanks,

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/7bf69077/attachment.html>

From afrankel at cisco.com Wed Jan 9 14:49:29 2013


From: afrankel at cisco.com (Adam Frankel)
Date: Wed, 09 Jan 2013 14:49:29 -0500
Subject: [cisco-voip] Cisco phones vulnerable to hack / remote access?
In-Reply-To: <50E72C89.9050400@cisco.com>
References: <CAGe0w3SV+5_nSpB01kTOB_AAta69HGWEYpYyxnVqkFEpnPpRfQ@mail.gmail.com>
<CAHgd+38U2ZKTRt-w16f2d66dnuuz6HX7pXJqbHTYDXPAufGKsQ@mail.gmail.com>
<CAFC4dsp8XVUYSmiTG5FQAv=DtR7p5YYuyhROhy2S41Or8F+7-Q@mail.gmail.com>
<50E72C89.9050400@cisco.com>
Message-ID: <50EDC9C9.8070508@cisco.com>

A public security advisory posted:

http://www.cisco.com/en/US/products/csa/cisco-sa-20130109-uipphone.html

HTH,

Adam

------------------------------------------------------------------------
*From:* Adam Frankel <afrankel at cisco.com>
*Sent:* Fri, Jan 04, 2013 2:24:57 PM
*To:* Cisco VOIP <cisco-voip at puck.nether.net>
*CC:*
*Subject:* Re: [cisco-voip] Cisco phones vulnerable to hack / remote access?

> PSIRT will be including all updated information related to this on the
> defect, CSCuc83860.
>
> Adam
> ------------------------------------------------------------------------
> *From:* Ed Leatherman <ealeatherman at gmail.com>
> *Sent:* Fri, Jan 04, 2013 2:11:24 PM
> *To:* Scott Voll <svoll.voip at gmail.com>
> *CC:* Cisco VOIP <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] Cisco phones vulnerable to hack / remote
> access?
>
>> I completely missed the video at the top of the IEEE article the
>> first time i read it.. i think my brain saw it as an advertisement
>> and just ignored it.
>>
>> The researchers full presentation is here also:
>> http://www.youtube.com/watch?v=f3zUOZcewtA&feature=youtu.be
>>
>>
>> On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip at gmail.com
>> <mailto:svoll.voip at gmail.com>> wrote:
>>
>> Lelio sent this out a week or two ago.
>> http://m.spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-
vulnerable
>> Check out the video.
>>
>> We are a closed facility, so the attacker would have to either be
>> inside, or take a phone off the wall in a reception area AND have
>> SSH access.
>>
>> I talked to my SE and he said:
>> Workaround = Restrict SSH and CLI access to trusted users only.
>> Administrators may consider leveraging 802.1x device
>> authentication to prevent unauthorized devices or systems from
>> accessing the voice network.
>>
>> Ang accomplished this by first gaining access to the device via
>> SSH and utilizing TFTP to pull down a malicious binary that is
>> designed to exploit the insufficient validation issue of the
>> affected System Calls. He ran this from the user context on the
>> device which performed the exploit. The caveats of this
>> particular issue are that an attacker would need to have
>> Authenticated Access either via SSH (Which would need to be
>> enabled, it is not enabled by default), or local access via the
>> Serial port. The attacker would also need to be able to point the
>> device at an attacker-controlled TFTP server to retrieve the payload.
>>
>> YMMV
>>
>> Scott
>>
>>
>>
>>
>> On Fri, Jan 4, 2013 at 6:35 AM, Robert Kulagowski
>> <rkulagow at gmail.com <mailto:rkulagow at gmail.com>> wrote:
>>
>> Since no one who knows anything for real is probably going to say
>> anything for now, are there any mitigating factors that I can
>> start
>> thinking about once management sees the following article?
>>
>> http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-
phones-vulnerable-to-eavesdropping-hack-researchers-say?lite
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>>
>> --
>> Ed Leatherman
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/776091b7/attachment.html>

From mh at markholloway.com Wed Jan 9 14:57:07 2013


From: mh at markholloway.com (Mark Holloway)
Date: Wed, 9 Jan 2013 14:57:07 -0500
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
Message-ID: <85BEC899-432E-4E17-8401-0590EFD5745B@markholloway.com>

Do you need the number in the diversion header to be the same as the CUCM calling
party or can it be any valid number that belongs to the SIP trunk (ie. like a Pilot
Number) to authenticate the call? A SIP Profile can easily add a diversion header.

On Jan 9, 2013, at 1:54 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:

> We have Verizon sip trunks and require unique codes based on the spoke site that
is calling. For example if we dial cisco it should be sent as 777-1-800-553-2447
for site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the
diversion in cube as Verizon requires. How are other accomplishing this? One
thought was to set the diversion header based on the subnet of the calling device.
>
> Thanks,
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/a7998dd7/attachment.html>

From tman701 at gmail.com Wed Jan 9 15:02:51 2013


From: tman701 at gmail.com (Joel Perez)
Date: Wed, 9 Jan 2013 15:02:51 -0500
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E52C78@W12112.ldschurch.org>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
<2F143E71016CA34C924BF4C33AEF211056E52C78@W12112.ldschurch.org>
Message-ID: <CABdWoUHaEKSw72u4Mqo1YGMLE5xK14+6DSkSQSd=ATMYVPPqcg@mail.gmail.com>
Hi Dennis,

What I have done in the past with Verizon is to use a prefix on the CM RL
and then match that prefix on the dialpeer in the CUBE and use
diversion-header manipulation based on the prefix that matched.
However I have never had to actually add unique codes to outbound dialed
numbers into VZ SIP trunks, i only had to make sure the outbound DID was in
the range that was specified for that spoke site.

Joel P

On Wed, Jan 9, 2013 at 2:25 PM, Nate VanMaren <VanMarenNP at ldschurch.org>wrote:

> I would assume it would be better to set the header based upon the
> number being called, if you were wanting virtual TEHO. That could be done
> by matching different dial-peers?****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Heim, Dennis
> *Sent:* Wednesday, January 09, 2013 11:55 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] Diversion Headers****
>
> ** **
>
> We have Verizon sip trunks and require unique codes based on the spoke
> site that is calling. For example if we dial cisco it should be sent as
> 777-1-800-553-2447 for site 1 and 888-1-800-553-2447 for site 2. We were
> looking at setting the diversion in cube as Verizon requires. How are other
> accomplishing this? One thought was to set the diversion header based on
> the subnet of the calling device.****
>
> ** **
>
> Thanks,****
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.****
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/19b964ff/attachment.html>
From Dennis.Heim at wwt.com Wed Jan 9 15:17:35 2013
From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Wed, 9 Jan 2013 14:17:35 -0600
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <85BEC899-432E-4E17-8401-0590EFD5745B@markholloway.com>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
<85BEC899-432E-4E17-8401-0590EFD5745B@markholloway.com>
Message-ID: <0CC57FCAB07CEB4595526952471493D316F247D197@PRODCMS1.wwt.local>

I need to prefix certain digits to the diversion header.

Dennis Heim | Sr. Unified Collaboration Team Lead


World Wide Technology | 314.212.1814 | dennis.heim at wwt.com<mailto:dennis.heim at
wwt.com>
"Creating Impact, Ignition & Scalability"

From: Mark Holloway [mailto:mh at markholloway.com]


Sent: Wednesday, January 09, 2013 2:57 PM
To: Heim, Dennis
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Diversion Headers

Do you need the number in the diversion header to be the same as the CUCM calling
party or can it be any valid number that belongs to the SIP trunk (ie. like a Pilot
Number) to authenticate the call? A SIP Profile can easily add a diversion header.

On Jan 9, 2013, at 1:54 PM, "Heim, Dennis" <Dennis.Heim at


wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

We have Verizon sip trunks and require unique codes based on the spoke site that is
calling. For example if we dial cisco it should be sent as 777-1-800-553-2447 for
site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the diversion
in cube as Verizon requires. How are other accomplishing this? One thought was to
set the diversion header based on the subnet of the calling device.

Thanks,
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/8dd628a7/attachment.html>

From mh at markholloway.com Wed Jan 9 15:21:45 2013


From: mh at markholloway.com (Mark Holloway)
Date: Wed, 9 Jan 2013 15:21:45 -0500
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D197@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
<85BEC899-432E-4E17-8401-0590EFD5745B@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D197@PRODCMS1.wwt.local>
Message-ID: <954A08FB-12DF-40B9-BA57-56FF2CF9E9B6@markholloway.com>
Could you match the Calling party (CUCM) number to a dial peer? Then you could
assign a SIP Profile to that dial peer to prepend the digits.

On Jan 9, 2013, at 3:17 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:

> I need to prefix certain digits to the diversion header.


>
> Dennis Heim | Sr. Unified Collaboration Team Lead
> World Wide Technology | 314.212.1814 | dennis.heim at wwt.com
> ?Creating Impact, Ignition & Scalability?
>
> From: Mark Holloway [mailto:mh at markholloway.com]
> Sent: Wednesday, January 09, 2013 2:57 PM
> To: Heim, Dennis
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Diversion Headers
>
> Do you need the number in the diversion header to be the same as the CUCM calling
party or can it be any valid number that belongs to the SIP trunk (ie. like a Pilot
Number) to authenticate the call? A SIP Profile can easily add a diversion header.
>
>
> On Jan 9, 2013, at 1:54 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
>
>
> We have Verizon sip trunks and require unique codes based on the spoke site that
is calling. For example if we dial cisco it should be sent as 777-1-800-553-2447
for site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the
diversion in cube as Verizon requires. How are other accomplishing this? One
thought was to set the diversion header based on the subnet of the calling device.
>
> Thanks,
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/ec3e42d1/attachment.html>

From svoll.voip at gmail.com Wed Jan 9 15:47:45 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Wed, 9 Jan 2013 12:47:45 -0800
Subject: [cisco-voip] 7936 and corporate directory
Message-ID: <CAHgd+39TCB7o3vTe_9Sf_HC4DCzy1fm=4m9oBjH1hp+exoLMnA@mail.gmail.com>

All of my 7936 conference phones, when you press the corporate directory,
come up with error condition.

they are running: cmterm_7936.3-3-21-0 and my CM is version 8.6.2.22900-9.

I'm not finding a bug when I search. Maybe my searching is bad.

Anyone know how to fix it? all my 796x and 7970 work fine with the
corporate directory.
TIA

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/40caa1a0/attachment.html>

From chrward at cisco.com Wed Jan 9 15:56:07 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Wed, 9 Jan 2013 20:56:07 +0000
Subject: [cisco-voip] Diversion Headers
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D197@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F23447D6@PRODCMS1.wwt.local>
<85BEC899-432E-4E17-8401-0590EFD5745B@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D197@PRODCMS1.wwt.local>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1ED796@xmb-rcd-x13.cisco.com>

In CUCM, this would probably be a good use of a SIP Normalization script. I suspect
CUBE could do it do, but I know less about that.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Heim, Dennis
Sent: Wednesday, January 09, 2013 3:18 PM
To: Mark Holloway
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Diversion Headers

I need to prefix certain digits to the diversion header.

Dennis Heim | Sr. Unified Collaboration Team Lead


World Wide Technology | 314.212.1814 | dennis.heim at wwt.com<mailto:dennis.heim at
wwt.com>
"Creating Impact, Ignition & Scalability"

From: Mark Holloway [mailto:mh at markholloway.com]


Sent: Wednesday, January 09, 2013 2:57 PM
To: Heim, Dennis
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Diversion Headers

Do you need the number in the diversion header to be the same as the CUCM calling
party or can it be any valid number that belongs to the SIP trunk (ie. like a Pilot
Number) to authenticate the call? A SIP Profile can easily add a diversion header.

On Jan 9, 2013, at 1:54 PM, "Heim, Dennis" <Dennis.Heim at


wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

We have Verizon sip trunks and require unique codes based on the spoke site that is
calling. For example if we dial cisco it should be sent as 777-1-800-553-2447 for
site 1 and 888-1-800-553-2447 for site 2. We were looking at setting the diversion
in cube as Verizon requires. How are other accomplishing this? One thought was to
set the diversion header based on the subnet of the calling device.

Thanks,
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/c184ec2a/attachment.html>

From erickbee at gmail.com Wed Jan 9 18:04:56 2013


From: erickbee at gmail.com (Erick B.)
Date: Wed, 9 Jan 2013 17:04:56 -0600
Subject: [cisco-voip] 7936 and corporate directory
In-Reply-To: <CAHgd+39TCB7o3vTe_9Sf_HC4DCzy1fm=4m9oBjH1hp+exoLMnA@mail.gmail.com>
References: <CAHgd+39TCB7o3vTe_9Sf_HC4DCzy1fm=4m9oBjH1hp+exoLMnA@mail.gmail.com>
Message-ID: <CAHSnBQwDBwWqnidsHP1AmdNbwLRaQwH8qFwYfsGdtwNxF49oow@mail.gmail.com>

What is the error message?

I had similar issue with 7935 (host not found error) and 8.5 but 7935 EOL
and had worked with TAC and these 2 bug id's were provided to us.

CSCtb89353 & CSCtb96601

TAC had told us to get a 7936 and use at least 3-3-21 version firmware.
This was in Jan 2012. I don't believe the client got 7936s yet...

On Wed, Jan 9, 2013 at 2:47 PM, Scott Voll <svoll.voip at gmail.com> wrote:

> All of my 7936 conference phones, when you press the corporate directory,
> come up with error condition.
>
> they are running: cmterm_7936.3-3-21-0 and my CM is version 8.6.2.22900-9.
>
> I'm not finding a bug when I search. Maybe my searching is bad.
>
> Anyone know how to fix it? all my 796x and 7970 work fine with the
> corporate directory.
>
> TIA
>
> Scott
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130109/e0d74744/attachment.html>

From rratliff at cisco.com Thu Jan 10 10:32:35 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Thu, 10 Jan 2013 10:32:35 -0500
Subject: [cisco-voip] 7936 and corporate directory
In-Reply-To: <CAHSnBQwDBwWqnidsHP1AmdNbwLRaQwH8qFwYfsGdtwNxF49oow@mail.gmail.com>
References: <CAHgd+39TCB7o3vTe_9Sf_HC4DCzy1fm=4m9oBjH1hp+exoLMnA@mail.gmail.com>
<CAHSnBQwDBwWqnidsHP1AmdNbwLRaQwH8qFwYfsGdtwNxF49oow@mail.gmail.com>
Message-ID: <AA749FE6-CA31-4E2F-96B7-CF4E82FD9023@cisco.com>

What's a packet capture show the phone trying to do, and what is it configured to
use for the directory URL? Unfortunately that error can cover anything from a
simple DNS resolution problem to misconfigured URLs, to HTTPS cert exchange issues.
You really need to see what the phone is trying to do (or see that it isn't
actually sending anything) to get a better clue.

-Ryan

On Jan 9, 2013, at 6:04 PM, Erick B. <erickbee at gmail.com> wrote:

What is the error message?

I had similar issue with 7935 (host not found error) and 8.5 but 7935 EOL and had
worked with TAC and these 2 bug id's were provided to us.

CSCtb89353 & CSCtb96601

TAC had told us to get a 7936 and use at least 3-3-21 version firmware. This was in
Jan 2012. I don't believe the client got 7936s yet...

On Wed, Jan 9, 2013 at 2:47 PM, Scott Voll <svoll.voip at gmail.com> wrote:
All of my 7936 conference phones, when you press the corporate directory, come up
with error condition.

they are running: cmterm_7936.3-3-21-0 and my CM is version 8.6.2.22900-9.

I'm not finding a bug when I search. Maybe my searching is bad.

Anyone know how to fix it? all my 796x and 7970 work fine with the corporate
directory.

TIA

Scott

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/33114e4c/attachment.html>

From Dennis.Heim at wwt.com Thu Jan 10 13:26:23 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Thu, 10 Jan 2013 12:26:23 -0600
Subject: [cisco-voip] SIP CUBE Caller ID
Message-ID: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>

I am doing a sip integration to a pbx. We are not getting the caller id name/number
when a call is placed form cisco to the pbx via the cube. We do see the caller id
name in the debugs, but not on the phone display.

Received:
SIP/2.0 200 OK
Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51<mailto:CD2B18C9-
5A8011E2-80D5F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
Content-Type: application/sdp
Content-Length: 367
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Date: Thu, 10 Jan 2013 17:20:27 GMT
P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>

What am I missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/87f6ca6f/attachment.html>

From kennethwhayes at gmail.com Thu Jan 10 13:32:10 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Thu, 10 Jan 2013 13:32:10 -0500
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
Message-ID: <3410625381745969557@unknownmsgid>

Do you have privacy ID enabled on your voice service voip also on your SIP
trunk to CUBE to UCM under inbound and outbound make sure you have the
header boxes checked.

Sent from my iPad

On Jan 10, 2013, at 1:28 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:

I am doing a sip integration to a pbx. We are not getting the caller id


name/number when a call is placed form cisco to the pbx via the cube. We do
see the caller id name in the debugs, but not on the phone display.

Received:
SIP/2.0 200 OK

Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51

CSeq: 101 INVITE

From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B

To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp

Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7

Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>

Content-Type: application/sdp

Content-Length: 367

X-Siemens-Call-Type: ST-insecure

Accept-Language: en;q=0.0

Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO

Date: Thu, 10 Jan 2013 17:20:27 GMT

P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>

What am I missing?

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/86279608/attachment.html>

From mh at markholloway.com Thu Jan 10 13:50:31 2013


From: mh at markholloway.com (Mark Holloway)
Date: Thu, 10 Jan 2013 13:50:31 -0500
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
Message-ID: <3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>

The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?

On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
> I am doing a sip integration to a pbx. We are not getting the caller id
name/number when a call is placed form cisco to the pbx via the cube. We do see the
caller id name in the debugs, but not on the phone display.
>
> Received:
> SIP/2.0 200 OK
> Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
> To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
> Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
> Content-Type: application/sdp
> Content-Length: 367
> X-Siemens-Call-Type: ST-insecure
> Accept-Language: en;q=0.0
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
> Date: Thu, 10 Jan 2013 17:20:27 GMT
> P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>
>
> What am I missing?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/fcffa909/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 123121 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/fcffa909/attachment.png>

From Dennis.Heim at wwt.com Thu Jan 10 14:55:08 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Thu, 10 Jan 2013 13:55:08 -0600
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
Message-ID: <0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>

It is showing in the PAI, but not the from field.

Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51


CSeq: 101 INVITE
Timestamp: 1357847526
Content-Length: 0

Jan 10 19:52:06.991: //184752/427582000000/SIP/Info/sipSPICheckResponseExt: INVITE


response with no RSEQ - disable IS_REL1XX
Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState: 0x2472CB8 :
State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg
enqueued for SPI with IP addr: [10.98.88.38]:5060, local_address:[10.98.254.51]
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 2 for event 1
Jan 10 19:52:07.119: //-
1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
Checking Invite Dialog
Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51
CSeq: 101 INVITE
From: sip:XXXX7800 at 10.210.61.43;tag=802E4C74-179B
To: <sip:18077005 at 10.98.88.38>;tag=SEC11-a58620a-1e58d20a-1-zvE1E7A74E0q
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C
Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>
Date: Thu, 10 Jan 2013 19:52:29 GMT
P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38>
Content-Length: 0

From: Mark Holloway [mailto:mh at markholloway.com]


Sent: Thursday, January 10, 2013 1:51 PM
To: Heim, Dennis
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP CUBE Caller ID

The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?

[cid:image001.png at 01CDEF42.7BBEBC30]

On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at


wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

I am doing a sip integration to a pbx. We are not getting the caller id name/number
when a call is placed form cisco to the pbx via the cube. We do see the caller id
name in the debugs, but not on the phone display.

Received:
SIP/2.0 200 OK
Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51<mailto:CD2B18C9-
5A8011E2-80D5F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
Content-Type: application/sdp
Content-Length: 367
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Date: Thu, 10 Jan 2013 17:20:27 GMT
P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>

What am I missing?
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/78702056/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 123121 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/78702056/attachment.png>

From Dennis.Heim at wwt.com Thu Jan 10 15:56:41 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Thu, 10 Jan 2013 14:56:41 -0600
Subject: [cisco-voip] SIP CUBE Caller ID
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>
<CAKBLUbC=90Qjg90c6PHeE8+6YmnaK1mZz79sS2sUP5+AoPS06w@mail.gmail.com>
Message-ID: <0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>

This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, without the name. I did not have a display name on my
phone, when I fixed that, the caller id name is visible to the siemens pbx.

The problem still is that I dial a number and it does not put in the name

The Cisco-Siemens direction, we see Cisco set the From with the name (From: "Cisco
Phone" sip:5987800 at ip. We also see the P-Asserted-Identity set to "Cisco Phone"
sip:5987800 at ip.

On the invite coming back from the siemens we see it set the From, only contain the
number. However, the P-Asserted-Identity, contains the caller id name.

From: Heim, Dennis


Sent: Thursday, January 10, 2013 3:46 PM
To: 'Kenneth Hayes'; Voice_VT
Subject: RE: [cisco-voip] SIP CUBE Caller ID

This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, with the name. I did not have a display name on my phone,
when I fixed that, the caller id name is visible to the siemens pbx.

The problem still is that I dial a number and it does not put in the name.

From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]<mailto:


[mailto:kennethwhayes at gmail.com]>
Sent: Thursday, January 10, 2013 3:29 PM
To: Heim, Dennis
Subject: Re: [cisco-voip] SIP CUBE Caller ID

This is inbound correct?


On Thu, Jan 10, 2013 at 2:55 PM, Heim, Dennis <Dennis.Heim at
wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:
It is showing in the PAI, but not the from field.

Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51<mailto:C2451EA-


5A9611E2-92D3F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
Timestamp: 1357847526
Content-Length: 0

Jan 10 19:52:06.991: //184752/427582000000/SIP/Info/sipSPICheckResponseExt: INVITE


response with no RSEQ - disable IS_REL1XX
Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState: 0x2472CB8 :
State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg
enqueued for SPI with IP addr: [10.98.88.38]:5060, local_address:[10.98.254.51]
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 2 for event 1
Jan 10 19:52:07.119: //-
1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
Checking Invite Dialog
Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51<mailto:C2451EA-
5A9611E2-92D3F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: sip:XXXX7800 at 10.210.61.43<mailto:sip%3AXXXX7800 at
10.210.61.43>;tag=802E4C74-179B
To: <sip:18077005 at 10.98.88.38<mailto:sip%3A18077005 at 10.98.88.38>>;tag=SEC11-
a58620a-1e58d20a-1-zvE1E7A74E0q
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C
Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>
Date: Thu, 10 Jan 2013 19:52:29 GMT
P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38<mailto:sip%3A8077005 at
10.98.88.38>>
Content-Length: 0

From: Mark Holloway [mailto:mh at markholloway.com<mailto:mh at markholloway.com>]


Sent: Thursday, January 10, 2013 1:51 PM
To: Heim, Dennis
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP CUBE Caller ID

The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?

[cid:image001.png at 01CDEF4A.AC6DD570]
On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at
wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

I am doing a sip integration to a pbx. We are not getting the caller id name/number
when a call is placed form cisco to the pbx via the cube. We do see the caller id
name in the debugs, but not on the phone display.

Received:
SIP/2.0 200 OK
Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51<mailto:CD2B18C9-
5A8011E2-80D5F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
Content-Type: application/sdp
Content-Length: 367
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Date: Thu, 10 Jan 2013 17:20:27 GMT
P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>

What am I missing?
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/3c21a24c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 123121 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/3c21a24c/attachment.png>

From ck-lists at cksoft.de Thu Jan 10 15:38:30 2013


From: ck-lists at cksoft.de (Christian Kratzer)
Date: Thu, 10 Jan 2013 21:38:30 +0100 (CET)
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
Message-ID: <alpine.BSF.2.00.1301102133580.29184@pohjola.cksoft.de>

Hi,
On Thu, 10 Jan 2013, Heim, Dennis wrote:

> I am doing a sip integration to a pbx. We are not getting the caller id
name/number when a call is placed form cisco to the pbx via the cube. We do see the
caller id name in the debugs, but not on the phone display.

try

clid strip name

in the incoming sip dial-peer.

If sip gives the cube a usable although empty name for the incoming call
then your phones won't bother to lookup the number.

If you strip the name the phones will look it up again.

Greetings
Christian

>
> Received:
> SIP/2.0 200 OK
> Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51<mailto:CD2B18C9-
5A8011E2-80D5F143-739C4300 at 10.98.254.51>
> CSeq: 101 INVITE
> From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
> To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
> Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
> Content-Type: application/sdp
> Content-Length: 367
> X-Siemens-Call-Type: ST-insecure
> Accept-Language: en;q=0.0
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
> Date: Thu, 10 Jan 2013 17:20:27 GMT
> P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>
>
> What am I missing?
>

--
Christian Kratzer CK Software GmbH
Email: ck at cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

From mh at markholloway.com Thu Jan 10 16:23:12 2013


From: mh at markholloway.com (Mark Holloway)
Date: Thu, 10 Jan 2013 16:23:12 -0500
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>
<CAKBLUbC=90Qjg90c6PHeE8+6YmnaK1mZz79sS2sUP5+AoPS06w@mail.gmail.com>
<0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>
Message-ID: <F3544AB7-071B-4494-B057-69A7796171CB@markholloway.com>

What I was looking for, but didn't see in your TXT file, is the SIP INVITE from
CUCM includes the calling party name in the FROM field to CUBE, and CUBE includes
the same FROM name to Siemens. Assuming that is true, Siemens appears to be
disregarding the name portion of the FROM field by not only failing to display it,
but completely removing it in 1XX responses. It would be nice if it processed PAI
but I think the name is being stripped and then Siemens just assumes there is no
name for the call, as if PAI didn't exist.

On Jan 10, 2013, at 3:56 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:

> This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, without the name. I did not have a display name on my
phone, when I fixed that, the caller id name is visible to the siemens pbx.
>
> The problem still is that I dial a number and it does not put in the name
>
> The Cisco-Siemens direction, we see Cisco set the From with the name (From: ?
Cisco Phone? sip:5987800 at ip. We also see the P-Asserted-Identity set to ?Cisco
Phone? sip:5987800 at ip.
>
> On the invite coming back from the siemens we see it set the From, only contain
the number. However, the P-Asserted-Identity, contains the caller id name.
>
> From: Heim, Dennis
> Sent: Thursday, January 10, 2013 3:46 PM
> To: 'Kenneth Hayes'; Voice_VT
> Subject: RE: [cisco-voip] SIP CUBE Caller ID
>
> This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, with the name. I did not have a display name on my phone,
when I fixed that, the caller id name is visible to the siemens pbx.
>
> The problem still is that I dial a number and it does not put in the name.
>
> From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]
> Sent: Thursday, January 10, 2013 3:29 PM
> To: Heim, Dennis
> Subject: Re: [cisco-voip] SIP CUBE Caller ID
>
> This is inbound correct?
>
> On Thu, Jan 10, 2013 at 2:55 PM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:
> It is showing in the PAI, but not the from field.
>
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> Timestamp: 1357847526
> Content-Length: 0
>
>
> Jan 10 19:52:06.991: //184752/427582000000/SIP/Info/sipSPICheckResponseExt:
INVITE response with no RSEQ - disable IS_REL1XX
> Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState: 0x2472CB8
: State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg
enqueued for SPI with IP addr: [10.98.88.38]:5060, local_address:[10.98.254.51]
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 2 for event 1
> Jan 10 19:52:07.119: //-
1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
Checking Invite Dialog
> Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 180 Ringing
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> From: sip:XXXX7800 at 10.210.61.43;tag=802E4C74-179B
> To: <sip:18077005 at 10.98.88.38>;tag=SEC11-a58620a-1e58d20a-1-zvE1E7A74E0q
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C
> Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>
> Date: Thu, 10 Jan 2013 19:52:29 GMT
> P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38>
> Content-Length: 0
>
> From: Mark Holloway [mailto:mh at markholloway.com]
> Sent: Thursday, January 10, 2013 1:51 PM
> To: Heim, Dennis
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] SIP CUBE Caller ID
>
> The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?
>
> <image001.png>
>
>
>
> On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
>
>
> I am doing a sip integration to a pbx. We are not getting the caller id
name/number when a call is placed form cisco to the pbx via the cube. We do see the
caller id name in the debugs, but not on the phone display.
>
> Received:
> SIP/2.0 200 OK
> Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
> To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
> Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
> Content-Type: application/sdp
> Content-Length: 367
> X-Siemens-Call-Type: ST-insecure
> Accept-Language: en;q=0.0
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
> Date: Thu, 10 Jan 2013 17:20:27 GMT
> P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>
>
> What am I missing?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/d980a68e/attachment.html>

From Dennis.Heim at wwt.com Thu Jan 10 16:58:23 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Thu, 10 Jan 2013 15:58:23 -0600
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <F3544AB7-071B-4494-B057-69A7796171CB@markholloway.com>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>
<CAKBLUbC=90Qjg90c6PHeE8+6YmnaK1mZz79sS2sUP5+AoPS06w@mail.gmail.com>
<0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>
<F3544AB7-071B-4494-B057-69A7796171CB@markholloway.com>
Message-ID: <0CC57FCAB07CEB4595526952471493D316F247D3B8@PRODCMS1.wwt.local>

Is it possible with cube to take the PAI and copy it into the from field?

Call setup

INVITE sip:18077014 at CUBE:5060 SIP/2.0


Via: SIP/2.0/TCP CUCM:5060;branch=z9hG4bK1eda32bbab882
From: "Cisco Phone" <sip:5987800 at CUCM>;tag=2004325~37777082-f7ba-4cb2-8467-
e286cea21f2e-88710674
To: <sip:18077014 at CUBE>
Date: Thu, 10 Jan 2013 21:47:24 GMT
Call-ID: 50330380-ef136ec-1a038-2b3dd20a at CUCM
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Cisco-Guid: 1345520512-0000065536-0000033495-0725471754
Session-Expires: 1800
P-Asserted-Identity: "Cisco Phone" <sip:5987800 at CUCM>
Remote-Party-ID: "Cisco Phone" <sip:5987800 at
CUCM>;party=calling;screen=yes;privacy=off
Contact: <sip:5987800 at CUCM:5060;transport=tcp>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 214

When ringing

Received:
SIP/2.0 180 Ringing
Call-ID: 1A53E43D-5AA611E2-A21DF143-739C4300 at CUBE
CSeq: 101 INVITE
From: sip:5987800 at CUCM;tag=809784F8-1B9F
To: <sip:18077014 at SiemensOSV>;tag=SEC11-a58620a-1e58d20a-1-4197U1P1AG4o
Via: SIP/2.0/UDP CUBE:5060;branch=z9hG4bK7B1AD5
Contact: <sip:18077014 at SiemensOSV:5060;maddr=SiemensOSV>
Content-Type: application/sdp
Content-Length: 320
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Allow-Events: CCNR
Date: Thu, 10 Jan 2013 21:47:24 GMT
P-Asserted-Identity: "Siemens User" <sip:18077014 at SiemensOSV>
From: Mark Holloway [mailto:mh at markholloway.com]
Sent: Thursday, January 10, 2013 4:23 PM
To: Heim, Dennis
Cc: Kenneth Hayes; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP CUBE Caller ID

What I was looking for, but didn't see in your TXT file, is the SIP INVITE from
CUCM includes the calling party name in the FROM field to CUBE, and CUBE includes
the same FROM name to Siemens. Assuming that is true, Siemens appears to be
disregarding the name portion of the FROM field by not only failing to display it,
but completely removing it in 1XX responses. It would be nice if it processed PAI
but I think the name is being stripped and then Siemens just assumes there is no
name for the call, as if PAI didn't exist.

On Jan 10, 2013, at 3:56 PM, "Heim, Dennis" <Dennis.Heim at


wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, without the name. I did not have a display name on my
phone, when I fixed that, the caller id name is visible to the siemens pbx.

The problem still is that I dial a number and it does not put in the name

The Cisco-Siemens direction, we see Cisco set the From with the name (From: "Cisco
Phone" sip:5987800 at ip. We also see the P-Asserted-Identity set to "Cisco Phone"
sip:5987800 at ip.

On the invite coming back from the siemens we see it set the From, only contain the
number. However, the P-Asserted-Identity, contains the caller id name.

From: Heim, Dennis


Sent: Thursday, January 10, 2013 3:46 PM
To: 'Kenneth Hayes'; Voice_VT
Subject: RE: [cisco-voip] SIP CUBE Caller ID
This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, with the name. I did not have a display name on my phone,
when I fixed that, the caller id name is visible to the siemens pbx.

The problem still is that I dial a number and it does not put in the name.

From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]<mailto:


[mailto:kennethwhayes at gmail.com]>
Sent: Thursday, January 10, 2013 3:29 PM
To: Heim, Dennis
Subject: Re: [cisco-voip] SIP CUBE Caller ID

This is inbound correct?


On Thu, Jan 10, 2013 at 2:55 PM, Heim, Dennis <Dennis.Heim at
wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:
It is showing in the PAI, but not the from field.

Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51<mailto:C2451EA-


5A9611E2-92D3F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
Timestamp: 1357847526
Content-Length: 0

Jan 10 19:52:06.991: //184752/427582000000/SIP/Info/sipSPICheckResponseExt: INVITE


response with no RSEQ - disable IS_REL1XX
Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState: 0x2472CB8 :
State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg
enqueued for SPI with IP addr: [10.98.88.38]:5060, local_address:[10.98.254.51]
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 2 for event 1
Jan 10 19:52:07.119: //-
1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
Checking Invite Dialog
Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51<mailto:C2451EA-
5A9611E2-92D3F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: sip:XXXX7800 at 10.210.61.43<mailto:sip%3AXXXX7800 at
10.210.61.43>;tag=802E4C74-179B
To: <sip:18077005 at 10.98.88.38<mailto:sip%3A18077005 at 10.98.88.38>>;tag=SEC11-
a58620a-1e58d20a-1-zvE1E7A74E0q
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C
Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>
Date: Thu, 10 Jan 2013 19:52:29 GMT
P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38<mailto:sip%3A8077005 at
10.98.88.38>>
Content-Length: 0

From: Mark Holloway [mailto:mh at markholloway.com<mailto:mh at markholloway.com>]


Sent: Thursday, January 10, 2013 1:51 PM
To: Heim, Dennis
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP CUBE Caller ID

The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?

<image001.png>

On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at


wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:

I am doing a sip integration to a pbx. We are not getting the caller id name/number
when a call is placed form cisco to the pbx via the cube. We do see the caller id
name in the debugs, but not on the phone display.

Received:
SIP/2.0 200 OK
Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51<mailto:CD2B18C9-
5A8011E2-80D5F143-739C4300 at 10.98.254.51>
CSeq: 101 INVITE
From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
Content-Type: application/sdp
Content-Length: 367
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Date: Thu, 10 Jan 2013 17:20:27 GMT
P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>

What am I missing?
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/37b92d3e/attachment.html>

From mh at markholloway.com Thu Jan 10 17:15:24 2013


From: mh at markholloway.com (Mark Holloway)
Date: Thu, 10 Jan 2013 17:15:24 -0500
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D3B8@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>
<CAKBLUbC=90Qjg90c6PHeE8+6YmnaK1mZz79sS2sUP5+AoPS06w@mail.gmail.com>
<0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>
<F3544AB7-071B-4494-B057-69A7796171CB@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D3B8@PRODCMS1.wwt.local>
Message-ID: <F9FC424D-CEC8-4036-8823-D04AC325F629@markholloway.com>

Maybe with SIP Profiles, but I think the real issue is Siemens isn't honoring the
From name, RPID, or PAI. Even if you add it back in after a 1XX response it may
not solve your problem.

On Jan 10, 2013, at 4:58 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:

> Is it possible with cube to take the PAI and copy it into the from field?
>
> Call setup
>
> INVITE sip:18077014 at CUBE:5060 SIP/2.0
> Via: SIP/2.0/TCP CUCM:5060;branch=z9hG4bK1eda32bbab882
> From: "Cisco Phone" <sip:5987800 at CUCM>;tag=2004325~37777082-f7ba-4cb2-8467-
e286cea21f2e-88710674
> To: <sip:18077014 at CUBE>
> Date: Thu, 10 Jan 2013 21:47:24 GMT
> Call-ID: 50330380-ef136ec-1a038-2b3dd20a at CUCM
> Supported: timer,resource-priority,replaces
> Min-SE: 1800
> User-Agent: Cisco-CUCM8.6
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY
> CSeq: 101 INVITE
> Expires: 180
> Allow-Events: presence, kpml
> Supported: X-cisco-srtp-fallback
> Supported: Geolocation
> Cisco-Guid: 1345520512-0000065536-0000033495-0725471754
> Session-Expires: 1800
> P-Asserted-Identity: "Cisco Phone" <sip:5987800 at CUCM>
> Remote-Party-ID: "Cisco Phone" <sip:5987800 at
CUCM>;party=calling;screen=yes;privacy=off
> Contact: <sip:5987800 at CUCM:5060;transport=tcp>
> Max-Forwards: 69
> Content-Type: application/sdp
> Content-Length: 214
>
> When ringing
>
> Received:
> SIP/2.0 180 Ringing
> Call-ID: 1A53E43D-5AA611E2-A21DF143-739C4300 at CUBE
> CSeq: 101 INVITE
> From: sip:5987800 at CUCM;tag=809784F8-1B9F
> To: <sip:18077014 at SiemensOSV>;tag=SEC11-a58620a-1e58d20a-1-4197U1P1AG4o
> Via: SIP/2.0/UDP CUBE:5060;branch=z9hG4bK7B1AD5
> Contact: <sip:18077014 at SiemensOSV:5060;maddr=SiemensOSV>
> Content-Type: application/sdp
> Content-Length: 320
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
> Allow-Events: CCNR
> Date: Thu, 10 Jan 2013 21:47:24 GMT
> P-Asserted-Identity: "Siemens User" <sip:18077014 at SiemensOSV>
> From: Mark Holloway [mailto:mh at markholloway.com]
> Sent: Thursday, January 10, 2013 4:23 PM
> To: Heim, Dennis
> Cc: Kenneth Hayes; cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] SIP CUBE Caller ID
>
> What I was looking for, but didn't see in your TXT file, is the SIP INVITE from
CUCM includes the calling party name in the FROM field to CUBE, and CUBE includes
the same FROM name to Siemens. Assuming that is true, Siemens appears to be
disregarding the name portion of the FROM field by not only failing to display it,
but completely removing it in 1XX responses. It would be nice if it processed PAI
but I think the name is being stripped and then Siemens just assumes there is no
name for the call, as if PAI didn't exist.
>
> On Jan 10, 2013, at 3:56 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
>
>
> This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, without the name. I did not have a display name on my
phone, when I fixed that, the caller id name is visible to the siemens pbx.
>
> The problem still is that I dial a number and it does not put in the name
>
> The Cisco-Siemens direction, we see Cisco set the From with the name (From: ?
Cisco Phone? sip:5987800 at ip. We also see the P-Asserted-Identity set to ?Cisco
Phone? sip:5987800 at ip.
>
> On the invite coming back from the siemens we see it set the From, only contain
the number. However, the P-Asserted-Identity, contains the caller id name.
>
> From: Heim, Dennis
> Sent: Thursday, January 10, 2013 3:46 PM
> To: 'Kenneth Hayes'; Voice_VT
> Subject: RE: [cisco-voip] SIP CUBE Caller ID
>
> This is outbound from CUCM. I dial the number it connects and the display just
shows the dialed number, with the name. I did not have a display name on my phone,
when I fixed that, the caller id name is visible to the siemens pbx.
>
> The problem still is that I dial a number and it does not put in the name.
>
> From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]
> Sent: Thursday, January 10, 2013 3:29 PM
> To: Heim, Dennis
> Subject: Re: [cisco-voip] SIP CUBE Caller ID
>
> This is inbound correct?
>
> On Thu, Jan 10, 2013 at 2:55 PM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:
> It is showing in the PAI, but not the from field.
>
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> Timestamp: 1357847526
> Content-Length: 0
>
>
> Jan 10 19:52:06.991: //184752/427582000000/SIP/Info/sipSPICheckResponseExt:
INVITE response with no RSEQ - disable IS_REL1XX
> Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState: 0x2472CB8
: State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg
enqueued for SPI with IP addr: [10.98.88.38]:5060, local_address:[10.98.254.51]
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 2 for event 1
> Jan 10 19:52:07.119: //-
1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
Checking Invite Dialog
> Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 180 Ringing
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> From: sip:XXXX7800 at 10.210.61.43;tag=802E4C74-179B
> To: <sip:18077005 at 10.98.88.38>;tag=SEC11-a58620a-1e58d20a-1-zvE1E7A74E0q
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C
> Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>
> Date: Thu, 10 Jan 2013 19:52:29 GMT
> P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38>
> Content-Length: 0
>
> From: Mark Holloway [mailto:mh at markholloway.com]
> Sent: Thursday, January 10, 2013 1:51 PM
> To: Heim, Dennis
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] SIP CUBE Caller ID
>
> The FROM field should have a name in front of the phone number. (Like the bottom
line of text in this capture). Can you send the SIP INVITE from CUCM > CUBE, and
from CUBE to the PBX?
>
> <image001.png>
>
>
>
> On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
>
>
> I am doing a sip integration to a pbx. We are not getting the caller id
name/number when a call is placed form cisco to the pbx via the cube. We do see the
caller id name in the debugs, but not on the phone display.
>
> Received:
> SIP/2.0 200 OK
> Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51
> CSeq: 101 INVITE
> From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B
> To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7
> Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>
> Content-Type: application/sdp
> Content-Length: 367
> X-Siemens-Call-Type: ST-insecure
> Accept-Language: en;q=0.0
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
> Date: Thu, 10 Jan 2013 17:20:27 GMT
> P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>
>
> What am I missing?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/16fd96f6/attachment.html>

From tman701 at gmail.com Thu Jan 10 17:19:26 2013


From: tman701 at gmail.com (Joel Perez)
Date: Thu, 10 Jan 2013 17:19:26 -0500
Subject: [cisco-voip] SIP CUBE Caller ID
In-Reply-To: <0CC57FCAB07CEB4595526952471493D316F247D3B8@PRODCMS1.wwt.local>
References: <0CC57FCAB07CEB4595526952471493D316F247D315@PRODCMS1.wwt.local>
<3B793D75-EFA9-4601-AE9B-3BAC2F0B7628@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D358@PRODCMS1.wwt.local>
<CAKBLUbC=90Qjg90c6PHeE8+6YmnaK1mZz79sS2sUP5+AoPS06w@mail.gmail.com>
<0CC57FCAB07CEB4595526952471493D316F247D382@PRODCMS1.wwt.local>
<F3544AB7-071B-4494-B057-69A7796171CB@markholloway.com>
<0CC57FCAB07CEB4595526952471493D316F247D3B8@PRODCMS1.wwt.local>
Message-ID: <CABdWoUHTFgdqDFO9jPxKJTUKAOj_L-EUg1e7bZXWZQUtnxLCUg@mail.gmail.com>

You should be able to but it depends on the version of IOS.

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_exampl
e09186a0080982499.shtml

I havent tried it with CUBE, only with ACME but it should be the same or
similar.

Joel P.

On Thu, Jan 10, 2013 at 4:58 PM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:
> Is it possible with cube to take the PAI and copy it into the from field?*
> ***
>
> ** **
>
> *Call setup*
>
> * *
>
> INVITE sip:18077014 at CUBE:5060 SIP/2.0****
>
> Via: SIP/2.0/TCP CUCM:5060;branch=z9hG4bK1eda32bbab882****
>
> From: "Cisco Phone" <sip:5987800 at CUCM
> >;tag=2004325~37777082-f7ba-4cb2-8467-e286cea21f2e-88710674****
>
> To: <sip:18077014 at CUBE>****
>
> Date: Thu, 10 Jan 2013 21:47:24 GMT****
>
> Call-ID: 50330380-ef136ec-1a038-2b3dd20a at CUCM****
>
> Supported: timer,resource-priority,replaces****
>
> Min-SE: 1800****
>
> User-Agent: Cisco-CUCM8.6****
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY****
>
> CSeq: 101 INVITE****
>
> Expires: 180****
>
> Allow-Events: presence, kpml****
>
> Supported: X-cisco-srtp-fallback****
>
> Supported: Geolocation****
>
> Cisco-Guid: 1345520512-0000065536-0000033495-0725471754****
>
> Session-Expires: 1800****
>
> P-Asserted-Identity: "Cisco Phone" <sip:5987800 at CUCM>****
>
> Remote-Party-ID: "Cisco Phone" <sip:5987800 at CUCM
> >;party=calling;screen=yes;privacy=off****
>
> Contact: <sip:5987800 at CUCM:5060;transport=tcp>****
>
> Max-Forwards: 69****
>
> Content-Type: application/sdp****
>
> Content-Length: 214****
>
> ** **
>
> *When ringing*
>
> ** **
>
> Received: ****
>
> SIP/2.0 180 Ringing****
>
> Call-ID: 1A53E43D-5AA611E2-A21DF143-739C4300 at CUBE****
>
> CSeq: 101 INVITE****
>
> From: sip:5987800 at CUCM;tag=809784F8-1B9F****
>
> To: <sip:18077014 at SiemensOSV>;tag=SEC11-a58620a-1e58d20a-1-4197U1P1AG4o***
> *
>
> Via: SIP/2.0/UDP CUBE:5060;branch=z9hG4bK7B1AD5****
>
> Contact: <sip:18077014 at SiemensOSV:5060;maddr=SiemensOSV>****
>
> Content-Type: application/sdp****
>
> Content-Length: 320****
>
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO****
>
> Allow-Events: CCNR****
>
> Date: Thu, 10 Jan 2013 21:47:24 GMT****
>
> P-Asserted-Identity: "Siemens User" <sip:18077014 at SiemensOSV>****
>
> *From:* Mark Holloway [mailto:mh at markholloway.com]
> *Sent:* Thursday, January 10, 2013 4:23 PM
> *To:* Heim, Dennis
> *Cc:* Kenneth Hayes; cisco-voip at puck.nether.net
>
> *Subject:* Re: [cisco-voip] SIP CUBE Caller ID****
>
> ** **
>
> What I was looking for, but didn't see in your TXT file, is the SIP INVITE
> from CUCM includes the calling party name in the FROM field to CUBE, and
> CUBE includes the same FROM name to Siemens. Assuming that is true, Siemens
> appears to be disregarding the name portion of the FROM field by not only
> failing to display it, but completely removing it in 1XX responses. It
> would be nice if it processed PAI but I think the name is being stripped
> and then Siemens just assumes there is no name for the call, as if PAI
> didn't exist.****
>
> ** **
>
> On Jan 10, 2013, at 3:56 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:**
> **
>
>
>
> ****
>
> This is outbound from CUCM. I dial the number it connects and the display
> just shows the dialed number, without the name. I did not have a display
> name on my phone, when I fixed that, the caller id name is visible to the
> siemens pbx.****
>
> ****
>
> The problem still is that I dial a number and it does not put in the name*
> ***
>
> ****
>
> The Cisco-Siemens direction, we see Cisco set the From with the name
> (From: ?Cisco Phone? sip:5987800 at ip. We also see the P-Asserted-Identity
> set to ?Cisco Phone? sip:5987800 at ip.****
>
> ****
>
> On the invite coming back from the siemens we see it set the From, only
> contain the number. However, the P-Asserted-Identity, contains the caller
> id name.****
>
> ****
>
> *From:* Heim, Dennis
> *Sent:* Thursday, January 10, 2013 3:46 PM
> *To:* 'Kenneth Hayes'; Voice_VT
> *Subject:* RE: [cisco-voip] SIP CUBE Caller ID****
>
> ****
>
> This is outbound from CUCM. I dial the number it connects and the display
> just shows the dialed number, with the name. I did not have a display name
> on my phone, when I fixed that, the caller id name is visible to the
> siemens pbx.****
>
> ****
>
> The problem still is that I dial a number and it does not put in the name.
> ****
>
> ****
>
> *From:* Kenneth Hayes [mailto:kennethwhayes at gmail.com]
> *Sent:* Thursday, January 10, 2013 3:29 PM
> *To:* Heim, Dennis
> *Subject:* Re: [cisco-voip] SIP CUBE Caller ID****
>
> ****
>
> This is inbound correct?****
>
> On Thu, Jan 10, 2013 at 2:55 PM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:
> ****
>
> It is showing in the PAI, but not the from field.****
>
> ****
>
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51****
>
> CSeq: 101 INVITE****
>
> Timestamp: 1357847526****
>
> Content-Length: 0****
>
> ****
>
> ****
>
> Jan 10 19:52:06.991:
> //184752/427582000000/SIP/Info/sipSPICheckResponseExt: INVITE response with
> no RSEQ - disable IS_REL1XX****
>
> Jan 10 19:52:06.991: //184752/427582000000/SIP/State/sipSPIChangeState:
> 0x2472CB8 : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to
> (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)****
>
> Jan 10 19:52:07.119: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [10.98.88.38]:5060,
> local_address:[10.98.254.51]****
>
> Jan 10 19:52:07.119:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1****
>
> Jan 10 19:52:07.119:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x0
> ****
>
> Jan 10 19:52:07.119:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor: Checking Invite
> Dialog****
>
> Jan 10 19:52:07.119: //184752/427582000000/SIP/Msg/ccsipDisplayMsg:****
>
> Received:****
>
> SIP/2.0 180 Ringing****
>
> Call-ID: C2451EA-5A9611E2-92D3F143-739C4300 at 10.98.254.51****
>
> CSeq: 101 INVITE****
>
> From: sip:XXXX7800 at 10.210.61.43;tag=802E4C74-179B****
>
> To: <sip:18077005 at 10.98.88.38>;tag=SEC11-a58620a-1e58d20a-1-zvE1E7A74E0q**
> **
>
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK5C1C8C****
>
> Contact: <sip:18077005 at 10.98.88.38:5060;maddr=10.98.88.38>****
>
> Date: Thu, 10 Jan 2013 19:52:29 GMT****
>
> P-Asserted-Identity: "My Name" <sip:8077005 at 10.98.88.38>****
>
> Content-Length: 0****
>
> ****
>
> *From:* Mark Holloway [mailto:mh at markholloway.com]
> *Sent:* Thursday, January 10, 2013 1:51 PM
> *To:* Heim, Dennis
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] SIP CUBE Caller ID****
>
> ****
>
> The FROM field should have a name in front of the phone number. (Like the
> bottom line of text in this capture). Can you send the SIP INVITE from
> CUCM > CUBE, and from CUBE to the PBX? ****
>
> ****
>
> <image001.png>****
>
> ****
>
> ****
>
> ****
>
> On Jan 10, 2013, at 1:26 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:**
> **
>
> ****
>
> I am doing a sip integration to a pbx. We are not getting the caller id
> name/number when a call is placed form cisco to the pbx via the cube. We do
> see the caller id name in the debugs, but not on the phone display.****
>
> ****
>
> Received:****
>
> SIP/2.0 200 OK****
>
> Call-ID: CD2B18C9-5A8011E2-80D5F143-739C4300 at 10.98.254.51****
>
> CSeq: 101 INVITE****
>
> From: <sip:XXXXXXXXXX at 10.98.254.51>;tag=7FA30F9C-154B****
>
> To: <sip:18077014 at osv1.XXX.com>;tag=SEC21-a58620a-1e58d20a-2-1e9kU4nFr1Kp*
> ***
>
> Via: SIP/2.0/UDP 10.98.254.51:5060;branch=z9hG4bK456B7****
>
> Contact: <sip:18077014 at 10.210.88.39:5060;maddr=10.210.88.39>****
>
> Content-Type: application/sdp****
>
> Content-Length: 367****
>
> X-Siemens-Call-Type: ST-insecure****
>
> Accept-Language: en;q=0.0****
>
> Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO****
>
> Date: Thu, 10 Jan 2013 17:20:27 GMT****
>
> P-Asserted-Identity: "My Name" <sip:8077014 at 10.210.88.39>****
>
> ****
>
> What am I missing?****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ****
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/53da0d8b/attachment.html>

From mizzou0 at yahoo.com Thu Jan 10 21:08:02 2013


From: mizzou0 at yahoo.com (Me)
Date: Thu, 10 Jan 2013 18:08:02 -0800
Subject: [cisco-voip] Simulate SIP error code 408 and 603 from CUBE
Message-ID: <CAGBqMBjocfDmaMijThnXFWXCtF=_qSbxFuH+EYVyNtpcopztcA@mail.gmail.com>

Is there a way to simulate SIP error code 408 (Not Available) and 603
(Reject) from a Cisco CUBE? Such as making a call to a number router
returns the SIP errors.

Regards,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/5ebd8f05/attachment.html>

From mh at markholloway.com Thu Jan 10 22:30:41 2013


From: mh at markholloway.com (Mark Holloway)
Date: Thu, 10 Jan 2013 22:30:41 -0500
Subject: [cisco-voip] Simulate SIP error code 408 and 603 from CUBE
In-Reply-To: <CAGBqMBjocfDmaMijThnXFWXCtF=_qSbxFuH+EYVyNtpcopztcA@mail.gmail.com>
References: <CAGBqMBjocfDmaMijThnXFWXCtF=_qSbxFuH+EYVyNtpcopztcA@mail.gmail.com>
Message-ID: <05DC3998-0E6A-4C0F-9C9D-3630BFD9234E@markholloway.com>

You need a SIP device to originate the call to CUBE and something on the "other
side" of CUBE to generate the 603 message. For SIP 408, this usually occurs when a
SIP INVITE Timeout occurs. You could configure CUBE to forward to some null device
to the INVITE will timeout and CUBE will send 408 back to the originating party.

SIPp and X-Lite work well for this sort of thing.

On Jan 10, 2013, at 9:08 PM, Me <mizzou0 at yahoo.com> wrote:

> Is there a way to simulate SIP error code 408 (Not Available) and 603 (Reject)
from a Cisco CUBE? Such as making a call to a number router returns the SIP
errors.
>
> Regards,
> Dave
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130110/5de09708/attachment.html>

From ahmed_elnagar at hotmail.com Fri Jan 11 09:10:37 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Fri, 11 Jan 2013 16:10:37 +0200
Subject: [cisco-voip] Cisco Unified IP Phone Local Kernel System Call Input
Validation Vulnerability
Message-ID: <BAY149-ds36C305B9071A909BD158C87290@phx.gbl>

I think someone was asking about the below a couple of days

Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green


From: CiscoNotificationService at cisco.com
[mailto:CiscoNotificationService at cisco.com]
Sent: Thursday, January 10, 2013 3:33 PM
To: Ahmed Elnagar
Subject: Cisco Notification Alert -UC-Products-01/10/2013 13:32 GMT

Cisco Notification Service Alert:


____________________________________________________________________________
____

Security Advisories & Responses for All Voice and Unified Communications

Title

Cisco Unified IP Phone Local Kernel System Call Input Validation


Vulnerability
<http://www.cisco.com/en/US/products/csa/cisco-sa-20130109-uipphone.html>

Description

Cisco Unified IP Phones 7900 Series versions 9.3(1)SR1 and prior contain an
arbitrary code execution vulnerability that could allow a local attacker to
execute code or modify arbitrary memory with elevated privileges. This
vulnerability is due to a failure to properly validate input passed to
kernel system calls from applications running in userspace. An attacker
could exploit this issue by gaining local access to the device using
physical access or authenticated access using SSH and executing an
attacker-controlled binary that is designed to exploit the issue. Such an
attack would originate from an unprivileged context. Ang Cui initially
reported the issue to the Cisco Product Security Incident Response Team
(PSIRT). On November 6, 2012, the Cisco PSIRT disclosed this issue in Cisco
bug ID CSCuc83860 (registered customers only) Release Note Enclosure.
Subsequently, Mr. Cui has spoken at several public conferences and has
performed public demonstrations of a device being compromised and used as a
listening device. Mitigations are available to help reduce the attack
surface of affected devices. See the &quo;Details&quo; section of this
security advisory and the accompanying Cisco Applied Mitigation Bulletin
(AMB) for additional information. This advisory is available at the
following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-s
a-20130109-uipphone

Date

09-JAN-2013
For more information; you can visit Cisco Security Advisories
<http://www.cisco.com/en/US/products/products_security_advisories_listing.ht
ml> & Responses index.
____________________________________________________________________________
____

To unsubscribe this notification click here


<http://www.cisco.com/cisco/support/notifications/addedit.html?notiId=186498
>

Help us improve this facility. To give feedback click here


<http://www.cisco.com/cisco/support/notifications.html#feedback>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130111/bb4a8717/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130111/bb4a8717/attachment.jpg>

From dzhars at gmail.com Fri Jan 11 13:32:53 2013


From: dzhars at gmail.com (David Zhars)
Date: Fri, 11 Jan 2013 13:32:53 -0500
Subject: [cisco-voip] FWD one Ext to Another
Message-ID: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>

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.html>

From tman701 at gmail.com Fri Jan 11 14:24:36 2013


From: tman701 at gmail.com (Joel Perez)
Date: Fri, 11 Jan 2013 14:24:36 -0500
Subject: [cisco-voip] FWD one Ext to Another
In-Reply-To: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
References: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
Message-ID: <CABdWoUFirq_PnXgGdThGwgQe+7wVoXNfYqaNier4mBe-DiZL3g@mail.gmail.com>

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 <dzhars at gmail.com> 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
> cisco-voip at puck.nether.net
> 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.html>

From rratliff at cisco.com Fri Jan 11 14:28:15 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Fri, 11 Jan 2013 14:28:15 -0500
Subject: [cisco-voip] FWD one Ext to Another
In-Reply-To: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
References: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
Message-ID: <CC5F2DCE-8E8D-46B8-AAB5-FAA32CAB83A4@cisco.com>

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 <dzhars at gmail.com> 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
cisco-voip at puck.nether.net
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.html>

From avholloway+cisco-voip at gmail.com Fri Jan 11 15:11:56 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Fri, 11 Jan 2013 14:11:56 -0600
Subject: [cisco-voip] CUCM MTP and g729
Message-ID: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>

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.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.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-0001.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-0002.png>

From jsteinberg at gmail.com Fri Jan 11 15:43:07 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Fri, 11 Jan 2013 15:43:07 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
Message-ID: <CACCAghZi4gbL6M-iEJcNfR+BS=oMBczN=2jJ7DBWzkmuEqpq7g@mail.gmail.com>

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 <


avholloway+cisco-voip at gmail.com> 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
> cisco-voip at puck.nether.net
> 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.html>

From wsisk at cisco.com Fri Jan 11 15:48:00 2013


From: wsisk at cisco.com (Wes Sisk)
Date: Fri, 11 Jan 2013 15:48:00 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
Message-ID: <3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>

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

From avholloway+cisco-voip at gmail.com Fri Jan 11 16:02:15 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Fri, 11 Jan 2013 15:02:15 -0600
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACCAghZi4gbL6M-iEJcNfR+BS=oMBczN=2jJ7DBWzkmuEqpq7g@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<CACCAghZi4gbL6M-iEJcNfR+BS=oMBczN=2jJ7DBWzkmuEqpq7g@mail.gmail.com>
Message-ID: <CACRCJOiYAgisxj-UR_1T-SHmL-yYTJvJhe=kFQ1A8CS6iCp6eg@mail.gmail.com>

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 <jsteinberg at gmail.com>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 <
> avholloway+cisco-voip at gmail.com> 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
>> cisco-voip at puck.nether.net
>> 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.html>

From avholloway+cisco-voip at gmail.com Fri Jan 11 16:08:54 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Fri, 11 Jan 2013 15:08:54 -0600
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
Message-ID: <CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>

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 <wsisk at cisco.com> 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
> cisco-voip at puck.nether.net
> 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.html>

From peter.slow at gmail.com Fri Jan 11 16:13:17 2013


From: peter.slow at gmail.com (Peter Slow)
Date: Fri, 11 Jan 2013 16:13:17 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOiYAgisxj-UR_1T-SHmL-yYTJvJhe=kFQ1A8CS6iCp6eg@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<CACCAghZi4gbL6M-iEJcNfR+BS=oMBczN=2jJ7DBWzkmuEqpq7g@mail.gmail.com>
<CACRCJOiYAgisxj-UR_1T-SHmL-yYTJvJhe=kFQ1A8CS6iCp6eg@mail.gmail.com>
Message-ID: <CAMa5Jw7ZznC4s8ExtRuy3ZTi_S8MrnB0gAuQorCw0FxG+ZFN0w@mail.gmail.com>

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


<avholloway+cisco-voip at gmail.com> 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 <jsteinberg at gmail.com>
> 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
>> <avholloway+cisco-voip at gmail.com> 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
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

From peter.slow at gmail.com Fri Jan 11 16:24:35 2013


From: peter.slow at gmail.com (Peter Slow)
Date: Fri, 11 Jan 2013 16:24:35 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
Message-ID: <CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>

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


<avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

From avholloway+cisco-voip at gmail.com Fri Jan 11 16:36:13 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Fri, 11 Jan 2013 15:36:13 -0600
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
Message-ID: <CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>

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 <peter.slow at gmail.com> 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
> <avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > 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.html>

From peter.slow at gmail.com Fri Jan 11 16:48:37 2013


From: peter.slow at gmail.com (Peter Slow)
Date: Fri, 11 Jan 2013 16:48:37 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
<CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
Message-ID: <CAMa5Jw6ZJqrba8Hp9OgxcZtsmpXv6W13Pm6-QV99=WsKD3Zs4Q@mail.gmail.com>

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


<avholloway+cisco-voip at gmail.com> 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 <peter.slow at gmail.com> 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
>> <avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
>> >> cisco-voip at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>
>> >
>> >
>> > _______________________________________________
>> > cisco-voip mailing list
>> > cisco-voip at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>
>

From rratliff at cisco.com Fri Jan 11 17:02:35 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Fri, 11 Jan 2013 17:02:35 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
<CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
Message-ID: <A287F450-2809-4BE6-A3D1-9584CC120CE1@cisco.com>

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 <avholloway+cisco-voip at gmail.com>


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 <peter.slow at gmail.com> 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


<avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
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.html>

From dzhars at gmail.com Fri Jan 11 19:49:08 2013


From: dzhars at gmail.com (David Zhars)
Date: Fri, 11 Jan 2013 19:49:08 -0500
Subject: [cisco-voip] FWD one Ext to Another
In-Reply-To: <253075E8-E4F6-4CA9-B9D8-248D96CC345C@cisco.com>
References: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
<CC5F2DCE-8E8D-46B8-AAB5-FAA32CAB83A4@cisco.com>
<CADe=jTHy5Po+7wYUFF1bRo7d1xpOxh-HvwuWyP7bpfCGN3nwFQ@mail.gmail.com>
<253075E8-E4F6-4CA9-B9D8-248D96CC345C@cisco.com>
Message-ID: <CADe=jTF5qu4XvN-NRvYKa_OHQNXcXDuWeqD4Z5-9E9b_TE_0Mg@mail.gmail.com>

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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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
>> cisco-voip at puck.nether.net
>> 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.html>

From george.hendrix at l-3com.com Sat Jan 12 07:45:58 2013


From: george.hendrix at l-3com.com (george.hendrix at l-3com.com)
Date: Sat, 12 Jan 2013 12:45:58 +0000
Subject: [cisco-voip] CUC Cluster replication issues
Message-ID: <255F57BB43F894468DA6BD4F2F5DD1CE6490DEF1@RSTN-S-MBX01.net.its.l-
3com.com>

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.html>

From jason.aarons at dimensiondata.com Sat Jan 12 12:45:23 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Sat, 12 Jan 2013 12:45:23 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <A287F450-2809-4BE6-A3D1-9584CC120CE1@cisco.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
<CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
<A287F450-2809-4BE6-A3D1-9584CC120CE1@cisco.com>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C718859@USISPCLEXDB01.na.didata.local>

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: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] 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 <avholloway+cisco-voip at


gmail.com<mailto:avholloway+cisco-voip at gmail.com>> 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 <peter.slow at


gmail.com<mailto:peter.slow at gmail.com>> 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


<avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>>
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 <wsisk at cisco.com<mailto:wsisk at
cisco.com>> 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
>> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
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.html>

From george.hendrix at l-3com.com Sat Jan 12 15:10:27 2013


From: george.hendrix at l-3com.com (george.hendrix at l-3com.com)
Date: Sat, 12 Jan 2013 20:10:27 +0000
Subject: [cisco-voip] CUC Cluster replication issues
In-Reply-To: <549601cdf0f1$35256480$9f702d80$@gmail.com>
References: <255F57BB43F894468DA6BD4F2F5DD1CE6490DEF1@RSTN-S-MBX01.net.its.l-
3com.com>
<549601cdf0f1$35256480$9f702d80$@gmail.com>
Message-ID: <255F57BB43F894468DA6BD4F2F5DD1CE6490DF81@RSTN-S-MBX01.net.its.l-
3com.com>

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: mike.lydick at gmail.com [mailto:mike.lydick at gmail.com]


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: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
george.hendrix at l-3com.com<mailto:george.hendrix at l-3com.com>
Sent: Saturday, January 12, 2013 7:46 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
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.html>

From mike.lydick at gmail.com Sat Jan 12 15:49:34 2013


From: mike.lydick at gmail.com (Mike Lydick)
Date: Sat, 12 Jan 2013 15:49:34 -0500
Subject: [cisco-voip] CUC Cluster replication issues
In-Reply-To: <255F57BB43F894468DA6BD4F2F5DD1CE6490DF81@RSTN-S-MBX01.net.its.l-
3com.com>
References: <255F57BB43F894468DA6BD4F2F5DD1CE6490DEF1@RSTN-S-MBX01.net.its.l-
3com.com>
<549601cdf0f1$35256480$9f702d80$@gmail.com>
<255F57BB43F894468DA6BD4F2F5DD1CE6490DF81@RSTN-S-MBX01.net.its.l-3com.com>
Message-ID: <227f901cdf106$54bcf5a0$fe36e0e0$@gmail.com>

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: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Saturday, January 12, 2013 3:10 PM
To: mike.lydick at gmail.com; cisco-voip at puck.nether.net
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: mike.lydick at gmail.com [mailto:mike.lydick at gmail.com]


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: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
george.hendrix at l-3com.com
Sent: Saturday, January 12, 2013 7:46 AM
To: cisco-voip at puck.nether.net
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.html>

From peter.slow at gmail.com Sat Jan 12 16:43:36 2013


From: peter.slow at gmail.com (Peter Slow)
Date: Sat, 12 Jan 2013 16:43:36 -0500
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C718859@USISPCLEXDB01.na.didata.local>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
<CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
<A287F450-2809-4BE6-A3D1-9584CC120CE1@cisco.com>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C718859@USISPCLEXDB01.na.didata.local>
Message-ID: <188F72A9-D5A4-448A-A2CE-059A5942833A@gmail.com>

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)" <jason.aarons at
dimensiondata.com> 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: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] 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 <avholloway+cisco-voip at
gmail.com> 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 <peter.slow at gmail.com> 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
> <avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> itevomcid
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> 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.html>

From erickbee at gmail.com Sun Jan 13 00:22:27 2013


From: erickbee at gmail.com (Erick B.)
Date: Sat, 12 Jan 2013 23:22:27 -0600
Subject: [cisco-voip] FWD one Ext to Another
In-Reply-To: <CADe=jTF5qu4XvN-NRvYKa_OHQNXcXDuWeqD4Z5-9E9b_TE_0Mg@mail.gmail.com>
References: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
<CC5F2DCE-8E8D-46B8-AAB5-FAA32CAB83A4@cisco.com>
<CADe=jTHy5Po+7wYUFF1bRo7d1xpOxh-HvwuWyP7bpfCGN3nwFQ@mail.gmail.com>
<253075E8-E4F6-4CA9-B9D8-248D96CC345C@cisco.com>
<CADe=jTF5qu4XvN-NRvYKa_OHQNXcXDuWeqD4Z5-9E9b_TE_0Mg@mail.gmail.com>
Message-ID: <CAHSnBQyyhz7b=LHzHtan_a0HfCiyt73GOvZgWnHnmxnq8Cg0zg@mail.gmail.com>

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 <dzhars at gmail.com> 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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> 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.html>

From MLoraditch at heliontechnologies.com Sun Jan 13 08:58:28 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Sun, 13 Jan 2013 13:58:28 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
Message-ID: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130113/a1866840/attachment.html>

From MLoraditch at heliontechnologies.com Sun Jan 13 15:06:25 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Sun, 13 Jan 2013 20:06:25 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change... the
unity connection pub is still running, I think we are on hour 15 of that...

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 9.1 Upgrade Times

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130113/d1ce9cdb/attachment.html>

From rratliff at cisco.com Mon Jan 14 11:06:07 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 14 Jan 2013 11:06:07 -0500
Subject: [cisco-voip] FWD one Ext to Another
In-Reply-To: <CAHSnBQyyhz7b=LHzHtan_a0HfCiyt73GOvZgWnHnmxnq8Cg0zg@mail.gmail.com>
References: <CADe=jTGzpoYcj4FjwqfMWs+5x9mw1Xtg7BSShnCA=WeAyhYYjQ@mail.gmail.com>
<CC5F2DCE-8E8D-46B8-AAB5-FAA32CAB83A4@cisco.com>
<CADe=jTHy5Po+7wYUFF1bRo7d1xpOxh-HvwuWyP7bpfCGN3nwFQ@mail.gmail.com>
<253075E8-E4F6-4CA9-B9D8-248D96CC345C@cisco.com>
<CADe=jTF5qu4XvN-NRvYKa_OHQNXcXDuWeqD4Z5-9E9b_TE_0Mg@mail.gmail.com>
<CAHSnBQyyhz7b=LHzHtan_a0HfCiyt73GOvZgWnHnmxnq8Cg0zg@mail.gmail.com>
Message-ID: <3F1A3BD3-9CA1-4600-8C60-4510D2DD8959@cisco.com>

> 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.

The use of an alternate extension is for the case when there is only one mailbox in
Unity, with two extensions that could be calling into it (forwarded or not).

-Ryan

On Jan 13, 2013, at 12:22 AM, Erick B. <erickbee at gmail.com> wrote:

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 <dzhars at gmail.com> 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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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 <rratliff at cisco.com> 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 <dzhars at gmail.com> 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
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/8e270105/attachment.html>

From MLoraditch at heliontechnologies.com Mon Jan 14 11:26:39 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Mon, 14 Jan 2013 16:26:39 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>

So I figured I'd loop around and let everyone know how things ended up.
Unity Connection never finished the first attempt and wouldn't cancel either. I had
to force a shutdown. After it came back up I tried again... 90 minutes boom.
Suffice it to say. I wish had done that sooner.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change... the
unity connection pub is still running, I think we are on hour 15 of that...

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] 9.1 Upgrade Times

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/ceee7a1f/attachment.html>

From petrybr at gmail.com Mon Jan 14 11:42:30 2013


From: petrybr at gmail.com (=?ISO-8859-1?Q?Jos=E9_Paulo_de_Oliveira_Petry?=)
Date: Mon, 14 Jan 2013 14:42:30 -0200
Subject: [cisco-voip] License migration: 8.6 -> 9.0
Message-ID: <CAMX+=-X2NE+DguYETCZ4TOJoC=Hbj27=TxCDwnh7tfBb=FDnRA@mail.gmail.com>

Hello,

I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.

To migrate licenses (DLU to CUWL) im using this doc:


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/migratn.html#wp1067112

After i add the CUCM instance, im trying to use the Migration Utility, but
im receiving this error:

"There are no Unified CM product instances with pre-9.0 licenses available


for upgrade"

Any suggestion?

Regards,

Jos? Paulo de Oliveira Petry


petrybr at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/88eb4ec5/attachment.html>

From tfrazee at gmail.com Mon Jan 14 11:45:00 2013


From: tfrazee at gmail.com (Tim Frazee)
Date: Mon, 14 Jan 2013 10:45:00 -0600
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
Message-ID: <CABzsfHxm-nH3DW-mYvFc8TqsWVjV7dHm+1DonOdR=g-q+ecwhg@mail.gmail.com>

so would you suggest a clean reboot before the upgrade of CUC to at least
9.1 ?

On Mon, Jan 14, 2013 at 10:26 AM, Matthew Loraditch <


MLoraditch at heliontechnologies.com> wrote:

> So I figured I?d loop around and let everyone know how things ended up.**
> **
>
> Unity Connection never finished the first attempt and wouldn?t cancel
> either. I had to force a shutdown. After it came back up I tried again? 90
> minutes boom. Suffice it to say. I wish had done that sooner. ****
>
> ** **
>
> ** **
>
> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
> ****
>
> ** **
>
> ** **
>
> *From:* Matthew Loraditch
> *Sent:* Sunday, January 13, 2013 3:06 PM
> *To:* Matthew Loraditch; cisco-voip at puck.nether.net
> *Subject:* RE: 9.1 Upgrade Times****
>
> ** **
>
> Well my CUCM publisher took almost 13 hours, my sub took 1 hour and
> change? the unity connection pub is still running, I think we are on hour
> 15 of that?****
>
> ** **
>
> ** **
>
> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
> ****
>
> ** **
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [
> mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at
puck.nether.net>]
> *On Behalf Of *Matthew Loraditch
> *Sent:* Sunday, January 13, 2013 8:58 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] 9.1 Upgrade Times****
>
> ** **
>
> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
> ****
>
> ** **
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/9560fde5/attachment.html>

From VanMarenNP at ldschurch.org Mon Jan 14 11:45:26 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Mon, 14 Jan 2013 16:45:26 +0000
Subject: [cisco-voip] License migration: 8.6 -> 9.0
In-Reply-To: <CAMX+=-X2NE+DguYETCZ4TOJoC=Hbj27=TxCDwnh7tfBb=FDnRA@mail.gmail.com>
References: <CAMX+=-X2NE+DguYETCZ4TOJoC=Hbj27=TxCDwnh7tfBb=FDnRA@mail.gmail.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E71580@W12112.ldschurch.org>

Run from 9.0 and do 9.1. You'll have to redo all of the licenses when you go to
9.1 anyways.

All of the 9.0 upgrades that I did the ELM work flawlessly once the ESXi host that
it was on had a proper NIC teaming configuration.

-Nate

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Jos? Paulo de Oliveira Petry
Sent: Monday, January 14, 2013 9:43 AM
To: Cisco VoIPoE List
Subject: [cisco-voip] License migration: 8.6 -> 9.0

Hello,

I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.

To migrate licenses (DLU to CUWL) im using this doc:


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/migratn.html#wp1067112

After i add the CUCM instance, im trying to use the Migration Utility, but im
receiving this error:

"There are no Unified CM product instances with pre-9.0 licenses available for
upgrade"

Any suggestion?
Regards,

Jos? Paulo de Oliveira Petry


petrybr at gmail.com<mailto:petrybr at gmail.com>

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/2c266ffa/attachment.html>

From Leslie.Meade at lvs1.com Mon Jan 14 11:56:35 2013


From: Leslie.Meade at lvs1.com (Leslie Meade)
Date: Mon, 14 Jan 2013 16:56:35 +0000
Subject: [cisco-voip] UCCX cluster
Message-ID:
<F64719604B4E6F41BDBB2AF38E7609F433DF4D9E@LVSCGYEX03.longviewsystems.com>

I am adding a new uccx server into a cluster. I have been told that once this is
done, there will be an outage while the Data base is replicated to the HA.
Is this true ? I am trying to find doc on this

Cheers

Leslie

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/8a66d29f/attachment.html>

From MLoraditch at heliontechnologies.com Mon Jan 14 12:08:18 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Mon, 14 Jan 2013 17:08:18 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <CABzsfHxm-nH3DW-mYvFc8TqsWVjV7dHm+1DonOdR=g-q+ecwhg@mail.gmail.com>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
<CABzsfHxm-nH3DW-mYvFc8TqsWVjV7dHm+1DonOdR=g-q+ecwhg@mail.gmail.com>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E2983110B618A@PHANES.helion.local>

To answer you and Nate


The server had been up for Several Months and yes it looks like it wouldn't hurt to
do a reboot.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: Tim Frazee [mailto:tfrazee at gmail.com]


Sent: Monday, January 14, 2013 11:45 AM
To: Matthew Loraditch
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

so would you suggest a clean reboot before the upgrade of CUC to at least 9.1 ?
On Mon, Jan 14, 2013 at 10:26 AM, Matthew Loraditch <MLoraditch at
heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>> wrote:
So I figured I'd loop around and let everyone know how things ended up.
Unity Connection never finished the first attempt and wouldn't cancel either. I had
to force a shutdown. After it came back up I tried again... 90 minutes boom.
Suffice it to say. I wish had done that sooner.

Matthew G. Loraditch - CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830<tel:410.252.8830>
fax. 410.252.9284<tel:410.252.9284>

Twitter<http://twitter.com/heliontech> |
Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> |
Website<http://www.heliontechnologies.com/> | Email Support<mailto:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change... the
unity connection pub is still running, I think we are on hour 15 of that...

Matthew G. Loraditch - CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830<tel:410.252.8830>
fax. 410.252.9284<tel:410.252.9284>

Twitter<http://twitter.com/heliontech> |
Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> |
Website<http://www.heliontechnologies.com/> | Email Support<mailto:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] 9.1 Upgrade Times

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<tel:410.252.8830>
fax. 410.252.9284<tel:410.252.9284>

Twitter<http://twitter.com/heliontech> |
Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> |
Website<http://www.heliontechnologies.com/> | Email Support<mailto:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/6e960b75/attachment.html>

From avholloway+cisco-voip at gmail.com Mon Jan 14 12:08:22 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Mon, 14 Jan 2013 11:08:22 -0600
Subject: [cisco-voip] UCCX cluster
In-Reply-To:
<F64719604B4E6F41BDBB2AF38E7609F433DF4D9E@LVSCGYEX03.longviewsystems.com>
References:
<F64719604B4E6F41BDBB2AF38E7609F433DF4D9E@LVSCGYEX03.longviewsystems.com>
Message-ID: <CACRCJOgW0jKdKiYJrjb8E8nGPAEN7VZwn2k9PL2rBNDL2=igOA@mail.gmail.com>
It's in the Admin Guide
[link<http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1846/products_insta
llation_and_configuration_guides_list.html>],
and it's a note, that calls *may* be dropped. I don't have any concrete
data to share with you, as I have only ever built HA from the get-go.

[image: Inline image 1]

On Mon, Jan 14, 2013 at 10:56 AM, Leslie Meade <Leslie.Meade at lvs1.com>wrote:

> I am adding a new uccx server into a cluster. I have been told that once
> this is done, there will be an outage while the Data base is replicated to
> the HA.****
>
> Is this true ? I am trying to find doc on this****
>
> ** **
>
> ** **
>
> Cheers****
>
> ** **
>
> ** **
>
> Leslie****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/9d722088/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uccx-add-ha-second-node-note.png
Type: image/png
Size: 18236 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/9d722088/attachment.png>

From VanMarenNP at ldschurch.org Mon Jan 14 11:33:25 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Mon, 14 Jan 2013 16:33:25 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E71556@W12112.ldschurch.org>
How long had the server been up before the you started the first upgrade?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Monday, January 14, 2013 9:27 AM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

So I figured I'd loop around and let everyone know how things ended up.
Unity Connection never finished the first attempt and wouldn't cancel either. I had
to force a shutdown. After it came back up I tried again... 90 minutes boom.
Suffice it to say. I wish had done that sooner.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change... the
unity connection pub is still running, I think we are on hour 15 of that...

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] 9.1 Upgrade Times

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/6e6a3efc/attachment.html>

From jbuchanan at presidio.com Mon Jan 14 13:03:39 2013


From: jbuchanan at presidio.com (Buchanan, James)
Date: Mon, 14 Jan 2013 18:03:39 +0000
Subject: [cisco-voip] UCCX cluster
In-Reply-To: <CACRCJOgW0jKdKiYJrjb8E8nGPAEN7VZwn2k9PL2rBNDL2=igOA@mail.gmail.com>
References:
<F64719604B4E6F41BDBB2AF38E7609F433DF4D9E@LVSCGYEX03.longviewsystems.com>
<CACRCJOgW0jKdKiYJrjb8E8nGPAEN7VZwn2k9PL2rBNDL2=igOA@mail.gmail.com>
Message-ID: <12D6A6A157B44348974E5ED93738628C25369137@HQEXCHMBX03.Presidio.Corp>

What will happen is that the CCX Engine will need to restart (at least). There may
also be issues while the port group is being rebuilt with the added ports. This
will create an outage.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Anthony Holloway
Sent: Monday, January 14, 2013 7:08 PM
To: Leslie Meade
Cc: cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] UCCX cluster

It's in the Admin Guide


[link<http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1846/products_insta
llation_and_configuration_guides_list.html>], and it's a note, that calls *may* be
dropped. I don't have any concrete data to share with you, as I have only ever
built HA from the get-go.

[Inline image 1]

On Mon, Jan 14, 2013 at 10:56 AM, Leslie Meade <Leslie.Meade at


lvs1.com<mailto:Leslie.Meade at lvs1.com>> wrote:
I am adding a new uccx server into a cluster. I have been told that once this is
done, there will be an outage while the Data base is replicated to the HA.
Is this true ? I am trying to find doc on this

Cheers

Leslie

James Buchanan | Sr. Network Engineer


Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at
presidio.com<mailto:jbuchanan at presidio.com>

[Be Secure In The Knowledge]<http://www.presidio.com>

Follow us:

[Follow Presidio on Twitter]<http://www.twitter.com/presidio>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is intended solely for the use of the intended
recipient(s) and may contain information that is privileged, confidential or
proprietary. If you are not an intended recipient, please notify the sender, and
then please delete and destroy all copies and attachments. Please be advised that
any review or dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/1f3dd87f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 18236 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/1f3dd87f/attachment.png>

From tanner.ezell at gmail.com Mon Jan 14 13:11:17 2013


From: tanner.ezell at gmail.com (Tanner Ezell)
Date: Mon, 14 Jan 2013 11:11:17 -0700
Subject: [cisco-voip] UCCX cluster
In-Reply-To: <12D6A6A157B44348974E5ED93738628C25369137@HQEXCHMBX03.Presidio.Corp>
References:
<F64719604B4E6F41BDBB2AF38E7609F433DF4D9E@LVSCGYEX03.longviewsystems.com>
<CACRCJOgW0jKdKiYJrjb8E8nGPAEN7VZwn2k9PL2rBNDL2=igOA@mail.gmail.com>
<12D6A6A157B44348974E5ED93738628C25369137@HQEXCHMBX03.Presidio.Corp>
Message-ID: <CADsErBYOzGxYPQF2Aiyqmf+ZN=FqG9w=b9McfXVyyUP=BfK18w@mail.gmail.com>

Note that the call control groups will not expand automatically, you'll
need to create the second set of ports on the CCG (at least that is the
behavior on SU4)

On Mon, Jan 14, 2013 at 11:03 AM, Buchanan, James <jbuchanan at presidio.com>wrote:

> What will happen is that the CCX Engine will need to restart (at
> least). There may also be issues while the port group is being rebuilt with
> the added ports. This will create an outage.****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Anthony Holloway
> *Sent:* Monday, January 14, 2013 7:08 PM
> *To:* Leslie Meade
> *Cc:* cisco-voip (cisco-voip at puck.nether.net)
> *Subject:* Re: [cisco-voip] UCCX cluster****
>
> ** **
>
> It's in the Admin Guide
[link<http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1846/products_insta
llation_and_configuration_guides_list.html>],
> and it's a note, that calls *may* be dropped. I don't have any concrete
> data to share with you, as I have only ever built HA from the get-go.
>
> [image: Inline image 1]****
>
> ** **
>
> On Mon, Jan 14, 2013 at 10:56 AM, Leslie Meade <Leslie.Meade at lvs1.com>
> wrote:****
>
> I am adding a new uccx server into a cluster. I have been told that once
> this is done, there will be an outage while the Data base is replicated to
> the HA.****
>
> Is this true ? I am trying to find doc on this****
>
> ****
>
> ****
>
> Cheers****
>
> ****
>
> ****
>
> Leslie****
>
> ****
>
>
>
> James Buchanan | Sr. Network Engineer
> Presidio | www.presidio.com
> 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
> jbuchanan at presidio.com
>
>
>
> [image: Be Secure In The Knowledge] <http://www.presidio.com>
>
>
> Follow us:
>
> [image: Follow Presidio on Twitter] <http://www.twitter.com/presidio>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
> *This message w/attachments (message) is intended solely for the use of
> the intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments. Please be advised that any review or dissemination of, or
> the taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.*****
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/732bf1c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 18236 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/732bf1c2/attachment.png>

From jmad at cityofevanston.org Mon Jan 14 12:35:02 2013


From: jmad at cityofevanston.org (Madziarczyk, Jonathan)
Date: Mon, 14 Jan 2013 11:35:02 -0600
Subject: [cisco-voip] Upgrading from 6x to 9x?
Message-ID:
<4604610D6AAC164AA12B9E03AB79028B0B7B9E82@EXCHANGE3.local.cityofevanston.org>

So I know Cisco did a full presentation at Live last year on this


(including moving from physical to virtual), but they didn't think to
record it, so all I have is the powerpoint, which is sadly lacking in
information. Has anyone seen a webex or similar presentation that
actually goes through the process and mentions all the caveats?

JonM

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/5432ea02/attachment.html>

From dane.newman at gmail.com Mon Jan 14 15:40:33 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 15:40:33 -0500
Subject: [cisco-voip] Mobility Issue
Message-ID: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>

Hello

I have an issue when users are connected to a call and hit the mobility
soft key button on 9971 phones when a call is active, the phone system
rings on the mobile number configured in the system. When they pick up the
the mobile number it just plays what sounds like hold music on both ends of
the call (I believe this music is coming from cucm but I haven't heard it
before) instead of providing 2 way voice.

In another senario with what I believe is the same issue. If a user picks
up on there cell phone first (using single number reach) opposed to the
deskphone the call is connected with 2 way voice and no issues exist. If
the user then hangs up his cell phone with the intent to take the call on
his deskphone the calling party starts hearing the hold music. Once the
user picks up the call on his deskphone he hears nothing but the calling
party is still hearing the hold music. It is not working as intended where
2 way voice happens once the user hangs up his mobile phone and picks up on
his deskphone 2 way voice should happen.

My topology is as follows..

PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE

Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.

Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/7d15c8c4/attachment.html>

From dane.newman at gmail.com Mon Jan 14 15:47:04 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 15:47:04 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
Message-ID: <BEF7E91B-C188-4968-A4FF-DF445665CE58@gmail.com>

This is what the music sounds like

-------------- next part --------------


A non-text attachment was scrubbed...
Name: Video.MOV
Type: video/quicktime
Size: 1086147 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/b80834b0/attachment.mov>
-------------- next part --------------

Sent from my mobile device

On Jan 14, 2013, at 3:40 PM, Dane Newman <dane.newman at gmail.com> wrote:

> Hello
>
> I have an issue when users are connected to a call and hit the mobility soft key
button on 9971 phones when a call is active, the phone system rings on the mobile
number configured in the system. When they pick up the the mobile number it just
plays what sounds like hold music on both ends of the call (I believe this music is
coming from cucm but I haven't heard it before) instead of providing 2 way voice.
>
> In another senario with what I believe is the same issue. If a user picks up on
there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>
> My topology is as follows..
>
>
> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>
> Calls are sent back out the SIP trunk to the ITSP when using mobile connect/snr.
>
> Does anyone have any ideas how I can make 2 way voice happen instead of the hold
music when the calls are picked up?

From jbalbuena at desca.com Mon Jan 14 14:34:39 2013


From: jbalbuena at desca.com (Jose Balbuena)
Date: Mon, 14 Jan 2013 19:34:39 +0000
Subject: [cisco-voip] ERROR UPDATING LOCALE - CUCM 8.0
Message-ID: <6EDB87B1248B1B47AAD57EE99E053B48825A66DC@desca-mia-e10n2.desca.com>

Hello,

Someone can help me to figure out why some IP Phones 7911 & 7942 are not loading
correctly the file that permit the phone is in Spanish. For what I understand of
the next log extracted of a Phone (7942, Firmware: SCCP42.9-0-3S), is that the file
is well received but finally the phone does not execute correctly.

Any help, please!

3270: ERR 17:33:25.187583 JVM: tftpClient Spanish_Colombia/mk-sccp.jar


/usr/ram/L10N1063478883 550001 1
3271: NOT 17:33:25.191035 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = Spanish_Colombia/mk-sccp.jar, dstFile = /usr/ram/L10N1063478883 max size
= 550001
3272: NOT 17:33:25.193072 CDP-D: catchipcfg:getdhcpinfo IP:a224f23 domain:
chngVal:1
3273: NOT 17:33:25.193903 CDP-D: cdpGetPortCfg SPANTOPC CFG:11
3274: NOT 17:33:25.205494 tftpClient: auth server - tftpList[0] =
::ffff:10.33.168.250
3275: NOT 17:33:25.206047 tftpClient: look up server - 0
3276: NOT 17:33:25.207805 SECD: lookupCTL: TFTP SRVR secure
3277: NOT 17:33:25.210974 tftpClient: secVal = 0x9
3278: NOT 17:33:25.211628 tftpClient: ::ffff:10.33.168.250 is a secure server
3279: NOT 17:33:25.212120 tftpClient: retval = SRVR_SECURE
3280: NOT 17:33:25.212597 tftpClient: Secure file requested
3281: NOT 17:33:25.213060 tftpClient: authenticated file approved - add .sgn --
Spanish_Colombia/mk-sccp.jar.sgn
3282: ERR 17:33:25.240988 RTSOLD: opvvlan:594->594 advvlan:4095->4095 vvlanState=1
3283: NOT 17:33:25.249036 TFTP: [26]:Requesting Spanish_Colombia/mk-sccp.jar.sgn
from 10.33.168.250 with size limit of 550001

Best & Regards.

Rodrigo B.
CCNA VOICE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/0abb2bf9/attachment.html>
-------------- next part --------------
This message and any attachments are intended only for the use of the individual to
whom they are addressed and it may contain information that is privileged or
confidential. If you have received this communication by mistake, please notify us
immediately by e-mail or telephone.The storage, recording, use or disclosure of
this e-mail and its attachments by anyone other than the intended recipient is
strictly prohibited. This message has been verified using antivirus software;
however, the sender is not responsible for any damage to hardware or software
resulting from the presence of any virus.

Este mensaje y cualquier anexo son exclusivamente para la persona a quien van
dirigidos y pueden contener informaci?n privilegiada o confidencial. Si usted ha
recibido esta comunicaci?n por error, le agradecemos notificarlo de inmediato por
esta misma v?a o por tel?fono. Est? prohibida su retenci?n, grabaci?n, utilizaci?n
o divulgaci?n con cualquier prop?sito. Este mensaje ha sido verificado con software
antivirus; sin embargo, el remitente no se hace responsable en caso de que en ?ste
o en los archivos adjuntos haya presencia de alg?n virus que pueda generar da?os en
los equipos o programas del destinatario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/0abb2bf9/attachment-0001.html>

From kennethwhayes at gmail.com Mon Jan 14 16:11:52 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Mon, 14 Jan 2013 16:11:52 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
Message-ID: <-4286606911770185612@unknownmsgid>

What version of code are you running on the CUBE?

Sent from my iPhone

On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:

> Hello
>
> I have an issue when users are connected to a call and hit the mobility soft key
button on 9971 phones when a call is active, the phone system rings on the mobile
number configured in the system. When they pick up the the mobile number it just
plays what sounds like hold music on both ends of the call (I believe this music is
coming from cucm but I haven't heard it before) instead of providing 2 way voice.
>
> In another senario with what I believe is the same issue. If a user picks up on
there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>
> My topology is as follows..
>
>
> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>
> Calls are sent back out the SIP trunk to the ITSP when using mobile connect/snr.
>
> Does anyone have any ideas how I can make 2 way voice happen instead of the hold
music when the calls are picked up?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

From dane.newman at gmail.com Mon Jan 14 16:18:16 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 16:18:16 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <-4286606911770185612@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
Message-ID: <07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>

Using keyboard-interactive authentication.


Password:

Cisco3825#
Cisco3825#sh ver
Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
(4)M5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Tue 04-Sep-12 17:25 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)

Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes


System returned to ROM by power-on
System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
Last reload type: Normal Reload

This product contains cryptographic features and is subject to United


States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to


export at cisco.com.

Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.


Processor board ID FTX1237A1T0
2 Gigabit Ethernet interfaces
2 Channelized T1/PRI ports
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity enabled.
479K bytes of NVRAM.
500472K bytes of ATA System CompactFlash (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device# PID SN

Sent from my mobile device

On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
> What version of code are you running on the CUBE?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Hello
>>
>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>
>> In another senario with what I believe is the same issue. If a user picks up on
there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>
>> My topology is as follows..
>>
>>
>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>
>> Calls are sent back out the SIP trunk to the ITSP when using mobile connect/snr.
>>
>> Does anyone have any ideas how I can make 2 way voice happen instead of the hold
music when the calls are picked up?
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip

From rratliff at cisco.com Mon Jan 14 17:25:41 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 14 Jan 2013 17:25:41 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
Message-ID: <C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>

Do you get similar behavior if you just hold and resume the call outside SNR
features?

-Ryan

On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:

Using keyboard-interactive authentication.


Password:
Cisco3825#
Cisco3825#sh ver
Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
(4)M5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Tue 04-Sep-12 17:25 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)

Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes


System returned to ROM by power-on
System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
Last reload type: Normal Reload

This product contains cryptographic features and is subject to United


States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to


export at cisco.com.

Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.


Processor board ID FTX1237A1T0
2 Gigabit Ethernet interfaces
2 Channelized T1/PRI ports
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity enabled.
479K bytes of NVRAM.
500472K bytes of ATA System CompactFlash (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device# PID SN

Sent from my mobile device

On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:

> What version of code are you running on the CUBE?


>
> Sent from my iPhone
>
> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Hello
>>
>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>
>> In another senario with what I believe is the same issue. If a user picks up on
there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>
>> My topology is as follows..
>>
>>
>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>
>> Calls are sent back out the SIP trunk to the ITSP when using mobile connect/snr.
>>
>> Does anyone have any ideas how I can make 2 way voice happen instead of the hold
music when the calls are picked up?
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/300195a6/attachment.html>

From kennethwhayes at gmail.com Mon Jan 14 17:36:35 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Mon, 14 Jan 2013 17:36:35 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
Message-ID: <1397723124845575534@unknownmsgid>

What codec are you using?

Sent from my iPhone

On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:

> Using keyboard-interactive authentication.


> Password:
>
> Cisco3825#
> Cisco3825#sh ver
> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
> (4)M5, RELEASE SOFTWARE (fc1)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2012 by Cisco Systems, Inc.
> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>
> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>
> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
> System returned to ROM by power-on
> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
> Last reload type: Normal Reload
>
>
> This product contains cryptographic features and is subject to United
> States and local country laws governing import, export, transfer and
> use. Delivery of Cisco cryptographic products does not imply
> third-party authority to import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for
> compliance with U.S. and local country laws. By using this product you
> agree to comply with applicable laws and regulations. If you are unable
> to comply with U.S. and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be found at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> export at cisco.com.
>
> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
> Processor board ID FTX1237A1T0
> 2 Gigabit Ethernet interfaces
> 2 Channelized T1/PRI ports
> 1 Virtual Private Network (VPN) Module
> DRAM configuration is 64 bits wide with parity enabled.
> 479K bytes of NVRAM.
> 500472K bytes of ATA System CompactFlash (Read/Write)
>
>
> License Info:
>
> License UDI:
>
> -------------------------------------------------
> Device# PID SN
>
> Sent from my mobile device
>
> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>
>> What version of code are you running on the CUBE?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>>> Hello
>>>
>>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>
>>> In another senario with what I believe is the same issue. If a user picks up on
there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>>
>>> My topology is as follows..
>>>
>>>
>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>
>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>
>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip

From dane.newman at gmail.com Mon Jan 14 18:06:25 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 18:06:25 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
Message-ID: <CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>

Ryan (sorry I forgot to reply to all)

Thanks for the Reply


Oddly enough we are.
This probably has something to do with MOH in general?

Internally when I user puts another user on hold everything works. No MOH
plays and they can hold and unhold the call just fine.
I tested calling from an external number. Once I put the external caller on
hold the MOH played but I was unable to resume the call. When I hit resume
on the deskphone the MOH still played to the external caller and there was
no sound on the deskphone.
On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Do you get similar behavior if you just hold and resume the call outside
> SNR features?
>
> -Ryan
>
> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Using keyboard-interactive authentication.
>
> Password:
>
>
> Cisco3825#
>
> Cisco3825#sh ver
>
> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
> Version 15.1
> (4)M5, RELEASE SOFTWARE (fc1)
>
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>
> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>
>
> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>
>
> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>
> System returned to ROM by power-on
>
> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>
> Last reload type: Normal Reload
>
>
>
> This product contains cryptographic features and is subject to United
>
> States and local country laws governing import, export, transfer and
>
> use. Delivery of Cisco cryptographic products does not imply
>
> third-party authority to import, export, distribute or use encryption.
>
> Importers, exporters, distributors and users are responsible for
>
> compliance with U.S. and local country laws. By using this product you
>
> agree to comply with applicable laws and regulations. If you are unable
>
> to comply with U.S. and local laws, return this product immediately.
>
>
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
>
> export at cisco.com.
>
>
> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>
> Processor board ID FTX1237A1T0
>
> 2 Gigabit Ethernet interfaces
>
> 2 Channelized T1/PRI ports
>
> 1 Virtual Private Network (VPN) Module
>
> DRAM configuration is 64 bits wide with parity enabled.
>
> 479K bytes of NVRAM.
>
> 500472K bytes of ATA System CompactFlash (Read/Write)
>
>
>
> License Info:
>
>
> License UDI:
>
>
> -------------------------------------------------
>
> Device# PID SN
>
> Sent from my mobile device
>
> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
> wrote:
>
> What version of code are you running on the CUBE?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Hello
>
> I have an issue when users are connected to a call and hit the mobility
> soft key button on 9971 phones when a call is active, the phone system
> rings on the mobile number configured in the system. When they pick up the
> the mobile number it just plays what sounds like hold music on both ends of
> the call (I believe this music is coming from cucm but I haven't heard it
> before) instead of providing 2 way voice.
>
> In another senario with what I believe is the same issue. If a user picks
> up on there cell phone first (using single number reach) opposed to the
> deskphone the call is connected with 2 way voice and no issues exist. If
> the user then hangs up his cell phone with the intent to take the call on
> his deskphone the calling party starts hearing the hold music. Once the
> user picks up the call on his deskphone he hears nothing but the calling
> party is still hearing the hold music. It is not working as intended where
> 2 way voice happens once the user hangs up his mobile phone and picks up on
> his deskphone 2 way voice should happen.
>
> My topology is as follows..
>
>
> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>
> Calls are sent back out the SIP trunk to the ITSP when using mobile
> connect/snr.
>
> Does anyone have any ideas how I can make 2 way voice happen instead of
> the hold music when the calls are picked up?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/0e759021/attachment.html>

From kennethwhayes at gmail.com Mon Jan 14 18:09:07 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Mon, 14 Jan 2013 18:09:07 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
Message-ID: <-5635080451137355987@unknownmsgid>

Have you tried different audio codecs?

Sent from my iPhone

On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:

Ryan (sorry I forgot to reply to all)

Thanks for the Reply


Oddly enough we are.
This probably has something to do with MOH in general?
Internally when I user puts another user on hold everything works. No MOH
plays and they can hold and unhold the call just fine.
I tested calling from an external number. Once I put the external caller
on hold the MOH played but I was unable to resume the call. When I hit
resume on the deskphone the MOH still played to the external caller and
there was no sound on the deskphone.

On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Do you get similar behavior if you just hold and resume the call outside
> SNR features?
>
> -Ryan
>
> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Using keyboard-interactive authentication.
>
> Password:
>
>
> Cisco3825#
>
> Cisco3825#sh ver
>
> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
> Version 15.1
> (4)M5, RELEASE SOFTWARE (fc1)
>
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>
> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>
>
> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>
>
> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>
> System returned to ROM by power-on
>
> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>
> Last reload type: Normal Reload
>
>
>
> This product contains cryptographic features and is subject to United
>
> States and local country laws governing import, export, transfer and
>
> use. Delivery of Cisco cryptographic products does not imply
>
> third-party authority to import, export, distribute or use encryption.
>
> Importers, exporters, distributors and users are responsible for
>
> compliance with U.S. and local country laws. By using this product you
>
> agree to comply with applicable laws and regulations. If you are unable
>
> to comply with U.S. and local laws, return this product immediately.
>
>
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
>
> export at cisco.com.
>
>
> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>
> Processor board ID FTX1237A1T0
>
> 2 Gigabit Ethernet interfaces
>
> 2 Channelized T1/PRI ports
>
> 1 Virtual Private Network (VPN) Module
>
> DRAM configuration is 64 bits wide with parity enabled.
>
> 479K bytes of NVRAM.
>
> 500472K bytes of ATA System CompactFlash (Read/Write)
>
>
>
> License Info:
>
>
> License UDI:
>
>
> -------------------------------------------------
>
> Device# PID SN
>
> Sent from my mobile device
>
> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
> wrote:
>
> What version of code are you running on the CUBE?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Hello
>
> I have an issue when users are connected to a call and hit the mobility
> soft key button on 9971 phones when a call is active, the phone system
> rings on the mobile number configured in the system. When they pick up the
> the mobile number it just plays what sounds like hold music on both ends of
> the call (I believe this music is coming from cucm but I haven't heard it
> before) instead of providing 2 way voice.
>
> In another senario with what I believe is the same issue. If a user picks
> up on there cell phone first (using single number reach) opposed to the
> deskphone the call is connected with 2 way voice and no issues exist. If
> the user then hangs up his cell phone with the intent to take the call on
> his deskphone the calling party starts hearing the hold music. Once the
> user picks up the call on his deskphone he hears nothing but the calling
> party is still hearing the hold music. It is not working as intended where
> 2 way voice happens once the user hangs up his mobile phone and picks up on
> his deskphone 2 way voice should happen.
>
> My topology is as follows..
>
>
> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>
> Calls are sent back out the SIP trunk to the ITSP when using mobile
> connect/snr.
>
> Does anyone have any ideas how I can make 2 way voice happen instead of
> the hold music when the calls are picked up?
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/0da8b086/attachment.html>

From dane.newman at gmail.com Mon Jan 14 18:12:55 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 18:12:55 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <-5635080451137355987@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
Message-ID: <CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>

My ITSP will only support 711ulaw for me currently I believe. They hard
coded it with me when I was initially setting it up.

Do you think this could be a codec issue? How would I go about identifying
if it is?

Dane

On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Have you tried different audio codecs?


>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Ryan (sorry I forgot to reply to all)
>
> Thanks for the Reply
> Oddly enough we are.
> This probably has something to do with MOH in general?
>
> Internally when I user puts another user on hold everything works. No MOH
> plays and they can hold and unhold the call just fine.
> I tested calling from an external number. Once I put the external caller
> on hold the MOH played but I was unable to resume the call. When I hit
> resume on the deskphone the MOH still played to the external caller and
> there was no sound on the deskphone.
>
> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Do you get similar behavior if you just hold and resume the call outside
>> SNR features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>>
>> Password:
>>
>>
>> Cisco3825#
>>
>> Cisco3825#sh ver
>>
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>> Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>>
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>
>> System returned to ROM by power-on
>>
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>
>> Last reload type: Normal Reload
>>
>>
>>
>> This product contains cryptographic features and is subject to United
>>
>> States and local country laws governing import, export, transfer and
>>
>> use. Delivery of Cisco cryptographic products does not imply
>>
>> third-party authority to import, export, distribute or use encryption.
>>
>> Importers, exporters, distributors and users are responsible for
>>
>> compliance with U.S. and local country laws. By using this product you
>>
>> agree to comply with applicable laws and regulations. If you are unable
>>
>> to comply with U.S. and local laws, return this product immediately.
>>
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be
>> found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>>
>> export at cisco.com.
>>
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>
>> Processor board ID FTX1237A1T0
>>
>> 2 Gigabit Ethernet interfaces
>>
>> 2 Channelized T1/PRI ports
>>
>> 1 Virtual Private Network (VPN) Module
>>
>> DRAM configuration is 64 bits wide with parity enabled.
>>
>> 479K bytes of NVRAM.
>>
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>>
>> License Info:
>>
>>
>> License UDI:
>>
>>
>> -------------------------------------------------
>>
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>> wrote:
>>
>> What version of code are you running on the CUBE?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Hello
>>
>> I have an issue when users are connected to a call and hit the mobility
>> soft key button on 9971 phones when a call is active, the phone system
>> rings on the mobile number configured in the system. When they pick up the
>> the mobile number it just plays what sounds like hold music on both ends of
>> the call (I believe this music is coming from cucm but I haven't heard it
>> before) instead of providing 2 way voice.
>>
>> In another senario with what I believe is the same issue. If a user picks
>> up on there cell phone first (using single number reach) opposed to the
>> deskphone the call is connected with 2 way voice and no issues exist. If
>> the user then hangs up his cell phone with the intent to take the call on
>> his deskphone the calling party starts hearing the hold music. Once the
>> user picks up the call on his deskphone he hears nothing but the calling
>> party is still hearing the hold music. It is not working as intended where
>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>> his deskphone 2 way voice should happen.
>>
>> My topology is as follows..
>>
>>
>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>
>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>> connect/snr.
>>
>> Does anyone have any ideas how I can make 2 way voice happen instead of
>> the hold music when the calls are picked up?
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/b368ee1e/attachment.html>

From kennethwhayes at gmail.com Mon Jan 14 18:20:11 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Mon, 14 Jan 2013 18:20:11 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
Message-ID: <5095685926238469350@unknownmsgid>

Well have you tried debugging the codec to see if it has any errors!

Sent from my iPhone

On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

My ITSP will only support 711ulaw for me currently I believe. They hard
coded it with me when I was initially setting it up.

Do you think this could be a codec issue? How would I go about identifying
if it is?

Dane

On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Have you tried different audio codecs?


>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Ryan (sorry I forgot to reply to all)
>
> Thanks for the Reply
> Oddly enough we are.
> This probably has something to do with MOH in general?
>
> Internally when I user puts another user on hold everything works. No MOH
> plays and they can hold and unhold the call just fine.
> I tested calling from an external number. Once I put the external caller
> on hold the MOH played but I was unable to resume the call. When I hit
> resume on the deskphone the MOH still played to the external caller and
> there was no sound on the deskphone.
>
> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Do you get similar behavior if you just hold and resume the call outside
>> SNR features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>>
>> Password:
>>
>>
>> Cisco3825#
>>
>> Cisco3825#sh ver
>>
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>> Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>>
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>
>> System returned to ROM by power-on
>>
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>
>> Last reload type: Normal Reload
>>
>>
>>
>> This product contains cryptographic features and is subject to United
>>
>> States and local country laws governing import, export, transfer and
>>
>> use. Delivery of Cisco cryptographic products does not imply
>>
>> third-party authority to import, export, distribute or use encryption.
>>
>> Importers, exporters, distributors and users are responsible for
>>
>> compliance with U.S. and local country laws. By using this product you
>>
>> agree to comply with applicable laws and regulations. If you are unable
>>
>> to comply with U.S. and local laws, return this product immediately.
>>
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be
>> found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>>
>> export at cisco.com.
>>
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>
>> Processor board ID FTX1237A1T0
>>
>> 2 Gigabit Ethernet interfaces
>>
>> 2 Channelized T1/PRI ports
>>
>> 1 Virtual Private Network (VPN) Module
>>
>> DRAM configuration is 64 bits wide with parity enabled.
>>
>> 479K bytes of NVRAM.
>>
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>>
>> License Info:
>>
>>
>> License UDI:
>>
>>
>> -------------------------------------------------
>>
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>> wrote:
>>
>> What version of code are you running on the CUBE?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Hello
>>
>> I have an issue when users are connected to a call and hit the mobility
>> soft key button on 9971 phones when a call is active, the phone system
>> rings on the mobile number configured in the system. When they pick up the
>> the mobile number it just plays what sounds like hold music on both ends of
>> the call (I believe this music is coming from cucm but I haven't heard it
>> before) instead of providing 2 way voice.
>>
>> In another senario with what I believe is the same issue. If a user picks
>> up on there cell phone first (using single number reach) opposed to the
>> deskphone the call is connected with 2 way voice and no issues exist. If
>> the user then hangs up his cell phone with the intent to take the call on
>> his deskphone the calling party starts hearing the hold music. Once the
>> user picks up the call on his deskphone he hears nothing but the calling
>> party is still hearing the hold music. It is not working as intended where
>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>> his deskphone 2 way voice should happen.
>>
>> My topology is as follows..
>>
>>
>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>
>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>> connect/snr.
>>
>> Does anyone have any ideas how I can make 2 way voice happen instead of
>> the hold music when the calls are picked up?
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/3b4877c3/attachment.html>

From kennethwhayes at gmail.com Mon Jan 14 18:20:43 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Mon, 14 Jan 2013 18:20:43 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
Message-ID: <1680820783548761203@unknownmsgid>

Have you also restarted the Cisco IP Media Services?

Sent from my iPhone

On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

My ITSP will only support 711ulaw for me currently I believe. They hard
coded it with me when I was initially setting it up.

Do you think this could be a codec issue? How would I go about identifying
if it is?

Dane

On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Have you tried different audio codecs?


>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Ryan (sorry I forgot to reply to all)
>
> Thanks for the Reply
> Oddly enough we are.
> This probably has something to do with MOH in general?
>
> Internally when I user puts another user on hold everything works. No MOH
> plays and they can hold and unhold the call just fine.
> I tested calling from an external number. Once I put the external caller
> on hold the MOH played but I was unable to resume the call. When I hit
> resume on the deskphone the MOH still played to the external caller and
> there was no sound on the deskphone.
>
> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Do you get similar behavior if you just hold and resume the call outside
>> SNR features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>>
>> Password:
>>
>>
>> Cisco3825#
>>
>> Cisco3825#sh ver
>>
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>> Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>>
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>
>> System returned to ROM by power-on
>>
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>
>> Last reload type: Normal Reload
>>
>>
>>
>> This product contains cryptographic features and is subject to United
>>
>> States and local country laws governing import, export, transfer and
>>
>> use. Delivery of Cisco cryptographic products does not imply
>>
>> third-party authority to import, export, distribute or use encryption.
>>
>> Importers, exporters, distributors and users are responsible for
>>
>> compliance with U.S. and local country laws. By using this product you
>>
>> agree to comply with applicable laws and regulations. If you are unable
>>
>> to comply with U.S. and local laws, return this product immediately.
>>
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be
>> found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>>
>> export at cisco.com.
>>
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>
>> Processor board ID FTX1237A1T0
>>
>> 2 Gigabit Ethernet interfaces
>>
>> 2 Channelized T1/PRI ports
>>
>> 1 Virtual Private Network (VPN) Module
>>
>> DRAM configuration is 64 bits wide with parity enabled.
>>
>> 479K bytes of NVRAM.
>>
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>>
>> License Info:
>>
>>
>> License UDI:
>>
>>
>> -------------------------------------------------
>>
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>> wrote:
>>
>> What version of code are you running on the CUBE?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Hello
>>
>> I have an issue when users are connected to a call and hit the mobility
>> soft key button on 9971 phones when a call is active, the phone system
>> rings on the mobile number configured in the system. When they pick up the
>> the mobile number it just plays what sounds like hold music on both ends of
>> the call (I believe this music is coming from cucm but I haven't heard it
>> before) instead of providing 2 way voice.
>>
>> In another senario with what I believe is the same issue. If a user picks
>> up on there cell phone first (using single number reach) opposed to the
>> deskphone the call is connected with 2 way voice and no issues exist. If
>> the user then hangs up his cell phone with the intent to take the call on
>> his deskphone the calling party starts hearing the hold music. Once the
>> user picks up the call on his deskphone he hears nothing but the calling
>> party is still hearing the hold music. It is not working as intended where
>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>> his deskphone 2 way voice should happen.
>>
>> My topology is as follows..
>>
>>
>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>
>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>> connect/snr.
>>
>> Does anyone have any ideas how I can make 2 way voice happen instead of
>> the hold music when the calls are picked up?
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/0eda0204/attachment.html>

From dane.newman at gmail.com Mon Jan 14 18:40:30 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Mon, 14 Jan 2013 18:40:30 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <1680820783548761203@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
Message-ID: <CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>

*Hello Kenneth*
**
*I have restarted both CUCM servers so this should have restarted the
services when the utils system restart happened*
**

*on my router I see I am using g711 from the debug *


**
*I ran a debug voip ccapi inout *
**
*I connected a call calling from an external number to a DiD inside of my
system. Once the call was connected I put the call on hold and the
following debug came out..the music on hold played for the external caller*

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783:
//12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839:
//12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

*I then after that took off the hold and the following debug came out. The
call on the PSDN side still played the hold music while there was no voice
on the deskphone side.*

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783:
//12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839:
//12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Have you also restarted the Cisco IP Media Services?


>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> My ITSP will only support 711ulaw for me currently I believe. They hard
> coded it with me when I was initially setting it up.
>
> Do you think this could be a codec issue? How would I go about
> identifying if it is?
>
> Dane
>
> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>
>> Have you tried different audio codecs?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Ryan (sorry I forgot to reply to all)
>>
>> Thanks for the Reply
>> Oddly enough we are.
>> This probably has something to do with MOH in general?
>>
>> Internally when I user puts another user on hold everything works. No MOH
>> plays and they can hold and unhold the call just fine.
>> I tested calling from an external number. Once I put the external
>> caller on hold the MOH played but I was unable to resume the call. When I
>> hit resume on the deskphone the MOH still played to the external caller and
>> there was no sound on the deskphone.
>>
>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> Do you get similar behavior if you just hold and resume the call outside
>>> SNR features?
>>>
>>> -Ryan
>>>
>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Using keyboard-interactive authentication.
>>>
>>> Password:
>>>
>>>
>>> Cisco3825#
>>>
>>> Cisco3825#sh ver
>>>
>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>> Version 15.1
>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>
>>> Technical Support: http://www.cisco.com/techsupport
>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>
>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>
>>>
>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>
>>>
>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>
>>> System returned to ROM by power-on
>>>
>>> System image file is
>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>> Last reload type: Normal Reload
>>>
>>>
>>>
>>> This product contains cryptographic features and is subject to United
>>>
>>> States and local country laws governing import, export, transfer and
>>>
>>> use. Delivery of Cisco cryptographic products does not imply
>>>
>>> third-party authority to import, export, distribute or use encryption.
>>>
>>> Importers, exporters, distributors and users are responsible for
>>>
>>> compliance with U.S. and local country laws. By using this product you
>>>
>>> agree to comply with applicable laws and regulations. If you are unable
>>>
>>> to comply with U.S. and local laws, return this product immediately.
>>>
>>>
>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>> found at:
>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>
>>> If you require further assistance please contact us by sending email to
>>>
>>> export at cisco.com.
>>>
>>>
>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>
>>> Processor board ID FTX1237A1T0
>>>
>>> 2 Gigabit Ethernet interfaces
>>>
>>> 2 Channelized T1/PRI ports
>>>
>>> 1 Virtual Private Network (VPN) Module
>>>
>>> DRAM configuration is 64 bits wide with parity enabled.
>>>
>>> 479K bytes of NVRAM.
>>>
>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>
>>>
>>>
>>> License Info:
>>>
>>>
>>> License UDI:
>>>
>>>
>>> -------------------------------------------------
>>>
>>> Device# PID SN
>>>
>>> Sent from my mobile device
>>>
>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>> wrote:
>>>
>>> What version of code are you running on the CUBE?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Hello
>>>
>>> I have an issue when users are connected to a call and hit the mobility
>>> soft key button on 9971 phones when a call is active, the phone system
>>> rings on the mobile number configured in the system. When they pick up the
>>> the mobile number it just plays what sounds like hold music on both ends of
>>> the call (I believe this music is coming from cucm but I haven't heard it
>>> before) instead of providing 2 way voice.
>>>
>>> In another senario with what I believe is the same issue. If a user
>>> picks up on there cell phone first (using single number reach) opposed to
>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>> If the user then hangs up his cell phone with the intent to take the call
>>> on his deskphone the calling party starts hearing the hold music. Once the
>>> user picks up the call on his deskphone he hears nothing but the calling
>>> party is still hearing the hold music. It is not working as intended where
>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>> his deskphone 2 way voice should happen.
>>>
>>> My topology is as follows..
>>>
>>>
>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>
>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>> connect/snr.
>>>
>>> Does anyone have any ideas how I can make 2 way voice happen instead of
>>> the hold music when the calls are picked up?
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/5ff73dd7/attachment.html>

From svoll.voip at gmail.com Mon Jan 14 18:45:41 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Mon, 14 Jan 2013 15:45:41 -0800
Subject: [cisco-voip] 2960s-48fps-l flex stack
Message-ID: <CAHgd+3_H1PcGKB06TWvwZOkDMFm7736Tfw2Od0Pb8tPSB3Mr7g@mail.gmail.com>

I have a 2960s-48fps-l and when I inserted the flex stack module I get:

%PLATFORM-6-FLEXSTACK_UNSUPPORTED_MODULE: Unsupported FlexStack module


inserted in Switch 1. C2960S-F-STACK
Is this not supported? I'm running 15.0.2se1. How do I get it talking to
the other switches?

TIA

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/4e227560/attachment.html>

From joshua.morgan at gmail.com Mon Jan 14 19:00:12 2013


From: joshua.morgan at gmail.com (Joshua Morgan)
Date: Tue, 15 Jan 2013 11:00:12 +1100
Subject: [cisco-voip] 2960s-48fps-l flex stack
In-Reply-To: <CAHgd+3_H1PcGKB06TWvwZOkDMFm7736Tfw2Od0Pb8tPSB3Mr7g@mail.gmail.com>
References: <CAHgd+3_H1PcGKB06TWvwZOkDMFm7736Tfw2Od0Pb8tPSB3Mr7g@mail.gmail.com>
Message-ID: <CAP-90TnrJqcQcdSj4TgqS-YV2bSmf39OGPQiwgVgB60mgaRVhA@mail.gmail.com>

That module may only be for 2960SF series switches (FastEthernet version).

On Tue, Jan 15, 2013 at 10:45 AM, Scott Voll <svoll.voip at gmail.com> wrote:

> I have a 2960s-48fps-l and when I inserted the flex stack module I get:
>
> %PLATFORM-6-FLEXSTACK_UNSUPPORTED_MODULE: Unsupported FlexStack module
> inserted in Switch 1. C2960S-F-STACK
>
> Is this not supported? I'm running 15.0.2se1. How do I get it talking to
> the other switches?
>
> TIA
>
> Scott
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/a33dec56/attachment.html>

From mikeeo at msn.com Mon Jan 14 21:01:21 2013


From: mikeeo at msn.com (Mike )
Date: Mon, 14 Jan 2013 21:01:21 -0500
Subject: [cisco-voip] Design question CTI or DN?
Message-ID: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>

I have about 1500 voice mail only users that I have in Unity connections and
I was wondering that the best way to get their DIDs into unity cx. I was
thinking I can create CTI ports send them all to voicemail. The problem is
the customer owns the whole block 0000-9999 and the DIDs are all over the
place or I'd create a wild card hunt pilot.
Any ideas?

Thanks,

Mike

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/6b72474d/attachment.html>

From VanMarenNP at ldschurch.org Mon Jan 14 22:19:28 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Tue, 15 Jan 2013 03:19:28 +0000
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>

What needs to happen to an assigned DIDs? If it's ok for them to go to a call


handler, then just have a wildcard for the whole block that sends anything un
assigned to Unity, then it will match their mailbox if it can or they can go to a
callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with AXL or
BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and I was
wondering that the best way to get their DIDs into unity cx. I was thinking I can
create CTI ports send them all to voicemail. The problem is the customer owns the
whole block 0000-9999 and the DIDs are all over the place or I'd create a wild card
hunt pilot.

Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/c6d379f2/attachment.html>

From mikeeo at msn.com Mon Jan 14 22:24:38 2013


From: mikeeo at msn.com (Mike )
Date: Mon, 14 Jan 2013 22:24:38 -0500
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
Message-ID: <BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get
ugly. Its weird they don't want to use SNR they just want the call to go to
voicemail. I don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a


call handler, then just have a wildcard for the whole block that sends
anything un assigned to Unity, then it will match their mailbox if it can or
they can go to a callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with
AXL or BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and
I was wondering that the best way to get their DIDs into unity cx. I was
thinking I can create CTI ports send them all to voicemail. The problem is
the customer owns the whole block 0000-9999 and the DIDs are all over the
place or I'd create a wild card hunt pilot.
Any ideas?

Thanks,

Mike

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/fc8f8f94/attachment.html>

From VanMarenNP at ldschurch.org Mon Jan 14 22:26:34 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Tue, 15 Jan 2013 03:26:34 +0000
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>

You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get ugly.
Its weird they don't want to use SNR they just want the call to go to voicemail. I
don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate
VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a call


handler, then just have a wildcard for the whole block that sends anything un
assigned to Unity, then it will match their mailbox if it can or they can go to a
callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with AXL or
BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and I was
wondering that the best way to get their DIDs into unity cx. I was thinking I can
create CTI ports send them all to voicemail. The problem is the customer owns the
whole block 0000-9999 and the DIDs are all over the place or I'd create a wild card
hunt pilot.

Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/8a7c8b0c/attachment.html>

From jonvoip at gmail.com Mon Jan 14 22:28:54 2013


From: jonvoip at gmail.com (Jonathan Charles)
Date: Mon, 14 Jan 2013 21:28:54 -0600
Subject: [cisco-voip] Can't download List.xml via TFTP... file not found...
Message-ID: <CAPLPVZip4H=A2v8u16F71TnfMS32CZgKe-4WWuJMRhMpcK7JYw@mail.gmail.com>

Trying to deploy images to 7970/71, 7975 and 7965s...

Cisco 7970/71s work fine, 7975s and 65s fail... with a File Not Found,
confirmed repeatedly that the file is there; logs show file being there,
but no signed:

1209: NOT 19:25:02.412509 tftpClient: tftp request rcv'd from


/usr/tmp/tftp, srcFile = Desktops/320x212x16/Large.png, dstFile =
/flash0/F-1580749268 max size = 550001
1210: NOT 19:25:02.430896 tftpClient: auth server - tftpList[0] =
::ffff:172.20.1.100
1211: NOT 19:25:02.431523 tftpClient: look up server - 0
1212: NOT 19:25:02.433489 SECD: lookupCTL: TFTP SRVR secure
1213: NOT 19:25:02.436291 tftpClient: secVal = 0x9
1214: NOT 19:25:02.437012 tftpClient: ::ffff:172.20.1.100 is a secure server
1215: NOT 19:25:02.437538 tftpClient: retval = SRVR_SECURE
1216: NOT 19:25:02.438074 tftpClient: Secure file requested
1217: NOT 19:25:02.438619 tftpClient: authenticated file approved -
add .sgn -- Desktops/320x212x16/HLarge.png.sgn
1218: NOT 19:25:02.470339 TFTP: [18]:Requesting
Desktops/320x212x16/HTALarge.png.sgn from 172.20.1.100 with size limit
of 550001
1219: NOT 19:25:02.585485 TFTP: [18]:Error --> File not found
1220: NOT 19:25:02.593573 SYSMSG: pid 18 (/sbin/tftpd) Normal Exit, status = 2
1221: INF 19:25:02.593616 runtime = 0.150 secs

Looks like it finds the file, wants a signed one, appears to convert
it, then fails to find it.

How do I generate the secure file?

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/6407435b/attachment.html>

From mikeeo at msn.com Mon Jan 14 22:30:15 2013


From: mikeeo at msn.com (Mike )
Date: Mon, 14 Jan 2013 22:30:15 -0500
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
Message-ID: <BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>

True, but I never seen a way to BAT in DNs.

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:27 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

You don't need DNs on a device anymore for them to be active. They just
need to be marked as "active"
From: Mike [mailto:mikeeo at msn.com]
Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get
ugly. Its weird they don't want to use SNR they just want the call to go to
voicemail. I don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a


call handler, then just have a wildcard for the whole block that sends
anything un assigned to Unity, then it will match their mailbox if it can or
they can go to a callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with
AXL or BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and
I was wondering that the best way to get their DIDs into unity cx. I was
thinking I can create CTI ports send them all to voicemail. The problem is
the customer owns the whole block 0000-9999 and the DIDs are all over the
place or I'd create a wild card hunt pilot.

Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/d2cdae74/attachment.html>

From VanMarenNP at ldschurch.org Mon Jan 14 22:35:17 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Tue, 15 Jan 2013 03:35:17 +0000
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
<BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E756D6@W12112.ldschurch.org>

Ah, my new best friend is import/export.

It's really just a CSV that does anything.

I haven't done it with DNs, but I just imported all of the permutations of phone
button templates in a few seconds.

Export something, look at the CSV in the TAR, edit it to what you want, and load it
back in.

Thanks,
-Nate

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:30 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

True, but I never seen a way to BAT in DNs.


From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]
Sent: Monday, January 14, 2013 10:27 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get ugly.
Its weird they don't want to use SNR they just want the call to go to voicemail. I
don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate
VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a call


handler, then just have a wildcard for the whole block that sends anything un
assigned to Unity, then it will match their mailbox if it can or they can go to a
callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with AXL or
BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and I was
wondering that the best way to get their DIDs into unity cx. I was thinking I can
create CTI ports send them all to voicemail. The problem is the customer owns the
whole block 0000-9999 and the DIDs are all over the place or I'd create a wild card
hunt pilot.

Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/8f6dbd09/attachment.html>

From mikeeo at msn.com Mon Jan 14 22:38:50 2013


From: mikeeo at msn.com (Mike )
Date: Mon, 14 Jan 2013 22:38:50 -0500
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E756D6@W12112.ldschurch.org>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
<BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E756D6@W12112.ldschurch.org>
Message-ID: <BLU0-SMTP366CE9668B959DD8AD94713C52D0@phx.gbl>

I'll give it a shot thanks!

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:35 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

Ah, my new best friend is import/export.

It's really just a CSV that does anything.

I haven't done it with DNs, but I just imported all of the permutations of
phone button templates in a few seconds.

Export something, look at the CSV in the TAR, edit it to what you want, and
load it back in.
Thanks,

-Nate

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:30 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

True, but I never seen a way to BAT in DNs.

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:27 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

You don't need DNs on a device anymore for them to be active. They just
need to be marked as "active"

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get
ugly. Its weird they don't want to use SNR they just want the call to go to
voicemail. I don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a


call handler, then just have a wildcard for the whole block that sends
anything un assigned to Unity, then it will match their mailbox if it can or
they can go to a callhandler.
Or build DNs for each number, not a ton of fun but can be made easier with
AXL or BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and
I was wondering that the best way to get their DIDs into unity cx. I was
thinking I can create CTI ports send them all to voicemail. The problem is
the customer owns the whole block 0000-9999 and the DIDs are all over the
place or I'd create a wild card hunt pilot.

Any ideas?

Thanks,

Mike

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/4f1a9738/attachment.html>

From John.VanLaecke at ghd.com Tue Jan 15 00:36:26 2013


From: John.VanLaecke at ghd.com (John Van Laecke)
Date: Tue, 15 Jan 2013 05:36:26 +0000
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <BLU0-SMTP366CE9668B959DD8AD94713C52D0@phx.gbl>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
<BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E756D6@W12112.ldschurch.org>
<BLU0-SMTP366CE9668B959DD8AD94713C52D0@phx.gbl>
Message-ID: <CF2E16827204E249BB155D2C1F5C1EAB1ABAB413@GLB-EXMBX-
001.ghdnet.internal>

In call manager you can make bulk dn's.

Goto
call routing
Directory number
Add new
And you can add a range in and create the call forwards.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Mike
Sent: Tuesday, 15 January 2013 1:39 PM
To: 'Nate VanMaren'; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

I'll give it a shot thanks!

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:35 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

Ah, my new best friend is import/export.

It's really just a CSV that does anything.

I haven't done it with DNs, but I just imported all of the permutations of phone
button templates in a few seconds.

Export something, look at the CSV in the TAR, edit it to what you want, and load it
back in.

Thanks,
-Nate

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:30 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

True, but I never seen a way to BAT in DNs.

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:27 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get ugly.
Its weird they don't want to use SNR they just want the call to go to voicemail. I
don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate
VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a call


handler, then just have a wildcard for the whole block that sends anything un
assigned to Unity, then it will match their mailbox if it can or they can go to a
callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with AXL or
BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and I was
wondering that the best way to get their DIDs into unity cx. I was thinking I can
create CTI ports send them all to voicemail. The problem is the customer owns the
whole block 0000-9999 and the DIDs are all over the place or I'd create a wild card
hunt pilot.
Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/41037423/attachment.html>

From ahmed_elnagar at hotmail.com Tue Jan 15 01:39:59 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Tue, 15 Jan 2013 08:39:59 +0200
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E71556@W12112.ldschurch.org>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
<2F143E71016CA34C924BF4C33AEF211056E71556@W12112.ldschurch.org>
Message-ID: <BAY149-ds10D2ABFE4E797176881759872D0@phx.gbl>

I usually make a cluster reboot for CUCM or unity connection before I


upgrade.
Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 6:33 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

How long had the server been up before the you started the first upgrade?

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Monday, January 14, 2013 9:27 AM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

So I figured I'd loop around and let everyone know how things ended up.

Unity Connection never finished the first attempt and wouldn't cancel
either. I had to force a shutdown. After it came back up I tried again. 90
minutes boom. Suffice it to say. I wish had done that sooner.

Matthew G. Loraditch - CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

<http://twitter.com/heliontech> Twitter |
<http://www.facebook.com/#!/pages/Helion/252157915296> Facebook |
<http://www.heliontechnologies.com/> Website |
<mailto:support at heliontechnologies.com?subject=Technical%20Support%20Request
> Email Support

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change.
the unity connection pub is still running, I think we are on hour 15 of
that.

Matthew G. Loraditch - CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

<http://twitter.com/heliontech> Twitter |
<http://www.facebook.com/#!/pages/Helion/252157915296> Facebook |
<http://www.heliontechnologies.com/> Website |
<mailto:support at heliontechnologies.com?subject=Technical%20Support%20Request
> Email Support

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 9.1 Upgrade Times

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

<http://twitter.com/heliontech> Twitter |
<http://www.facebook.com/#!/pages/Helion/252157915296> Facebook |
<http://www.heliontechnologies.com/> Website |
<mailto:support at heliontechnologies.com?subject=Technical%20Support%20Request
> Email Support

NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ce740226/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ce740226/attachment.jpg>

From jbuchanan at presidio.com Tue Jan 15 02:24:54 2013


From: jbuchanan at presidio.com (Buchanan, James)
Date: Tue, 15 Jan 2013 07:24:54 +0000
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <BAY149-ds10D2ABFE4E797176881759872D0@phx.gbl>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
<2F143E71016CA34C924BF4C33AEF211056E71556@W12112.ldschurch.org>
<BAY149-ds10D2ABFE4E797176881759872D0@phx.gbl>
Message-ID: <12D6A6A157B44348974E5ED93738628C25369417@HQEXCHMBX03.Presidio.Corp>

Cleaning out log files and CDRs might also be a good idea.

James Buchanan | Sr. Network Engineer


Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at
presidio.com<mailto:jbuchanan at presidio.com>

[Be Secure In The Knowledge]<http://www.presidio.com>

Follow us:

[Follow Presidio on Twitter]<http://www.twitter.com/presidio>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Tuesday, January 15, 2013 8:40 AM
To: 'Nate VanMaren'; 'Matthew Loraditch'; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

I usually make a cluster reboot for CUCM or unity connection before I upgrade.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
[Description: Description: Description: MS Green]

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 6:33 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Subject: Re: [cisco-voip] 9.1 Upgrade Times

How long had the server been up before the you started the first upgrade?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Matthew Loraditch
Sent: Monday, January 14, 2013 9:27 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] 9.1 Upgrade Times

So I figured I?d loop around and let everyone know how things ended up.
Unity Connection never finished the first attempt and wouldn?t cancel either. I had
to force a shutdown. After it came back up I tried again? 90 minutes boom. Suffice
it to say. I wish had done that sooner.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change? the
unity connection pub is still running, I think we are on hour 15 of that?

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of
Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] 9.1 Upgrade Times

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>
NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

This message w/attachments (message) is intended solely for the use of the intended
recipient(s) and may contain information that is privileged, confidential or
proprietary. If you are not an intended recipient, please notify the sender, and
then please delete and destroy all copies and attachments. Please be advised that
any review or dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/e8ae516d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/e8ae516d/attachment.jpg>

From A.L.M.Buxey at lboro.ac.uk Tue Jan 15 02:35:12 2013


From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Tue, 15 Jan 2013 07:35:12 +0000
Subject: [cisco-voip] 2960s-48fps-l flex stack
Message-ID: <A5BBBF24-B07B-4BAD-8C37-FF571A201638@lboro.ac.uk>

I've seen this on ios 15 with flexstack modules. Have you tried removing the module
and re-inserting, or a power cycle with the module installed?

alan

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/15ae771f/attachment.html>

From jbuchanan at presidio.com Tue Jan 15 08:58:54 2013


From: jbuchanan at presidio.com (Buchanan, James)
Date: Tue, 15 Jan 2013 13:58:54 +0000
Subject: [cisco-voip] 2960s-48fps-l flex stack
In-Reply-To: <A5BBBF24-B07B-4BAD-8C37-FF571A201638@lboro.ac.uk>
References: <A5BBBF24-B07B-4BAD-8C37-FF571A201638@lboro.ac.uk>
Message-ID: <12D6A6A157B44348974E5ED93738628C25369491@HQEXCHMBX03.Presidio.Corp>

What is the IOS being run? Is it IP Base? I don?t think anything lower will run the
stacking module.

James Buchanan | Sr. Network Engineer


Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at
presidio.com<mailto:jbuchanan at presidio.com>

[Be Secure In The Knowledge]<http://www.presidio.com>

Follow us:

[Follow Presidio on Twitter]<http://www.twitter.com/presidio>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Alan Buxey
Sent: Tuesday, January 15, 2013 9:35 AM
To: svoll.voip at gmail.com; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 2960s-48fps-l flex stack

I've seen this on ios 15 with flexstack modules. Have you tried removing the module
and re-inserting, or a power cycle with the module installed?

alan

This message w/attachments (message) is intended solely for the use of the intended
recipient(s) and may contain information that is privileged, confidential or
proprietary. If you are not an intended recipient, please notify the sender, and
then please delete and destroy all copies and attachments. Please be advised that
any review or dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/43a2c3bc/attachment.html>

From rratliff at cisco.com Tue Jan 15 09:42:37 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 15 Jan 2013 09:42:37 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
Message-ID: <F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>

Given you have an ITSP it's most likely the initial hold that's failing, which is
only manifesting when you try to resume it. If you haven't noticed already this
is also very likely causing transfers to fail.

Take a look at the SIP signaling for a call. I believe the most common cause to
this is the ITSP not handling our transition from active->inactive->sendonly-
>active from hold to MOH to resume. The "Duplex Streaming Enabled" parameter is
there just for this type of problem.

-Ryan

On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:

Hello Kenneth

I have restarted both CUCM servers so this should have restarted the services when
the utils system restart happened

on my router I see I am using g711 from the debug

I ran a debug voip ccapi inout

I connected a call calling from an external number to a DiD inside of my system.


Once the call was connected I put the call on hold and the following debug came
out..the music on hold played for the external caller

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

I then after that took off the hold and the following debug came out. The call on
the PSDN side still played the hold music while there was no voice on the deskphone
side.

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
Have you also restarted the Cisco IP Media Services?

Sent from my iPhone

On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

> My ITSP will only support 711ulaw for me currently I believe. They hard coded it
with me when I was initially setting it up.
>
> Do you think this could be a codec issue? How would I go about identifying if it
is?
>
> Dane
>
> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
> Have you tried different audio codecs?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Ryan (sorry I forgot to reply to all)
>>
>> Thanks for the Reply
>> Oddly enough we are.
>> This probably has something to do with MOH in general?
>>
>> Internally when I user puts another user on hold everything works. No MOH plays
and they can hold and unhold the call just fine.
>> I tested calling from an external number. Once I put the external caller on hold
the MOH played but I was unable to resume the call. When I hit resume on the
deskphone the MOH still played to the external caller and there was no sound on the
deskphone.
>>
>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>> Do you get similar behavior if you just hold and resume the call outside SNR
features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>> Password:
>>
>> Cisco3825#
>> Cisco3825#sh ver
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>> System returned to ROM by power-on
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>> Last reload type: Normal Reload
>>
>>
>> This product contains cryptographic features and is subject to United
>> States and local country laws governing import, export, transfer and
>> use. Delivery of Cisco cryptographic products does not imply
>> third-party authority to import, export, distribute or use encryption.
>> Importers, exporters, distributors and users are responsible for
>> compliance with U.S. and local country laws. By using this product you
>> agree to comply with applicable laws and regulations. If you are unable
>> to comply with U.S. and local laws, return this product immediately.
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>> export at cisco.com.
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>> Processor board ID FTX1237A1T0
>> 2 Gigabit Ethernet interfaces
>> 2 Channelized T1/PRI ports
>> 1 Virtual Private Network (VPN) Module
>> DRAM configuration is 64 bits wide with parity enabled.
>> 479K bytes of NVRAM.
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>> License Info:
>>
>> License UDI:
>>
>> -------------------------------------------------
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>
>>> What version of code are you running on the CUBE?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>>> Hello
>>>>
>>>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>>
>>>> In another senario with what I believe is the same issue. If a user picks up
on there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>>>
>>>> My topology is as follows..
>>>>
>>>>
>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>
>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>>
>>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/106bcbcf/attachment.html>
From rratliff at cisco.com Tue Jan 15 09:51:04 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 15 Jan 2013 09:51:04 -0500
Subject: [cisco-voip] 9.1 Upgrade Times
In-Reply-To: <12D6A6A157B44348974E5ED93738628C25369417@HQEXCHMBX03.Presidio.Corp>
References: <C75AF2AD9308C246AFBDDB994E3E2983110B24E7@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B2E69@PHANES.helion.local>
<C75AF2AD9308C246AFBDDB994E3E2983110B5E52@PHANES.helion.local>
<2F143E71016CA34C924BF4C33AEF211056E71556@W12112.ldschurch.org>
<BAY149-ds10D2ABFE4E797176881759872D0@phx.gbl>
<12D6A6A157B44348974E5ED93738628C25369417@HQEXCHMBX03.Presidio.Corp>
Message-ID: <A7C3FDE4-31FF-40F1-80B3-128AF17039D6@cisco.com>

Also take a look at disk space so you don't run out during the upgrade.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/9_1_1/CUCM_BK_R6F8DBD4
_00_release-notes-for-cucm-91_chapter_011.html#CUCM_RF_C4B0C2D8_00

-Ryan

On Jan 15, 2013, at 2:24 AM, "Buchanan, James" <jbuchanan at presidio.com> wrote:

Cleaning out log files and CDRs might also be a good idea.

James Buchanan | Sr. Network Engineer


Presidio | www.presidio.com
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at presidio.com

Follow us:

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Tuesday, January 15, 2013 8:40 AM
To: 'Nate VanMaren'; 'Matthew Loraditch'; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

I usually make a cluster reboot for CUCM or unity connection before I upgrade.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 6:33 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

How long had the server been up before the you started the first upgrade?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Monday, January 14, 2013 9:27 AM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 9.1 Upgrade Times

So I figured I?d loop around and let everyone know how things ended up.
Unity Connection never finished the first attempt and wouldn?t cancel either. I had
to force a shutdown. After it came back up I tried again? 90 minutes boom. Suffice
it to say. I wish had done that sooner.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: Matthew Loraditch


Sent: Sunday, January 13, 2013 3:06 PM
To: Matthew Loraditch; cisco-voip at puck.nether.net
Subject: RE: 9.1 Upgrade Times

Well my CUCM publisher took almost 13 hours, my sub took 1 hour and change? the
unity connection pub is still running, I think we are on hour 15 of that?

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Sunday, January 13, 2013 8:58 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] 9.1 Upgrade Times

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 | Facebook | Website | Email Support

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

This message w/attachments (message) is intended solely for the use of the intended
recipient(s) and may contain information that is privileged, confidential or
proprietary. If you are not an intended recipient, please notify the sender, and
then please delete and destroy all copies and attachments. Please be advised that
any review or dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ce3cf423/attachment.html>

From avholloway+cisco-voip at gmail.com Tue Jan 15 11:08:14 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Tue, 15 Jan 2013 10:08:14 -0600
Subject: [cisco-voip] CUCM MTP and g729
In-Reply-To: <188F72A9-D5A4-448A-A2CE-059A5942833A@gmail.com>
References: <CACRCJOi5SVz2He4nuzDHX-xS7SFGphgbww-PxqacCTo9sPm__A@mail.gmail.com>
<3440C2FC-FC42-4B2D-B4EB-2F76B76BC6F7@cisco.com>
<CACRCJOguqqYfJrY38mSG47qgmnkz=RYReZdLA2rTdpPYpuSz0A@mail.gmail.com>
<CAMa5Jw7OZ1-cQOo3KVdx56A9FdTDmOqVK9rzxy5+CHr8v8dQ9Q@mail.gmail.com>
<CACRCJOiRpHqNMHLNYgLEvTtKUunie7Y82HKvFfUW1zCbU-6c5g@mail.gmail.com>
<A287F450-2809-4BE6-A3D1-9584CC120CE1@cisco.com>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C718859@USISPCLEXDB01.na.didata.local>
<188F72A9-D5A4-448A-A2CE-059A5942833A@gmail.com>
Message-ID: <CACRCJOgsQ82pJf7HaP30XPFJ8xK0YjuqQci4vsNQL-wpws_hzg@mail.gmail.com>

Here is the trace from the MTP registering, showing that it supports
pass-through:

10:49:20.397 |StationInit: (0000001) CapabilitiesRes capCount=6 *caps=


258(0)*
...
10:49:20.397
|MediaTerminationPointControl(1)::wait_capabilities_StationCapRes - Device
= SUB02B_MTP - *Pass-Through Supported = 1*|[redacted]

Looks like it's the 258 you and Ryan spoke of. Mystery solved! Thanks to
all who provided input.

On Sat, Jan 12, 2013 at 3:43 PM, Peter Slow <peter.slow at gmail.com> wrote:

> 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)" <
> jason.aarons at dimensiondata.com> 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:* cisco-voip-bounces at puck.nether.net [
> mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at
puck.nether.net>]
> *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 <
> avholloway+cisco-voip at gmail.com> 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 <peter.slow at gmail.com> 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
> <avholloway+cisco-voip at gmail.com> 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 <wsisk at cisco.com> 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
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
>
>
> itevomcid ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/b7c28c69/attachment.html>

From tednugent73 at gmail.com Tue Jan 15 11:19:14 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Tue, 15 Jan 2013 11:19:14 -0500
Subject: [cisco-voip] Gathering Licenses from CUCM?
Message-ID: <CAHs2VYsenEWypHOWa7BRbcTwLvxRPGshzMv49_QqOd2xCsr-Ng@mail.gmail.com>

I'm attempting to gather ~50 individual license files from a CUCM 7.1
server to zip them up and send to licensing.... Is there anyway to pull
them off the server without having to copy/paste into the individual
files...?

TIA
T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/75a24234/attachment.html>
From VanMarenNP at ldschurch.org Tue Jan 15 10:23:27 2013
From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Tue, 15 Jan 2013 15:23:27 +0000
Subject: [cisco-voip] Design question CTI or DN?
In-Reply-To: <CF2E16827204E249BB155D2C1F5C1EAB1ABAB413@GLB-EXMBX-
001.ghdnet.internal>
References: <BLU0-SMTP21829B96B1F0A32A113A6D3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E7561D@W12112.ldschurch.org>
<BLU0-SMTP35978042C1DFCB75E7430F3C52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E75651@W12112.ldschurch.org>
<BLU0-SMTP35668CEDEABCD8D477E09FEC52D0@phx.gbl>
<2F143E71016CA34C924BF4C33AEF211056E756D6@W12112.ldschurch.org>
<BLU0-SMTP366CE9668B959DD8AD94713C52D0@phx.gbl>
<CF2E16827204E249BB155D2C1F5C1EAB1ABAB413@GLB-EXMBX-001.ghdnet.internal>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E75ECA@W12112.ldschurch.org>

Yeah that is really good for consecutive ranges, but I don't think that is his case
here.

From: John Van Laecke [mailto:John.VanLaecke at ghd.com]


Sent: Monday, January 14, 2013 10:36 PM
To: Mike ; Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

In call manager you can make bulk dn's.

Goto
call routing
Directory number
Add new
And you can add a range in and create the call forwards.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Tuesday, 15 January 2013 1:39 PM
To: 'Nate VanMaren'; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

I'll give it a shot thanks!

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:35 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

Ah, my new best friend is import/export.

It's really just a CSV that does anything.

I haven't done it with DNs, but I just imported all of the permutations of phone
button templates in a few seconds.

Export something, look at the CSV in the TAR, edit it to what you want, and load it
back in.

Thanks,
-Nate

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:30 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

True, but I never seen a way to BAT in DNs.

From: Nate VanMaren [mailto:VanMarenNP at ldschurch.org]


Sent: Monday, January 14, 2013 10:27 PM
To: Mike ; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"

From: Mike [mailto:mikeeo at msn.com]


Sent: Monday, January 14, 2013 8:25 PM
To: Nate VanMaren; 'cisco voip'
Subject: RE: [cisco-voip] Design question CTI or DN?

I was thinking of doing a wildcard 1XXX, 2XXX, 3XXX etc , but that might get ugly.
Its weird they don't want to use SNR they just want the call to go to voicemail. I
don't think you can BAT in DNs only CTI ports right?

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nate
VanMaren
Sent: Monday, January 14, 2013 10:19 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Design question CTI or DN?

What needs to happen to an assigned DIDs? If it's ok for them to go to a call


handler, then just have a wildcard for the whole block that sends anything un
assigned to Unity, then it will match their mailbox if it can or they can go to a
callhandler.

Or build DNs for each number, not a ton of fun but can be made easier with AXL or
BAT, the real trouble is keeping them up to date.

-Nate

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 14, 2013 7:01 PM
To: 'cisco voip'
Subject: [cisco-voip] Design question CTI or DN?

I have about 1500 voice mail only users that I have in Unity connections and I was
wondering that the best way to get their DIDs into unity cx. I was thinking I can
create CTI ports send them all to voicemail. The problem is the customer owns the
whole block 0000-9999 and the DIDs are all over the place or I'd create a wild card
hunt pilot.

Any ideas?

Thanks,
Mike

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/52a3d6d7/attachment.html>

From rratliff at cisco.com Tue Jan 15 11:31:25 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 15 Jan 2013 11:31:25 -0500
Subject: [cisco-voip] Gathering Licenses from CUCM?
In-Reply-To: <CAHs2VYsenEWypHOWa7BRbcTwLvxRPGshzMv49_QqOd2xCsr-Ng@mail.gmail.com>
References: <CAHs2VYsenEWypHOWa7BRbcTwLvxRPGshzMv49_QqOd2xCsr-Ng@mail.gmail.com>
Message-ID: <AE3BBFE7-2F2B-4081-9AC0-16D297A1D07B@cisco.com>

admin:file get license *


Please wait while the system is gathering files info ...done.
Sub-directories were not traversed.
Number of files affected: 7
Total size in Bytes: 3450
Total size in Kbytes: 3.3691406
Would you like to proceed [y/n]?
-Ryan

On Jan 15, 2013, at 11:19 AM, Ted Nugent <tednugent73 at gmail.com> wrote:

I'm attempting to gather ~50 individual license files from a CUCM 7.1 server to zip
them up and send to licensing.... Is there anyway to pull them off the server
without having to copy/paste into the individual files...?

TIA
T
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/f7870707/attachment.html>

From tednugent73 at gmail.com Tue Jan 15 12:05:58 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Tue, 15 Jan 2013 12:05:58 -0500
Subject: [cisco-voip] Gathering Licenses from CUCM?
In-Reply-To: <AE3BBFE7-2F2B-4081-9AC0-16D297A1D07B@cisco.com>
References: <CAHs2VYsenEWypHOWa7BRbcTwLvxRPGshzMv49_QqOd2xCsr-Ng@mail.gmail.com>
<AE3BBFE7-2F2B-4081-9AC0-16D297A1D07B@cisco.com>
Message-ID: <CAHs2VYtsCkxJupLyVXy4zgBaFQwah-4qcyc2Xw8pMEGE+Ts5Gg@mail.gmail.com>

Awesome that did it! Thanks!... is there a similar command of Unity


Connection? I see the command there but I get...

admin:file get license *


Please wait while the system is gathering files info ...done.
No such file or directory can be found.
admin:

On Tue, Jan 15, 2013 at 11:31 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> file get license *


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/cbfd58c3/attachment.html>

From dane.newman at gmail.com Tue Jan 15 12:35:58 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Tue, 15 Jan 2013 12:35:58 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
Message-ID: <CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>

Thanks Ryan for the input

*On the call when I hold the call the following debug pops out....*

*Jan 15 17:56:05.246:
//13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
passthru hdrs to
container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
found.
*Jan 15 17:56:05.274:
//13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
found.
*Jan 15 17:56:05.286:
//13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
passthru hdrs to
container
*Jan 15 17:56:05.302:
//13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:05.322: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE

*After I try to unhold the call the following debug comes out....*
**

*Jan 15 17:56:18.874:
//13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
passthru hdrs to
container
*Jan 15 17:56:18.894:
//13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:18.906: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE
Cisco3825#
Cisco3825#
Cisco3825#

On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Given you have an ITSP it's most likely the initial hold that's failing,
> which is only manifesting when you try to resume it. If you haven't
> noticed already this is also very likely causing transfers to fail.
>
> Take a look at the SIP signaling for a call. I believe the most common
> cause to this is the ITSP not handling our transition from
> active->inactive->sendonly->active from hold to MOH to resume. The
> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>
> -Ryan
>
> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> *Hello Kenneth*
> **
> *I have restarted both CUCM servers so this should have restarted the
> services when the utils system restart happened*
> **
>
> *on my router I see I am using g711 from the debug *
> **
> *I ran a debug voip ccapi inout *
> **
> *I connected a call calling from an external number to a DiD inside of my
> system. Once the call was connected I put the call on hold and the
> following debug came out..the music on hold played for the external caller
> *
>
> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
> Stop Tone On Digit=FALSE, Tone=Null,
> Tone Direction=Sum Network, Params=0x0, Call Id=12741
> *Jan 14 23:47:40.783:
> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742, Xmit Function=0x64204BAC
> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=170, Call Id=12742
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=171, Call Id=12741
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
> Interface=0xC05A65AC, Call Id=12742
> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
> Stop Tone On Digit=FALSE, Tone=Null,
> Tone Direction=Sum Network, Params=0x0, Call Id=12741
> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=96, Call Id=12742
> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.839:
> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741, Xmit Function=0x64204BAC
> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=170, Call Id=12741
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=171, Call Id=12742
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
> Interface=0xC05A65AC, Call Id=12742
> Cisco3825#
> Cisco3825#
> Cisco3825#
>
>
> *I then after that took off the hold and the following debug came out.
> The call on the PSDN side still played the hold music while there was no
> voice on the deskphone side.*
>
> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
> Stop Tone On Digit=FALSE, Tone=Null,
> Tone Direction=Sum Network, Params=0x0, Call Id=12741
> *Jan 14 23:47:40.783:
> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742, Xmit Function=0x64204BAC
> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=170, Call Id=12742
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=171, Call Id=12741
> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
> Interface=0xC05A65AC, Call Id=12742
> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
> Stop Tone On Digit=FALSE, Tone=Null,
> Tone Direction=Sum Network, Params=0x0, Call Id=12741
> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=96, Call Id=12742
> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.839:
> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741, Xmit Function=0x64204BAC
> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=170, Call Id=12741
> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
> Call Id=12742,
> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
> Modem=0x0, Codec Bytes=20, Signal Type=2)
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
> Playout Max=1000(ms), Fax Nom=300(ms))
> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
> Call Id=12741,
> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event=171, Call Id=12742
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
> Event Is Sent To Conferenced SPI(s) Directly
> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
> Interface=0xC05A65AC, Call Id=12742
> Cisco3825#
> Cisco3825#
> Cisco3825#
>
> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>
>> Have you also restarted the Cisco IP Media Services?
>>
>> Sent from my iPhone
>>
>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> My ITSP will only support 711ulaw for me currently I believe. They hard
>> coded it with me when I was initially setting it up.
>>
>> Do you think this could be a codec issue? How would I go about
>> identifying if it is?
>>
>> Dane
>>
>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> Have you tried different audio codecs?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Ryan (sorry I forgot to reply to all)
>>>
>>> Thanks for the Reply
>>> Oddly enough we are.
>>> This probably has something to do with MOH in general?
>>>
>>> Internally when I user puts another user on hold everything works. No
>>> MOH plays and they can hold and unhold the call just fine.
>>> I tested calling from an external number. Once I put the external
>>> caller on hold the MOH played but I was unable to resume the call. When I
>>> hit resume on the deskphone the MOH still played to the external caller and
>>> there was no sound on the deskphone.
>>>
>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> Do you get similar behavior if you just hold and resume the call
>>>> outside SNR features?
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Using keyboard-interactive authentication.
>>>>
>>>> Password:
>>>>
>>>>
>>>> Cisco3825#
>>>>
>>>> Cisco3825#sh ver
>>>>
>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>> Version 15.1
>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>
>>>> Technical Support: http://www.cisco.com/techsupport
>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>
>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>
>>>>
>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>
>>>>
>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>
>>>> System returned to ROM by power-on
>>>>
>>>> System image file is
>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>> Last reload type: Normal Reload
>>>>
>>>>
>>>>
>>>> This product contains cryptographic features and is subject to United
>>>>
>>>> States and local country laws governing import, export, transfer and
>>>>
>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>
>>>> third-party authority to import, export, distribute or use encryption.
>>>>
>>>> Importers, exporters, distributors and users are responsible for
>>>>
>>>> compliance with U.S. and local country laws. By using this product you
>>>>
>>>> agree to comply with applicable laws and regulations. If you are unable
>>>>
>>>> to comply with U.S. and local laws, return this product immediately.
>>>>
>>>>
>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>> found at:
>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>
>>>> If you require further assistance please contact us by sending email to
>>>>
>>>> export at cisco.com.
>>>>
>>>>
>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>
>>>> Processor board ID FTX1237A1T0
>>>>
>>>> 2 Gigabit Ethernet interfaces
>>>>
>>>> 2 Channelized T1/PRI ports
>>>>
>>>> 1 Virtual Private Network (VPN) Module
>>>>
>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>
>>>> 479K bytes of NVRAM.
>>>>
>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>
>>>>
>>>>
>>>> License Info:
>>>>
>>>>
>>>> License UDI:
>>>>
>>>>
>>>> -------------------------------------------------
>>>>
>>>> Device# PID SN
>>>>
>>>> Sent from my mobile device
>>>>
>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>> wrote:
>>>>
>>>> What version of code are you running on the CUBE?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Hello
>>>>
>>>> I have an issue when users are connected to a call and hit the
>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>> system rings on the mobile number configured in the system. When they pick
>>>> up the the mobile number it just plays what sounds like hold music on both
>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>> heard it before) instead of providing 2 way voice.
>>>>
>>>> In another senario with what I believe is the same issue. If a user
>>>> picks up on there cell phone first (using single number reach) opposed to
>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>> If the user then hangs up his cell phone with the intent to take the call
>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>> party is still hearing the hold music. It is not working as intended where
>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>> his deskphone 2 way voice should happen.
>>>>
>>>> My topology is as follows..
>>>>
>>>>
>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>
>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>> connect/snr.
>>>>
>>>> Does anyone have any ideas how I can make 2 way voice happen instead of
>>>> the hold music when the calls are picked up?
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/270ef67f/attachment.html>
From rratliff at cisco.com Tue Jan 15 12:42:51 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 15 Jan 2013 12:42:51 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
Message-ID: <AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>

Without sip messages I can't get any clues from that.

-Ryan

On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:

Thanks Ryan for the input

On the call when I hold the call the following debug pops out....

*Jan 15 17:56:05.246: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:


Unable to add passthru hdrs to
container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not found.
*Jan 15 17:56:05.274: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
*Jan 15 17:56:05.286: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
container
*Jan 15 17:56:05.302: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:05.322: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could
not modify QoS params for midcall INVITE

After I try to unhold the call the following debug comes out....

*Jan 15 17:56:18.874: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:


Unable to add passthru hdrs to
container
*Jan 15 17:56:18.894: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:18.906: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could
not modify QoS params for midcall INVITE
Cisco3825#
Cisco3825#
Cisco3825#

On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
Given you have an ITSP it's most likely the initial hold that's failing, which is
only manifesting when you try to resume it. If you haven't noticed already this
is also very likely causing transfers to fail.

Take a look at the SIP signaling for a call. I believe the most common cause to
this is the ITSP not handling our transition from active->inactive->sendonly-
>active from hold to MOH to resume. The "Duplex Streaming Enabled" parameter is
there just for this type of problem.

-Ryan

On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:

Hello Kenneth

I have restarted both CUCM servers so this should have restarted the services when
the utils system restart happened

on my router I see I am using g711 from the debug

I ran a debug voip ccapi inout

I connected a call calling from an external number to a DiD inside of my system.


Once the call was connected I put the call on hold and the following debug came
out..the music on hold played for the external caller

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

I then after that took off the hold and the following debug came out. The call on
the PSDN side still played the hold music while there was no voice on the deskphone
side.

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
Have you also restarted the Cisco IP Media Services?

Sent from my iPhone

On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

> My ITSP will only support 711ulaw for me currently I believe. They hard coded it
with me when I was initially setting it up.
>
> Do you think this could be a codec issue? How would I go about identifying if it
is?
>
> Dane
>
> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
> Have you tried different audio codecs?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Ryan (sorry I forgot to reply to all)
>>
>> Thanks for the Reply
>> Oddly enough we are.
>> This probably has something to do with MOH in general?
>>
>> Internally when I user puts another user on hold everything works. No MOH plays
and they can hold and unhold the call just fine.
>> I tested calling from an external number. Once I put the external caller on hold
the MOH played but I was unable to resume the call. When I hit resume on the
deskphone the MOH still played to the external caller and there was no sound on the
deskphone.
>>
>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>> Do you get similar behavior if you just hold and resume the call outside SNR
features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>> Password:
>>
>> Cisco3825#
>> Cisco3825#sh ver
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>> System returned to ROM by power-on
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>> Last reload type: Normal Reload
>>
>>
>> This product contains cryptographic features and is subject to United
>> States and local country laws governing import, export, transfer and
>> use. Delivery of Cisco cryptographic products does not imply
>> third-party authority to import, export, distribute or use encryption.
>> Importers, exporters, distributors and users are responsible for
>> compliance with U.S. and local country laws. By using this product you
>> agree to comply with applicable laws and regulations. If you are unable
>> to comply with U.S. and local laws, return this product immediately.
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>> export at cisco.com.
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>> Processor board ID FTX1237A1T0
>> 2 Gigabit Ethernet interfaces
>> 2 Channelized T1/PRI ports
>> 1 Virtual Private Network (VPN) Module
>> DRAM configuration is 64 bits wide with parity enabled.
>> 479K bytes of NVRAM.
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>> License Info:
>>
>> License UDI:
>>
>> -------------------------------------------------
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>
>>> What version of code are you running on the CUBE?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>>> Hello
>>>>
>>>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>>
>>>> In another senario with what I believe is the same issue. If a user picks up
on there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>>>
>>>> My topology is as follows..
>>>>
>>>>
>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>
>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>>
>>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/08e70253/attachment.html>

From dane.newman at gmail.com Tue Jan 15 14:11:05 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Tue, 15 Jan 2013 14:11:05 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
Message-ID: <CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>

Ryan

What is the proper debug to use to caputre the useful information?

Dane

On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Without sip messages I can't get any clues from that.
>
> -Ryan
>
> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Thanks Ryan for the input
>
>
> *On the call when I hold the call the following debug pops out....*
>
>
> *Jan 15 17:56:05.246:
> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
> passthru hdrs to
> container
> SIP: Attribute mid, level 1 instance 1 not found.
> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
> found.
> *Jan 15 17:56:05.274:
> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
> passthru headers to container
> SIP: Attribute mid, level 1 instance 1 not found.
> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
> found.
> *Jan 15 17:56:05.286:
> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
> passthru hdrs to
> container
> *Jan 15 17:56:05.302:
> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
> passthru headers to container
> SIP: Attribute mid, level 1 instance 1 not found.
> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
> found.
> SIP: Attribute mid, level 1 instance 1 not found.
> *Jan 15 17:56:05.322:
> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
> params for midcall INVITE
>
> *After I try to unhold the call the following debug comes out....*
> **
>
> *Jan 15 17:56:18.874:
> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
> passthru hdrs to
> container
> *Jan 15 17:56:18.894:
> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
> passthru headers to container
> SIP: Attribute mid, level 1 instance 1 not found.
> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
> found.
> SIP: Attribute mid, level 1 instance 1 not found.
> *Jan 15 17:56:18.906:
> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
> params for midcall INVITE
> Cisco3825#
> Cisco3825#
> Cisco3825#
>
> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Given you have an ITSP it's most likely the initial hold that's failing,
>> which is only manifesting when you try to resume it. If you haven't
>> noticed already this is also very likely causing transfers to fail.
>>
>> Take a look at the SIP signaling for a call. I believe the most common
>> cause to this is the ITSP not handling our transition from
>> active->inactive->sendonly->active from hold to MOH to resume. The
>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> *Hello Kenneth*
>> **
>> *I have restarted both CUCM servers so this should have restarted the
>> services when the utils system restart happened*
>> **
>>
>> *on my router I see I am using g711 from the debug *
>> **
>> *I ran a debug voip ccapi inout *
>> **
>> *I connected a call calling from an external number to a DiD inside of
>> my system. Once the call was connected I put the call on hold and the
>> following debug came out..the music on hold played for the external caller
>> *
>>
>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>> Stop Tone On Digit=FALSE, Tone=Null,
>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>> *Jan 14 23:47:40.783:
>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742, Xmit Function=0x64204BAC
>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=170, Call Id=12742
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=171, Call Id=12741
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>> Interface=0xC05A65AC, Call Id=12742
>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>> Stop Tone On Digit=FALSE, Tone=Null,
>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=96, Call Id=12742
>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.839:
>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741, Xmit Function=0x64204BAC
>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=170, Call Id=12741
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=171, Call Id=12742
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>> Interface=0xC05A65AC, Call Id=12742
>> Cisco3825#
>> Cisco3825#
>> Cisco3825#
>>
>>
>> *I then after that took off the hold and the following debug came out.
>> The call on the PSDN side still played the hold music while there was no
>> voice on the deskphone side.*
>>
>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>> Stop Tone On Digit=FALSE, Tone=Null,
>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>> *Jan 14 23:47:40.783:
>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742, Xmit Function=0x64204BAC
>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=170, Call Id=12742
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=171, Call Id=12741
>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>> Interface=0xC05A65AC, Call Id=12742
>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>> Stop Tone On Digit=FALSE, Tone=Null,
>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=96, Call Id=12742
>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.839:
>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741, Xmit Function=0x64204BAC
>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=170, Call Id=12741
>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>> Call Id=12742,
>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>> Playout Max=1000(ms), Fax Nom=300(ms))
>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>> Call Id=12741,
>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event=171, Call Id=12742
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>> Event Is Sent To Conferenced SPI(s) Directly
>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>> Interface=0xC05A65AC, Call Id=12742
>> Cisco3825#
>> Cisco3825#
>> Cisco3825#
>>
>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> Have you also restarted the Cisco IP Media Services?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> My ITSP will only support 711ulaw for me currently I believe. They hard
>>> coded it with me when I was initially setting it up.
>>>
>>> Do you think this could be a codec issue? How would I go about
>>> identifying if it is?
>>>
>>> Dane
>>>
>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> Have you tried different audio codecs?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Ryan (sorry I forgot to reply to all)
>>>>
>>>> Thanks for the Reply
>>>> Oddly enough we are.
>>>> This probably has something to do with MOH in general?
>>>>
>>>> Internally when I user puts another user on hold everything works. No
>>>> MOH plays and they can hold and unhold the call just fine.
>>>> I tested calling from an external number. Once I put the external
>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>> there was no sound on the deskphone.
>>>>
>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>
>>>>> Do you get similar behavior if you just hold and resume the call
>>>>> outside SNR features?
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Using keyboard-interactive authentication.
>>>>>
>>>>> Password:
>>>>>
>>>>>
>>>>> Cisco3825#
>>>>>
>>>>> Cisco3825#sh ver
>>>>>
>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>> Version 15.1
>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>
>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>
>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>
>>>>>
>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>
>>>>>
>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>
>>>>> System returned to ROM by power-on
>>>>>
>>>>> System image file is
>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>> Last reload type: Normal Reload
>>>>>
>>>>>
>>>>>
>>>>> This product contains cryptographic features and is subject to United
>>>>>
>>>>> States and local country laws governing import, export, transfer and
>>>>>
>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>
>>>>> third-party authority to import, export, distribute or use encryption.
>>>>>
>>>>> Importers, exporters, distributors and users are responsible for
>>>>>
>>>>> compliance with U.S. and local country laws. By using this product you
>>>>>
>>>>> agree to comply with applicable laws and regulations. If you are
>>>>> unable
>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>
>>>>>
>>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>>> found at:
>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>
>>>>> If you require further assistance please contact us by sending email
>>>>> to
>>>>> export at cisco.com.
>>>>>
>>>>>
>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>
>>>>> Processor board ID FTX1237A1T0
>>>>>
>>>>> 2 Gigabit Ethernet interfaces
>>>>>
>>>>> 2 Channelized T1/PRI ports
>>>>>
>>>>> 1 Virtual Private Network (VPN) Module
>>>>>
>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>
>>>>> 479K bytes of NVRAM.
>>>>>
>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>
>>>>>
>>>>>
>>>>> License Info:
>>>>>
>>>>>
>>>>> License UDI:
>>>>>
>>>>>
>>>>> -------------------------------------------------
>>>>>
>>>>> Device# PID SN
>>>>>
>>>>> Sent from my mobile device
>>>>>
>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>> wrote:
>>>>>
>>>>> What version of code are you running on the CUBE?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> I have an issue when users are connected to a call and hit the
>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>> system rings on the mobile number configured in the system. When they pick
>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>> heard it before) instead of providing 2 way voice.
>>>>>
>>>>> In another senario with what I believe is the same issue. If a user
>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>> party is still hearing the hold music. It is not working as intended where
>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>>> his deskphone 2 way voice should happen.
>>>>>
>>>>> My topology is as follows..
>>>>>
>>>>>
>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>
>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>> connect/snr.
>>>>>
>>>>> Does anyone have any ideas how I can make 2 way voice happen instead
>>>>> of the hold music when the calls are picked up?
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/1843a1a2/attachment.html>

From rratliff at cisco.com Tue Jan 15 14:28:59 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 15 Jan 2013 14:28:59 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
Message-ID: <3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>

ccsip message is what I'd go with just to see the signaling with no other stuff.
Depending on what that shows and what your gateway is doing to the signals you may
need to expand from there.

-Ryan

On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:

Ryan

What is the proper debug to use to caputre the useful information?

Dane

On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Without sip messages I can't get any clues from that.

-Ryan

On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:

Thanks Ryan for the input

On the call when I hold the call the following debug pops out....

*Jan 15 17:56:05.246: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:


Unable to add passthru hdrs to
container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not found.
*Jan 15 17:56:05.274: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
*Jan 15 17:56:05.286: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
container
*Jan 15 17:56:05.302: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:05.322: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could
not modify QoS params for midcall INVITE

After I try to unhold the call the following debug comes out....

*Jan 15 17:56:18.874: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:


Unable to add passthru hdrs to
container
*Jan 15 17:56:18.894: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
passthru headers to container
SIP: Attribute mid, level 1 instance 1 not found.
SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: Attribute mid, level 1 instance 1 not found.
*Jan 15 17:56:18.906: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could
not modify QoS params for midcall INVITE
Cisco3825#
Cisco3825#
Cisco3825#

On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
Given you have an ITSP it's most likely the initial hold that's failing, which is
only manifesting when you try to resume it. If you haven't noticed already this
is also very likely causing transfers to fail.

Take a look at the SIP signaling for a call. I believe the most common cause to
this is the ITSP not handling our transition from active->inactive->sendonly-
>active from hold to MOH to resume. The "Duplex Streaming Enabled" parameter is
there just for this type of problem.

-Ryan

On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:

Hello Kenneth

I have restarted both CUCM servers so this should have restarted the services when
the utils system restart happened

on my router I see I am using g711 from the debug

I ran a debug voip ccapi inout

I connected a call calling from an external number to a DiD inside of my system.


Once the call was connected I put the call on hold and the following debug came
out..the music on hold played for the external caller

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

I then after that took off the hold and the following debug came out. The call on
the PSDN side still played the hold music while there was no voice on the deskphone
side.

*Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:


Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
*Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12742
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
Feature Type=50, Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12741
*Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
*Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=12741
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=96, Call Id=12742
*Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
*Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
*Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event=170, Call Id=12741
*Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event=171, Call Id=12742
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
*Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
Interface=0xC05A65AC, Call Id=12742
Cisco3825#
Cisco3825#
Cisco3825#

On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
Have you also restarted the Cisco IP Media Services?

Sent from my iPhone

On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

> My ITSP will only support 711ulaw for me currently I believe. They hard coded it
with me when I was initially setting it up.
>
> Do you think this could be a codec issue? How would I go about identifying if it
is?
>
> Dane
>
> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
> Have you tried different audio codecs?
>
> Sent from my iPhone
>
> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Ryan (sorry I forgot to reply to all)
>>
>> Thanks for the Reply
>> Oddly enough we are.
>> This probably has something to do with MOH in general?
>>
>> Internally when I user puts another user on hold everything works. No MOH plays
and they can hold and unhold the call just fine.
>> I tested calling from an external number. Once I put the external caller on hold
the MOH played but I was unable to resume the call. When I hit resume on the
deskphone the MOH still played to the external caller and there was no sound on the
deskphone.
>>
>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>> Do you get similar behavior if you just hold and resume the call outside SNR
features?
>>
>> -Ryan
>>
>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Using keyboard-interactive authentication.
>> Password:
>>
>> Cisco3825#
>> Cisco3825#sh ver
>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>> (4)M5, RELEASE SOFTWARE (fc1)
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>
>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>
>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>> System returned to ROM by power-on
>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>> Last reload type: Normal Reload
>>
>>
>> This product contains cryptographic features and is subject to United
>> States and local country laws governing import, export, transfer and
>> use. Delivery of Cisco cryptographic products does not imply
>> third-party authority to import, export, distribute or use encryption.
>> Importers, exporters, distributors and users are responsible for
>> compliance with U.S. and local country laws. By using this product you
>> agree to comply with applicable laws and regulations. If you are unable
>> to comply with U.S. and local laws, return this product immediately.
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be found at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>> export at cisco.com.
>>
>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>> Processor board ID FTX1237A1T0
>> 2 Gigabit Ethernet interfaces
>> 2 Channelized T1/PRI ports
>> 1 Virtual Private Network (VPN) Module
>> DRAM configuration is 64 bits wide with parity enabled.
>> 479K bytes of NVRAM.
>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>
>>
>> License Info:
>>
>> License UDI:
>>
>> -------------------------------------------------
>> Device# PID SN
>>
>> Sent from my mobile device
>>
>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>
>>> What version of code are you running on the CUBE?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>>> Hello
>>>>
>>>> I have an issue when users are connected to a call and hit the mobility soft
key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>>
>>>> In another senario with what I believe is the same issue. If a user picks up
on there cell phone first (using single number reach) opposed to the deskphone the
call is connected with 2 way voice and no issues exist. If the user then hangs up
his cell phone with the intent to take the call on his deskphone the calling party
starts hearing the hold music. Once the user picks up the call on his deskphone he
hears nothing but the calling party is still hearing the hold music. It is not
working as intended where 2 way voice happens once the user hangs up his mobile
phone and picks up on his deskphone 2 way voice should happen.
>>>>
>>>> My topology is as follows..
>>>>
>>>>
>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>
>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>>
>>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/035f8c4a/attachment.html>

From dane.newman at gmail.com Tue Jan 15 15:12:44 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Tue, 15 Jan 2013 15:12:44 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
Message-ID: <CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>

Thanks Ryan

I see I am always getting a 200 ok message after my invites from the debug

*Putting a call on HOLD*

*Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 102 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video

Content-Type: application/sdp
Content-Length: 240

v=0

o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 0.0.0.0

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 103 INVITE


Max-Forwards: 70

Timestamp: 1358281168

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Type: application/sdp

Content-Length: 289

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101 19

c=IN IP4 98.192.104.214

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22


Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 102 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK691F12E0;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 103 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK691F12E0;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214


CSeq: 103 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 239

v=0

o=root 1685873050 1685873052 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 102 INVITE


Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 253

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

*Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D


From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 103 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Length: 0

*Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 102 ACK

Allow-Events: presence

Content-Length: 0

*Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22


Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 103 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video

Content-Length: 0

*Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 104 INVITE

Max-Forwards: 70

Timestamp: 1358281168

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 103 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69211AB3;received=98.192.104.214
From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 104 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69211AB3;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 104 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333

v=0
o=root 1685873050 1685873053 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 3 8 0 18 101

a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 103 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces
Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70
CSeq: 103 ACK

Allow-Events: presence

Content-Type: application/sdp

Content-Length: 209

v=0

o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 0.0.0.0

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0

a=X-cisco-media:nomedia

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

*Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 104 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event
Content-Type: application/sdp

Content-Length: 251

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 0.0.0.0

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 0.0.0.0

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

*Unholding the call the MOH continues on the previously held caller while
the user hears nothing*

**

*Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 104 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video

Content-Length: 0

*Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 105 INVITE

Max-Forwards: 70
Timestamp: 1358281175

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE


Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333

v=0

o=root 1685873050 1685873054 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 3 8 0 18 101


a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer
Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 104 ACK

Allow-Events: presence, kpml

Content-Type: application/sdp

Content-Length: 243

v=0
o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 10.1.10.18

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 105 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 265

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214


s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 98.192.104.214

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

Cisco3825#

Cisco3825#

Cisco3825#

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 104 INVITE

Max-Forwards: 70

Expires: 180
Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video

Content-Length: 0

*Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 105 INVITE

Max-Forwards: 70

Timestamp: 1358281175

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas
Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333

v=0

o=root 1685873050 1685873054 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 3 8 0 18 101

a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1

s=SIP Call
c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 104 ACK

Allow-Events: presence, kpml

Content-Type: application/sdp

Content-Length: 243

v=0

o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 10.1.10.18

b=TIAS:64000

b=AS:64
t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 105 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 265

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 98.192.104.214


a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

Cisco3825#

On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> ccsip message is what I'd go with just to see the signaling with no other
> stuff. Depending on what that shows and what your gateway is doing to the
> signals you may need to expand from there.
>
> -Ryan
>
> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Ryan
>
> What is the proper debug to use to caputre the useful information?
>
> Dane
>
>
>
> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Without sip messages I can't get any clues from that.
>>
>> -Ryan
>>
>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Thanks Ryan for the input
>>
>>
>> *On the call when I hold the call the following debug pops out....*
>>
>>
>> *Jan 15 17:56:05.246:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> *Jan 15 17:56:05.274:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> *Jan 15 17:56:05.286:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> *Jan 15 17:56:05.302:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> SIP: Attribute mid, level 1 instance 1 not found.
>> *Jan 15 17:56:05.322:
>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>> params for midcall INVITE
>>
>> *After I try to unhold the call the following debug comes out....*
>> **
>>
>> *Jan 15 17:56:18.874:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> *Jan 15 17:56:18.894:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> SIP: Attribute mid, level 1 instance 1 not found.
>> *Jan 15 17:56:18.906:
>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>> params for midcall INVITE
>> Cisco3825#
>> Cisco3825#
>> Cisco3825#
>>
>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> Given you have an ITSP it's most likely the initial hold that's failing,
>>> which is only manifesting when you try to resume it. If you haven't
>>> noticed already this is also very likely causing transfers to fail.
>>>
>>> Take a look at the SIP signaling for a call. I believe the most common
>>> cause to this is the ITSP not handling our transition from
>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>
>>> -Ryan
>>>
>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> *Hello Kenneth*
>>> **
>>> *I have restarted both CUCM servers so this should have restarted the
>>> services when the utils system restart happened*
>>> **
>>>
>>> *on my router I see I am using g711 from the debug *
>>> **
>>> *I ran a debug voip ccapi inout *
>>> **
>>> *I connected a call calling from an external number to a DiD inside of
>>> my system. Once the call was connected I put the call on hold and the
>>> following debug came out..the music on hold played for the external caller
>>> *
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783:
>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839:
>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>>
>>> *I then after that took off the hold and the following debug came out.
>>> The call on the PSDN side still played the hold music while there was no
>>> voice on the deskphone side.*
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783:
>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839:
>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> Have you also restarted the Cisco IP Media Services?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>> hard coded it with me when I was initially setting it up.
>>>>
>>>> Do you think this could be a codec issue? How would I go about
>>>> identifying if it is?
>>>>
>>>> Dane
>>>>
>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> Have you tried different audio codecs?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Ryan (sorry I forgot to reply to all)
>>>>>
>>>>> Thanks for the Reply
>>>>> Oddly enough we are.
>>>>> This probably has something to do with MOH in general?
>>>>>
>>>>> Internally when I user puts another user on hold everything works. No
>>>>> MOH plays and they can hold and unhold the call just fine.
>>>>> I tested calling from an external number. Once I put the external
>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>>> there was no sound on the deskphone.
>>>>>
>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>> outside SNR features?
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Using keyboard-interactive authentication.
>>>>>>
>>>>>> Password:
>>>>>>
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>> Cisco3825#sh ver
>>>>>>
>>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>>> Version 15.1
>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>
>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>
>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>
>>>>>>
>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>>
>>>>>>
>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>
>>>>>> System returned to ROM by power-on
>>>>>>
>>>>>> System image file is
>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>> Last reload type: Normal Reload
>>>>>>
>>>>>>
>>>>>>
>>>>>> This product contains cryptographic features and is subject to United
>>>>>>
>>>>>> States and local country laws governing import, export, transfer and
>>>>>>
>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>
>>>>>> third-party authority to import, export, distribute or use
>>>>>> encryption.
>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>
>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>> you
>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>> unable
>>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>>
>>>>>>
>>>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>>>> found at:
>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>
>>>>>> If you require further assistance please contact us by sending email
>>>>>> to
>>>>>> export at cisco.com.
>>>>>>
>>>>>>
>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>
>>>>>> Processor board ID FTX1237A1T0
>>>>>>
>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>
>>>>>> 2 Channelized T1/PRI ports
>>>>>>
>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>
>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>
>>>>>> 479K bytes of NVRAM.
>>>>>>
>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>
>>>>>>
>>>>>>
>>>>>> License Info:
>>>>>>
>>>>>>
>>>>>> License UDI:
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------
>>>>>>
>>>>>> Device# PID SN
>>>>>>
>>>>>> Sent from my mobile device
>>>>>>
>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> What version of code are you running on the CUBE?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> I have an issue when users are connected to a call and hit the
>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>> system rings on the mobile number configured in the system. When they pick
>>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>
>>>>>> In another senario with what I believe is the same issue. If a user
>>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>>> party is still hearing the hold music. It is not working as intended where
>>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>>>> his deskphone 2 way voice should happen.
>>>>>>
>>>>>> My topology is as follows..
>>>>>>
>>>>>>
>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>
>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>>> connect/snr.
>>>>>>
>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead
>>>>>> of the hold music when the calls are picked up?
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/b4c5c30f/attachment.html>

From kennethwhayes at gmail.com Tue Jan 15 15:31:45 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Tue, 15 Jan 2013 15:31:45 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
Message-ID: <-510307317839395630@unknownmsgid>

What do your media resources look like?

Also can you show me a copy of your voice service voip config?

Sent from my iPad

On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:

Thanks Ryan

I see I am always getting a 200 ok message after my invites from the debug

*Putting a call on HOLD*

*Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 102 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation
Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video

Content-Type: application/sdp

Content-Length: 240

v=0

o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 0.0.0.0

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 103 INVITE

Max-Forwards: 70

Timestamp: 1358281168

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Type: application/sdp

Content-Length: 289

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101 19

c=IN IP4 98.192.104.214

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:


Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 102 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK691F12E0;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 103 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK691F12E0;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 103 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 239

v=0

o=root 1685873050 1685873052 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa


From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 102 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 253

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16
a=ptime:20

*Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 103 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Length: 0

*Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 102 ACK

Allow-Events: presence

Content-Length: 0

*Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:


Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 103 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video

Content-Length: 0

*Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e


Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 104 INVITE

Max-Forwards: 70

Timestamp: 1358281168

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 103 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

*Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69211AB3;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 104 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69211AB3;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 104 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer
Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333

v=0

o=root 1685873050 1685873053 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 3 8 0 18 101

a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 103 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3


From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 103 ACK

Allow-Events: presence

Content-Type: application/sdp

Content-Length: 209

v=0

o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 0.0.0.0

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0

a=X-cisco-media:nomedia

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

*Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:28 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214


Max-Forwards: 70

CSeq: 104 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 251

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 0.0.0.0

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 0.0.0.0

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

*Unholding the call the MOH continues on the previously held caller while
the user hears nothing*

**

*Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 104 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video

Content-Length: 0

*Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800
Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 105 INVITE

Max-Forwards: 70

Timestamp: 1358281175

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333
v=0

o=root 1685873050 1685873054 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0

m=audio 13014 RTP/AVP 3 8 0 18 101

a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>


Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10


Max-Forwards: 70

CSeq: 104 ACK

Allow-Events: presence, kpml

Content-Type: application/sdp

Content-Length: 243

v=0

o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 10.1.10.18

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 105 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 265

v=0

o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 98.192.104.214

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

Cisco3825#

Cisco3825#

Cisco3825#

INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Supported: timer,resource-priority,replaces

Min-SE: 1800
User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY

CSeq: 104 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>

Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;party=calling;screen=yes;privacy=off

Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video

Content-Length: 0

*Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 3257897472-0000065536-0000000035-0173015306

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

CSeq: 105 INVITE

Max-Forwards: 70
Timestamp: 1358281175

Contact: <sip:6784563290 at 98.192.104.214:5060>

Expires: 180

Allow-Events: telephone-event

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Session-Expires: 1800;refresher=uas

Content-Length: 0

*Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE


Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Length: 0

*Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 98.192.104.214:5060


;branch=z9hG4bK69232672;received=98.192.104.214

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

CSeq: 105 INVITE

Server: Asterisk PBX 1.6.2.13

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces, timer

Require: timer

Session-Expires: 1800;refresher=uas

Contact: <sip:17705439047 at 64.154.41.150>

Content-Type: application/sdp

Content-Length: 333

v=0

o=root 1685873050 1685873054 IN IP4 64.154.41.150

s=Asterisk PBX 1.6.2.13

c=IN IP4 64.154.41.150

t=0 0
m=audio 13014 RTP/AVP 3 8 0 18 101

a=rtpmap:3 GSM/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=inactive

*Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

CSeq: 104 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:17705439047 at 10.1.200.1


>;party=called;screen=no;privacy=off

Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires: 1800;refresher=uas

Require: timer
Supported: timer

Content-Type: application/sdp

Content-Length: 277

v=0

o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1

s=SIP Call

c=IN IP4 10.1.200.1

t=0 0

m=audio 19514 RTP/AVP 0 101 19

c=IN IP4 10.1.200.1

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

*Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616

From: "Dane Newman" <sip:6784563290 at 10.1.80.10


>;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957

To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22

Date: Tue, 15 Jan 2013 19:57:42 GMT

Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10

Max-Forwards: 70

CSeq: 104 ACK

Allow-Events: presence, kpml

Content-Type: application/sdp

Content-Length: 243
v=0

o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10

s=SIP Call

c=IN IP4 10.1.10.18

b=TIAS:64000

b=AS:64

t=0 0

m=audio 21476 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0

Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB

From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net


>;tag=2E6BC0B0-2268

To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e

Date: Tue, 15 Jan 2013 20:19:35 GMT

Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214

Max-Forwards: 70

CSeq: 105 ACK

Authorization: Digest username="6784563290",realm="asterisk",uri="


sip:17705439047 at 64.154.41.150:5060
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 265

v=0
o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214

s=SIP Call

c=IN IP4 98.192.104.214

t=0 0

m=audio 19458 RTP/AVP 0 101

c=IN IP4 98.192.104.214

a=inactive

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

Cisco3825#

On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> ccsip message is what I'd go with just to see the signaling with no other
> stuff. Depending on what that shows and what your gateway is doing to the
> signals you may need to expand from there.
>
> -Ryan
>
> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Ryan
>
> What is the proper debug to use to caputre the useful information?
>
> Dane
>
>
>
> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Without sip messages I can't get any clues from that.
>>
>> -Ryan
>>
>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Thanks Ryan for the input
>>
>>
>> *On the call when I hold the call the following debug pops out....*
>>
>>
>> *Jan 15 17:56:05.246:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> *Jan 15 17:56:05.274:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> *Jan 15 17:56:05.286:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> *Jan 15 17:56:05.302:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> SIP: Attribute mid, level 1 instance 1 not found.
>> *Jan 15 17:56:05.322:
>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>> params for midcall INVITE
>>
>> *After I try to unhold the call the following debug comes out....*
>> **
>>
>> *Jan 15 17:56:18.874:
>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>> passthru hdrs to
>> container
>> *Jan 15 17:56:18.894:
>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>> passthru headers to container
>> SIP: Attribute mid, level 1 instance 1 not found.
>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>> found.
>> SIP: Attribute mid, level 1 instance 1 not found.
>> *Jan 15 17:56:18.906:
>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>> params for midcall INVITE
>> Cisco3825#
>> Cisco3825#
>> Cisco3825#
>>
>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> Given you have an ITSP it's most likely the initial hold that's failing,
>>> which is only manifesting when you try to resume it. If you haven't
>>> noticed already this is also very likely causing transfers to fail.
>>>
>>> Take a look at the SIP signaling for a call. I believe the most common
>>> cause to this is the ITSP not handling our transition from
>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>
>>> -Ryan
>>>
>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> *Hello Kenneth*
>>> **
>>> *I have restarted both CUCM servers so this should have restarted the
>>> services when the utils system restart happened*
>>> **
>>>
>>> *on my router I see I am using g711 from the debug *
>>> **
>>> *I ran a debug voip ccapi inout *
>>> **
>>> *I connected a call calling from an external number to a DiD inside of
>>> my system. Once the call was connected I put the call on hold and the
>>> following debug came out..the music on hold played for the external caller
>>> *
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783:
>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839:
>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>>
>>> *I then after that took off the hold and the following debug came out.
>>> The call on the PSDN side still played the hold music while there was no
>>> voice on the deskphone side.*
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783:
>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839:
>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>> Call Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>> Call Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> Have you also restarted the Cisco IP Media Services?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>> hard coded it with me when I was initially setting it up.
>>>>
>>>> Do you think this could be a codec issue? How would I go about
>>>> identifying if it is?
>>>>
>>>> Dane
>>>>
>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> Have you tried different audio codecs?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Ryan (sorry I forgot to reply to all)
>>>>>
>>>>> Thanks for the Reply
>>>>> Oddly enough we are.
>>>>> This probably has something to do with MOH in general?
>>>>>
>>>>> Internally when I user puts another user on hold everything works. No
>>>>> MOH plays and they can hold and unhold the call just fine.
>>>>> I tested calling from an external number. Once I put the external
>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>>> there was no sound on the deskphone.
>>>>>
>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>> outside SNR features?
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Using keyboard-interactive authentication.
>>>>>>
>>>>>> Password:
>>>>>>
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>> Cisco3825#sh ver
>>>>>>
>>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>>> Version 15.1
>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>
>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>
>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>
>>>>>>
>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>>
>>>>>>
>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>
>>>>>> System returned to ROM by power-on
>>>>>>
>>>>>> System image file is
>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>> Last reload type: Normal Reload
>>>>>>
>>>>>>
>>>>>>
>>>>>> This product contains cryptographic features and is subject to United
>>>>>>
>>>>>> States and local country laws governing import, export, transfer and
>>>>>>
>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>
>>>>>> third-party authority to import, export, distribute or use
>>>>>> encryption.
>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>
>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>> you
>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>> unable
>>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>>
>>>>>>
>>>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>>>> found at:
>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>
>>>>>> If you require further assistance please contact us by sending email
>>>>>> to
>>>>>> export at cisco.com.
>>>>>>
>>>>>>
>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>
>>>>>> Processor board ID FTX1237A1T0
>>>>>>
>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>
>>>>>> 2 Channelized T1/PRI ports
>>>>>>
>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>
>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>
>>>>>> 479K bytes of NVRAM.
>>>>>>
>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>
>>>>>>
>>>>>>
>>>>>> License Info:
>>>>>>
>>>>>>
>>>>>> License UDI:
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------
>>>>>>
>>>>>> Device# PID SN
>>>>>>
>>>>>> Sent from my mobile device
>>>>>>
>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> What version of code are you running on the CUBE?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> I have an issue when users are connected to a call and hit the
>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>> system rings on the mobile number configured in the system. When they pick
>>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>
>>>>>> In another senario with what I believe is the same issue. If a user
>>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>>> party is still hearing the hold music. It is not working as intended where
>>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>>>> his deskphone 2 way voice should happen.
>>>>>>
>>>>>> My topology is as follows..
>>>>>>
>>>>>>
>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>
>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>>> connect/snr.
>>>>>>
>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead
>>>>>> of the hold music when the calls are picked up?
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/72827997/attachment.html>

From dane.newman at gmail.com Tue Jan 15 15:39:02 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Tue, 15 Jan 2013 15:39:02 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <-510307317839395630@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
Message-ID: <CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>

Below is a show run from the router

[OK]
Cisco3825#sh run
Building configuration...

Current configuration : 10183 bytes


!
! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco3825
!
boot-start-marker
boot-end-marker
!
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication login vpnauth local
aaa authorization exec default local
aaa authorization network default local
aaa authorization network vpnauth local
!
!
!
!
!
aaa session-id common
!
no network-clock-participate wic 0
!
dot11 syslog
ip source-route
!
ip cef
!
!
!
!
ip domain name datasc.local
ip inspect udp idle-time 1800
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
voice-card 0
dsp services dspfarm
!
!
!
voice service voip
ip address trusted list
ipv4 64.154.41.150 255.255.255.255
allow-connections sip to sip
fax protocol pass-through g711ulaw
sip
!
!
!
!
voice translation-rule 1
rule 1 /6784604564/ /200/
rule 2 /6784563290/ /100/
rule 3 /6784563291/ /101/
rule 4 /6784563292/ /102/
rule 5 /6784563293/ /103/
rule 6 /6784563294/ /104/
rule 7 /6784563295/ /105/
rule 8 /6784563296/ /106/
rule 9 /6784563297/ /107/
rule 10 /6784563298/ /108/
rule 11 /6784563299/ /109/
rule 12 /6784604565/ /125/
!
!
voice translation-profile incomingdid
translate called 1
!
!
crypto pki token default removal timeout 0
!
crypto pki trustpoint selfsigned
enrollment selfsigned
subject-name CN=connect.datasc.com
revocation-check crl
!
!
crypto pki certificate chain selfsigned
certificate self-signed 02
30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
quit
!
!
license udi pid CISCO3825 sn FTX1237A1T0
username xxxxxxx privilege 15 secret xxxxxx
!
redundancy
!
!
controller T1 0/0/0
!
controller T1 0/0/1
!
ip ssh version 2
!
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
crypto isakmp fragmentation
!
crypto isakmp client configuration group datasc
key Recoil90
dns 4.2.2.2 4.2.2.1
domain datasc.local
pool vpnpool
save-password
!
crypto isakmp client configuration group datascsplit
key Recoil90
dns 4.2.2.2 4.2.2.1
domain datasc.local
pool vpnpool
acl 101
save-password
crypto isakmp profile datasc
match identity group datasc
client authentication list vpnauth
isakmp authorization list vpnauth
client configuration address respond
virtual-template 1
crypto isakmp profile datascsplit
match identity group datascsplit
client authentication list vpnauth
isakmp authorization list vpnauth
client configuration address respond
virtual-template 2
!
!
crypto ipsec transform-set transformset esp-aes
crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set ezvpntransform
set isakmp-profile datasc
!
crypto ipsec profile VTI2
set transform-set ezvpntransform
set isakmp-profile datascsplit
!
!
!
!
!
!
!
interface Loopback1
ip address 10.1.150.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface GigabitEthernet0/0
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
hold-queue 240000 in
!
interface GigabitEthernet0/1
ip address 10.1.200.1 255.255.255.252
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
!
interface Virtual-Template1 type tunnel
ip unnumbered GigabitEthernet0/0
ip nat inside
ip virtual-reassembly in
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
!
interface Virtual-Template2 type tunnel
ip unnumbered GigabitEthernet0/0
ip nat inside
ip virtual-reassembly in
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI2
!
interface Virtual-Template3
ip unnumbered GigabitEthernet0/0
ip nat outside
ip virtual-reassembly in
ip policy route-map anyconnecthop
!
!
router eigrp 1
maximum-paths 1
network 10.0.0.0
redistribute static
!
ip local pool vpnpool 10.1.100.10 10.1.100.200
ip forward-protocol nd
ip http server
ip http secure-server
!
!
ip nat inside source list NATNETWORKS interface GigabitEthernet0/0 overload
ip nat inside source static tcp 10.1.50.150 80 interface GigabitEthernet0/0
80
ip nat inside source static tcp 10.1.80.100 5001 interface
GigabitEthernet0/0 5001
ip nat inside source static udp 10.1.80.100 5001 interface
GigabitEthernet0/0 5001
!
ip access-list extended NATNETWORKS
deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any
ip access-list extended anyconnecthop
deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any
!
access-list 50 permit 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.0.0.0 0.255.255.255 any
!
!
!
!
route-map anyconnecthop permit 10
match ip address anyconnecthop
set ip next-hop 10.1.150.2
!
!
!
!
!
control-plane
!
!
!
!
mgcp profile default
!
!
dial-peer voice 100 voip
description Publisher
preference 1
destination-pattern 1..
session protocol sipv2
session target ipv4:10.1.80.10
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 101 voip
description Subscriber
preference 2
destination-pattern 1..
session target ipv4:10.1.80.11
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 200 voip
description Publisher
preference 1
destination-pattern 2..
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target ipv4:10.1.80.10
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 300 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 678456329.
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 301 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 6784604565
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 302 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 6784604564
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 201 voip
description Publisher
preference 2
destination-pattern 2..
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target ipv4:10.1.80.11
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 500 voip
description outgoing
preference 1
destination-pattern .T
session protocol sipv2
session target dns:sip.talkinip.net
dtmf-relay rtp-nte
codec g711ulaw
!
!
sip-ua
credentials username xxxxxxxx password 7 xxxxxxx realm
sipconnect.ipcomms.net
authentication username xxxxxx password 7 xxxxxxx
authentication username xxxxx password 7 xxxxxxx realm
sipconnect.ipcomms.net
set pstn-cause 3 sip-status 486
set pstn-cause 34 sip-status 486
set pstn-cause 47 sip-status 486
registrar dns:sipconnect.ipcomms.net expires 60
sip-server dns:sipconnect.ipcomms.net:5060
!
!
!
gatekeeper
shutdown
!
!
call-manager-fallback
max-conferences 8 gain -6
transfer-system full-consult
ip source-address 10.1.200.1 port 2000
max-ephones 20
max-dn 40
!
!
!
line con 0
line aux 0
line vty 0 4
privilege level 15
transport input ssh
line vty 5 15
privilege level 15
transport input ssh
!
scheduler allocate 20000 1000
!
webvpn gateway gateway_1
ip interface GigabitEthernet0/0 port 443
ssl trustpoint selfsigned
inservice
!
webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg sequence 1
!
webvpn context datasc
title "DataSC VPN"
secondary-color white
title-color #CCCC66
text-color black
ssl authenticate verify all
!
url-list "Servers"
heading "Server"
!
!
policy group datasc
url-list "Servers"
functions svc-enabled
svc address-pool "vpnpool" netmask 255.255.255.0
svc keep-client-installed
svc dns-server primary 4.2.2.2
svc dtls
virtual-template 3
default-group-policy datasc
aaa authentication list vpnauth
gateway gateway_1 domain datasc
inservice
!
!
webvpn context datascsplit
title "DataSC VPN Split"
secondary-color white
title-color #CCCC66
text-color black
ssl authenticate verify all
!
url-list "Servers"
heading "Server"
!
!
policy group datascsplit
url-list "Servers"
functions svc-enabled
svc address-pool "vpnpool" netmask 255.255.255.0
svc split include acl 50
svc dns-server primary 4.2.2.2
svc dtls
default-group-policy datascsplit
aaa authentication list vpnauth
gateway gateway_1 domain datascsplit
inservice
!
end
Cisco3825#

On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> What do your media resources look like?


>
>
> Also can you show me a copy of your voice service voip config?
>
> Sent from my iPad
>
> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Thanks Ryan
>
> I see I am always getting a 200 ok message after my invites from the debug
>
> *Putting a call on HOLD*
>
>
>
> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 102 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>
> Content-Type: application/sdp
>
> Content-Length: 240
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 103 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281168
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Type: application/sdp
>
> Content-Length: 289
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101 19
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 102 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 103 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 103 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 239
>
> v=0
>
> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 102 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 253
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 103 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Length: 0
>
> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 102 ACK
>
> Allow-Events: presence
>
> Content-Length: 0
>
> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 103 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>
> Content-Length: 0
>
> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281168
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 103 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 104 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 104 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 103 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 103 ACK
>
> Allow-Events: presence
>
> Content-Type: application/sdp
>
> Content-Length: 209
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0
>
> a=X-cisco-media:nomedia
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 251
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 0.0.0.0
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
>
>
> *Unholding the call the MOH continues on the previously held caller while
> the user hears nothing*
>
> **
>
>
>
> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>
> Content-Length: 0
>
> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 105 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281175
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Allow-Events: presence, kpml
>
> Content-Type: application/sdp
>
> Content-Length: 243
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 10.1.10.18
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 105 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 265
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> Cisco3825#
>
> Cisco3825#
>
>
>
> Cisco3825#
>
>
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>
> Content-Length: 0
>
> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 105 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281175
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Allow-Events: presence, kpml
>
> Content-Type: application/sdp
>
> Content-Length: 243
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 10.1.10.18
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 105 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 265
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> Cisco3825#
>
>
> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> ccsip message is what I'd go with just to see the signaling with no other
>> stuff. Depending on what that shows and what your gateway is doing to the
>> signals you may need to expand from there.
>>
>> -Ryan
>>
>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Ryan
>>
>> What is the proper debug to use to caputre the useful information?
>>
>> Dane
>>
>>
>>
>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>
>>> Without sip messages I can't get any clues from that.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Thanks Ryan for the input
>>>
>>>
>>> *On the call when I hold the call the following debug pops out....*
>>>
>>>
>>> *Jan 15 17:56:05.246:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> *Jan 15 17:56:05.274:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> *Jan 15 17:56:05.286:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> *Jan 15 17:56:05.302:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:05.322:
>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>> params for midcall INVITE
>>>
>>> *After I try to unhold the call the following debug comes out....*
>>> **
>>>
>>> *Jan 15 17:56:18.874:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> *Jan 15 17:56:18.894:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:18.906:
>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>> params for midcall INVITE
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> Given you have an ITSP it's most likely the initial hold that's
>>>> failing, which is only manifesting when you try to resume it. If you
>>>> haven't noticed already this is also very likely causing transfers to fail.
>>>>
>>>> Take a look at the SIP signaling for a call. I believe the most
>>>> common cause to this is the ITSP not handling our transition from
>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> *Hello Kenneth*
>>>> **
>>>> *I have restarted both CUCM servers so this should have restarted the
>>>> services when the utils system restart happened*
>>>> **
>>>>
>>>> *on my router I see I am using g711 from the debug *
>>>> **
>>>> *I ran a debug voip ccapi inout *
>>>> **
>>>> *I connected a call calling from an external number to a DiD inside of
>>>> my system. Once the call was connected I put the call on hold and the
>>>> following debug came out..the music on hold played for the external caller
>>>> *
>>>>
>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.783:
>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.783:
>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12742
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12741
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=96, Call Id=12742
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.839:
>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.839:
>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12741
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12742
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> Cisco3825#
>>>> Cisco3825#
>>>> Cisco3825#
>>>>
>>>>
>>>> *I then after that took off the hold and the following debug came
>>>> out. The call on the PSDN side still played the hold music while there was
>>>> no voice on the deskphone side.*
>>>>
>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.783:
>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.783:
>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12742
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12741
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=96, Call Id=12742
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.839:
>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.839:
>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12741
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12742
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> Cisco3825#
>>>> Cisco3825#
>>>> Cisco3825#
>>>>
>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>> hard coded it with me when I was initially setting it up.
>>>>>
>>>>> Do you think this could be a codec issue? How would I go about
>>>>> identifying if it is?
>>>>>
>>>>> Dane
>>>>>
>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>> kennethwhayes at gmail.com> wrote:
>>>>>
>>>>>> Have you tried different audio codecs?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>
>>>>>> Thanks for the Reply
>>>>>> Oddly enough we are.
>>>>>> This probably has something to do with MOH in general?
>>>>>>
>>>>>> Internally when I user puts another user on hold everything works. No
>>>>>> MOH plays and they can hold and unhold the call just fine.
>>>>>> I tested calling from an external number. Once I put the external
>>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>>>> there was no sound on the deskphone.
>>>>>>
>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>> outside SNR features?
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Using keyboard-interactive authentication.
>>>>>>>
>>>>>>> Password:
>>>>>>>
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> Cisco3825#sh ver
>>>>>>>
>>>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>>>> Version 15.1
>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>
>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>
>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>
>>>>>>>
>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>>>
>>>>>>>
>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>
>>>>>>> System returned to ROM by power-on
>>>>>>>
>>>>>>> System image file is
>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>> Last reload type: Normal Reload
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This product contains cryptographic features and is subject to
>>>>>>> United
>>>>>>> States and local country laws governing import, export, transfer and
>>>>>>>
>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>
>>>>>>> third-party authority to import, export, distribute or use
>>>>>>> encryption.
>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>
>>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>>> you
>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>> unable
>>>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>>>
>>>>>>>
>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>>>>> found at:
>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>
>>>>>>> If you require further assistance please contact us by sending email
>>>>>>> to
>>>>>>> export at cisco.com.
>>>>>>>
>>>>>>>
>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>
>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>
>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>
>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>
>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>
>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>
>>>>>>> 479K bytes of NVRAM.
>>>>>>>
>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> License Info:
>>>>>>>
>>>>>>>
>>>>>>> License UDI:
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------
>>>>>>>
>>>>>>> Device# PID SN
>>>>>>>
>>>>>>> Sent from my mobile device
>>>>>>>
>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> What version of code are you running on the CUBE?
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>> system rings on the mobile number configured in the system. When they pick
>>>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>
>>>>>>> In another senario with what I believe is the same issue. If a user
>>>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>>>> party is still hearing the hold music. It is not working as intended where
>>>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>>>>> his deskphone 2 way voice should happen.
>>>>>>>
>>>>>>> My topology is as follows..
>>>>>>>
>>>>>>>
>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>
>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>>>> connect/snr.
>>>>>>>
>>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead
>>>>>>> of the hold music when the calls are picked up?
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/e3797ec4/attachment.html>

From kennethwhayes at gmail.com Tue Jan 15 15:42:17 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Tue, 15 Jan 2013 15:42:17 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
Message-ID: <3988242485236118541@unknownmsgid>

Bind your media and source to your outbound interface on your voice service
voip.

Sent from my iPhone

On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:

Below is a show run from the router

[OK]
Cisco3825#sh run
Building configuration...
Current configuration : 10183 bytes
!
! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco3825
!
boot-start-marker
boot-end-marker
!
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication login vpnauth local
aaa authorization exec default local
aaa authorization network default local
aaa authorization network vpnauth local
!
!
!
!
!
aaa session-id common
!
no network-clock-participate wic 0
!
dot11 syslog
ip source-route
!
ip cef
!
!
!
!
ip domain name datasc.local
ip inspect udp idle-time 1800
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
voice-card 0
dsp services dspfarm
!
!
!
voice service voip
ip address trusted list
ipv4 64.154.41.150 255.255.255.255
allow-connections sip to sip
fax protocol pass-through g711ulaw
sip
!
!
!
!
voice translation-rule 1
rule 1 /6784604564/ /200/
rule 2 /6784563290/ /100/
rule 3 /6784563291/ /101/
rule 4 /6784563292/ /102/
rule 5 /6784563293/ /103/
rule 6 /6784563294/ /104/
rule 7 /6784563295/ /105/
rule 8 /6784563296/ /106/
rule 9 /6784563297/ /107/
rule 10 /6784563298/ /108/
rule 11 /6784563299/ /109/
rule 12 /6784604565/ /125/
!
!
voice translation-profile incomingdid
translate called 1
!
!
crypto pki token default removal timeout 0
!
crypto pki trustpoint selfsigned
enrollment selfsigned
subject-name CN=connect.datasc.com
revocation-check crl
!
!
crypto pki certificate chain selfsigned
certificate self-signed 02
30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
quit
!
!
license udi pid CISCO3825 sn FTX1237A1T0
username xxxxxxx privilege 15 secret xxxxxx
!
redundancy
!
!
controller T1 0/0/0
!
controller T1 0/0/1
!
ip ssh version 2
!
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
crypto isakmp fragmentation
!
crypto isakmp client configuration group datasc
key Recoil90
dns 4.2.2.2 4.2.2.1
domain datasc.local
pool vpnpool
save-password
!
crypto isakmp client configuration group datascsplit
key Recoil90
dns 4.2.2.2 4.2.2.1
domain datasc.local
pool vpnpool
acl 101
save-password
crypto isakmp profile datasc
match identity group datasc
client authentication list vpnauth
isakmp authorization list vpnauth
client configuration address respond
virtual-template 1
crypto isakmp profile datascsplit
match identity group datascsplit
client authentication list vpnauth
isakmp authorization list vpnauth
client configuration address respond
virtual-template 2
!
!
crypto ipsec transform-set transformset esp-aes
crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set ezvpntransform
set isakmp-profile datasc
!
crypto ipsec profile VTI2
set transform-set ezvpntransform
set isakmp-profile datascsplit
!
!
!
!
!
!
!
interface Loopback1
ip address 10.1.150.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface GigabitEthernet0/0
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
hold-queue 240000 in
!
interface GigabitEthernet0/1
ip address 10.1.200.1 255.255.255.252
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
!
interface Virtual-Template1 type tunnel
ip unnumbered GigabitEthernet0/0
ip nat inside
ip virtual-reassembly in
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
!
interface Virtual-Template2 type tunnel
ip unnumbered GigabitEthernet0/0
ip nat inside
ip virtual-reassembly in
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI2
!
interface Virtual-Template3
ip unnumbered GigabitEthernet0/0
ip nat outside
ip virtual-reassembly in
ip policy route-map anyconnecthop
!
!
router eigrp 1
maximum-paths 1
network 10.0.0.0
redistribute static
!
ip local pool vpnpool 10.1.100.10 10.1.100.200
ip forward-protocol nd
ip http server
ip http secure-server
!
!
ip nat inside source list NATNETWORKS interface GigabitEthernet0/0 overload
ip nat inside source static tcp 10.1.50.150 80 interface GigabitEthernet0/0
80
ip nat inside source static tcp 10.1.80.100 5001 interface
GigabitEthernet0/0 5001
ip nat inside source static udp 10.1.80.100 5001 interface
GigabitEthernet0/0 5001
!
ip access-list extended NATNETWORKS
deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any
ip access-list extended anyconnecthop
deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any
!
access-list 50 permit 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.0.0.0 0.255.255.255 any
!
!
!
!
route-map anyconnecthop permit 10
match ip address anyconnecthop
set ip next-hop 10.1.150.2
!
!
!
!
!
control-plane
!
!
!
!
mgcp profile default
!
!
dial-peer voice 100 voip
description Publisher
preference 1
destination-pattern 1..
session protocol sipv2
session target ipv4:10.1.80.10
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 101 voip
description Subscriber
preference 2
destination-pattern 1..
session target ipv4:10.1.80.11
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 200 voip
description Publisher
preference 1
destination-pattern 2..
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target ipv4:10.1.80.10
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 300 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 678456329.
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 301 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 6784604565
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 302 voip
description incoming Calldid
translation-profile incoming incomingdid
preference 1
session protocol sipv2
session target sip-server
incoming called-number 6784604564
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 201 voip
description Publisher
preference 2
destination-pattern 2..
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target ipv4:10.1.80.11
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 500 voip
description outgoing
preference 1
destination-pattern .T
session protocol sipv2
session target dns:sip.talkinip.net
dtmf-relay rtp-nte
codec g711ulaw
!
!
sip-ua
credentials username xxxxxxxx password 7 xxxxxxx realm
sipconnect.ipcomms.net
authentication username xxxxxx password 7 xxxxxxx
authentication username xxxxx password 7 xxxxxxx realm
sipconnect.ipcomms.net
set pstn-cause 3 sip-status 486
set pstn-cause 34 sip-status 486
set pstn-cause 47 sip-status 486
registrar dns:sipconnect.ipcomms.net expires 60
sip-server dns:sipconnect.ipcomms.net:5060
!
!
!
gatekeeper
shutdown
!
!
call-manager-fallback
max-conferences 8 gain -6
transfer-system full-consult
ip source-address 10.1.200.1 port 2000
max-ephones 20
max-dn 40
!
!
!
line con 0
line aux 0
line vty 0 4
privilege level 15
transport input ssh
line vty 5 15
privilege level 15
transport input ssh
!
scheduler allocate 20000 1000
!
webvpn gateway gateway_1
ip interface GigabitEthernet0/0 port 443
ssl trustpoint selfsigned
inservice
!
webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg sequence 1
!
webvpn context datasc
title "DataSC VPN"
secondary-color white
title-color #CCCC66
text-color black
ssl authenticate verify all
!
url-list "Servers"
heading "Server"
!
!
policy group datasc
url-list "Servers"
functions svc-enabled
svc address-pool "vpnpool" netmask 255.255.255.0
svc keep-client-installed
svc dns-server primary 4.2.2.2
svc dtls
virtual-template 3
default-group-policy datasc
aaa authentication list vpnauth
gateway gateway_1 domain datasc
inservice
!
!
webvpn context datascsplit
title "DataSC VPN Split"
secondary-color white
title-color #CCCC66
text-color black
ssl authenticate verify all
!
url-list "Servers"
heading "Server"
!
!
policy group datascsplit
url-list "Servers"
functions svc-enabled
svc address-pool "vpnpool" netmask 255.255.255.0
svc split include acl 50
svc dns-server primary 4.2.2.2
svc dtls
default-group-policy datascsplit
aaa authentication list vpnauth
gateway gateway_1 domain datascsplit
inservice
!
end
Cisco3825#

On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> What do your media resources look like?


>
>
> Also can you show me a copy of your voice service voip config?
>
> Sent from my iPad
>
> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Thanks Ryan
>
> I see I am always getting a 200 ok message after my invites from the debug
>
> *Putting a call on HOLD*
>
>
>
> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 102 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>
> Content-Type: application/sdp
>
> Content-Length: 240
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 103 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281168
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Type: application/sdp
>
> Content-Length: 289
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101 19
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 102 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 103 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 103 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 239
>
> v=0
>
> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 102 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 253
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 103 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Length: 0
>
> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 102 ACK
>
> Allow-Events: presence
>
> Content-Length: 0
>
> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 103 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>
> Content-Length: 0
>
> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281168
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 103 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 104 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 104 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 103 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 103 ACK
>
> Allow-Events: presence
>
> Content-Type: application/sdp
>
> Content-Length: 209
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0
>
> a=X-cisco-media:nomedia
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:28 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 251
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 0.0.0.0
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 0.0.0.0
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
>
>
> *Unholding the call the MOH continues on the previously held caller while
> the user hears nothing*
>
> **
>
>
>
> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>
> Content-Length: 0
>
> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 105 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281175
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Allow-Events: presence, kpml
>
> Content-Type: application/sdp
>
> Content-Length: 243
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 10.1.10.18
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 105 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 265
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> Cisco3825#
>
> Cisco3825#
>
>
>
> Cisco3825#
>
>
>
> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Supported: timer,resource-priority,replaces
>
> Min-SE: 1800
>
> User-Agent: Cisco-CUCM8.6
>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY
>
> CSeq: 104 INVITE
>
> Max-Forwards: 70
>
> Expires: 180
>
> Allow-Events: presence
>
> Supported: X-cisco-srtp-fallback
>
> Supported: Geolocation
>
> Session-Expires: 1800;refresher=uas
>
> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>
> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;party=calling;screen=yes;privacy=off
>
> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>
> Content-Length: 0
>
> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Supported: timer,resource-priority,replaces,sdp-anat
>
> Min-SE: 1800
>
> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>
> User-Agent: Cisco-SIPGateway/IOS-12.x
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> CSeq: 105 INVITE
>
> Max-Forwards: 70
>
> Timestamp: 1358281175
>
> Contact: <sip:6784563290 at 98.192.104.214:5060>
>
> Expires: 180
>
> Allow-Events: telephone-event
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Session-Expires: 1800;refresher=uas
>
> Content-Length: 0
>
> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow-Events: telephone-event
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 100 Trying
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Length: 0
>
> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP 98.192.104.214:5060
> ;branch=z9hG4bK69232672;received=98.192.104.214
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> CSeq: 105 INVITE
>
> Server: Asterisk PBX 1.6.2.13
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>
> Supported: replaces, timer
>
> Require: timer
>
> Session-Expires: 1800;refresher=uas
>
> Contact: <sip:17705439047 at 64.154.41.150>
>
> Content-Type: application/sdp
>
> Content-Length: 333
>
> v=0
>
> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>
> s=Asterisk PBX 1.6.2.13
>
> c=IN IP4 64.154.41.150
>
> t=0 0
>
> m=audio 13014 RTP/AVP 3 8 0 18 101
>
> a=rtpmap:3 GSM/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> a=inactive
>
> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> CSeq: 104 INVITE
>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
>
> Allow-Events: telephone-event
>
> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
> >;party=called;screen=no;privacy=off
>
> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>
> Supported: replaces
>
> Supported: sdp-anat
>
> Server: Cisco-SIPGateway/IOS-12.x
>
> Session-Expires: 1800;refresher=uas
>
> Require: timer
>
> Supported: timer
>
> Content-Type: application/sdp
>
> Content-Length: 277
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>
> s=SIP Call
>
> c=IN IP4 10.1.200.1
>
> t=0 0
>
> m=audio 19514 RTP/AVP 0 101 19
>
> c=IN IP4 10.1.200.1
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=rtpmap:19 CN/8000
>
> a=ptime:20
>
> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>
> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>
> Date: Tue, 15 Jan 2013 19:57:42 GMT
>
> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>
> Max-Forwards: 70
>
> CSeq: 104 ACK
>
> Allow-Events: presence, kpml
>
> Content-Type: application/sdp
>
> Content-Length: 243
>
> v=0
>
> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>
> s=SIP Call
>
> c=IN IP4 10.1.10.18
>
> b=TIAS:64000
>
> b=AS:64
>
> t=0 0
>
> m=audio 21476 RTP/AVP 0 101
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=inactive
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>
> Sent:
>
> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>
> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
> >;tag=2E6BC0B0-2268
>
> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>
> Date: Tue, 15 Jan 2013 20:19:35 GMT
>
> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>
> Max-Forwards: 70
>
> CSeq: 105 ACK
>
> Authorization: Digest username="6784563290",realm="asterisk",uri="
> sip:17705439047 at 64.154.41.150:5060
> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>
> Allow-Events: telephone-event
>
> Content-Type: application/sdp
>
> Content-Length: 265
>
> v=0
>
> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>
> s=SIP Call
>
> c=IN IP4 98.192.104.214
>
> t=0 0
>
> m=audio 19458 RTP/AVP 0 101
>
> c=IN IP4 98.192.104.214
>
> a=inactive
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-16
>
> a=ptime:20
>
> Cisco3825#
>
>
> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> ccsip message is what I'd go with just to see the signaling with no other
>> stuff. Depending on what that shows and what your gateway is doing to the
>> signals you may need to expand from there.
>>
>> -Ryan
>>
>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Ryan
>>
>> What is the proper debug to use to caputre the useful information?
>>
>> Dane
>>
>>
>>
>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>
>>> Without sip messages I can't get any clues from that.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Thanks Ryan for the input
>>>
>>>
>>> *On the call when I hold the call the following debug pops out....*
>>>
>>>
>>> *Jan 15 17:56:05.246:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> *Jan 15 17:56:05.274:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> *Jan 15 17:56:05.286:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> *Jan 15 17:56:05.302:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:05.322:
>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>> params for midcall INVITE
>>>
>>> *After I try to unhold the call the following debug comes out....*
>>> **
>>>
>>> *Jan 15 17:56:18.874:
>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>> passthru hdrs to
>>> container
>>> *Jan 15 17:56:18.894:
>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not
>>> found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:18.906:
>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>> params for midcall INVITE
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> Given you have an ITSP it's most likely the initial hold that's
>>>> failing, which is only manifesting when you try to resume it. If you
>>>> haven't noticed already this is also very likely causing transfers to fail.
>>>>
>>>> Take a look at the SIP signaling for a call. I believe the most
>>>> common cause to this is the ITSP not handling our transition from
>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> *Hello Kenneth*
>>>> **
>>>> *I have restarted both CUCM servers so this should have restarted the
>>>> services when the utils system restart happened*
>>>> **
>>>>
>>>> *on my router I see I am using g711 from the debug *
>>>> **
>>>> *I ran a debug voip ccapi inout *
>>>> **
>>>> *I connected a call calling from an external number to a DiD inside of
>>>> my system. Once the call was connected I put the call on hold and the
>>>> following debug came out..the music on hold played for the external caller
>>>> *
>>>>
>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.783:
>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.783:
>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12742
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12741
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=96, Call Id=12742
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.839:
>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.839:
>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12741
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12742
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> Cisco3825#
>>>> Cisco3825#
>>>> Cisco3825#
>>>>
>>>>
>>>> *I then after that took off the hold and the following debug came
>>>> out. The call on the PSDN side still played the hold music while there was
>>>> no voice on the deskphone side.*
>>>>
>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.783:
>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.783:
>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12742
>>>> *Jan 14 23:47:40.783:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12741
>>>> *Jan 14 23:47:40.811:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=96, Call Id=12742
>>>> *Jan 14 23:47:40.819:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.839:
>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>> *Jan 14 23:47:40.839:
>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=170, Call Id=12741
>>>> *Jan 14 23:47:40.843:
>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>> Call Id=12742,
>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>> Call Id=12741,
>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event=171, Call Id=12742
>>>> *Jan 14 23:47:40.863:
>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>> Interface=0xC05A65AC, Call Id=12742
>>>> Cisco3825#
>>>> Cisco3825#
>>>> Cisco3825#
>>>>
>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>> hard coded it with me when I was initially setting it up.
>>>>>
>>>>> Do you think this could be a codec issue? How would I go about
>>>>> identifying if it is?
>>>>>
>>>>> Dane
>>>>>
>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>> kennethwhayes at gmail.com> wrote:
>>>>>
>>>>>> Have you tried different audio codecs?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>
>>>>>> Thanks for the Reply
>>>>>> Oddly enough we are.
>>>>>> This probably has something to do with MOH in general?
>>>>>>
>>>>>> Internally when I user puts another user on hold everything works. No
>>>>>> MOH plays and they can hold and unhold the call just fine.
>>>>>> I tested calling from an external number. Once I put the external
>>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>>>> there was no sound on the deskphone.
>>>>>>
>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>> outside SNR features?
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Using keyboard-interactive authentication.
>>>>>>>
>>>>>>> Password:
>>>>>>>
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> Cisco3825#sh ver
>>>>>>>
>>>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>>>> Version 15.1
>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>
>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>
>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>
>>>>>>>
>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>>>
>>>>>>>
>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>
>>>>>>> System returned to ROM by power-on
>>>>>>>
>>>>>>> System image file is
>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>> Last reload type: Normal Reload
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This product contains cryptographic features and is subject to
>>>>>>> United
>>>>>>> States and local country laws governing import, export, transfer and
>>>>>>>
>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>
>>>>>>> third-party authority to import, export, distribute or use
>>>>>>> encryption.
>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>
>>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>>> you
>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>> unable
>>>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>>>
>>>>>>>
>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may be
>>>>>>> found at:
>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>
>>>>>>> If you require further assistance please contact us by sending email
>>>>>>> to
>>>>>>> export at cisco.com.
>>>>>>>
>>>>>>>
>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>
>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>
>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>
>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>
>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>
>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>
>>>>>>> 479K bytes of NVRAM.
>>>>>>>
>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> License Info:
>>>>>>>
>>>>>>>
>>>>>>> License UDI:
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------
>>>>>>>
>>>>>>> Device# PID SN
>>>>>>>
>>>>>>> Sent from my mobile device
>>>>>>>
>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> What version of code are you running on the CUBE?
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>> system rings on the mobile number configured in the system. When they pick
>>>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>
>>>>>>> In another senario with what I believe is the same issue. If a user
>>>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>>>> on his deskphone the calling party starts hearing the hold music. Once the
>>>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>>>> party is still hearing the hold music. It is not working as intended where
>>>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up on
>>>>>>> his deskphone 2 way voice should happen.
>>>>>>>
>>>>>>> My topology is as follows..
>>>>>>>
>>>>>>>
>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>
>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>>>> connect/snr.
>>>>>>>
>>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead
>>>>>>> of the hold music when the calls are picked up?
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/fe8134b6/attachment.html>

From svoll.voip at gmail.com Tue Jan 15 16:57:01 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Tue, 15 Jan 2013 13:57:01 -0800
Subject: [cisco-voip] 2960s-48fps-l flex stack
In-Reply-To: <CAHgd+3_H1PcGKB06TWvwZOkDMFm7736Tfw2Od0Pb8tPSB3Mr7g@mail.gmail.com>
References: <CAHgd+3_H1PcGKB06TWvwZOkDMFm7736Tfw2Od0Pb8tPSB3Mr7g@mail.gmail.com>
Message-ID: <CAHgd+388knMf13LGphBRqgEkkZgiy8TC15QOpbgtpmq0a6LrRA@mail.gmail.com>

Well I have been just informed that there are two different stacking
modules.

c2960S-F-Stack
and
c2960S-Stack Notice the lack of the letter "F"

the F is for the 10/100 switches and the Non-F is for the Gig switches.

you can still stack 100 and gig together, they just take different modules.

Oh, and by the way the non-F is about twice the price of the F.

I won't make any comments on the letter......

Scott

On Mon, Jan 14, 2013 at 3:45 PM, Scott Voll <svoll.voip at gmail.com> wrote:

> I have a 2960s-48fps-l and when I inserted the flex stack module I get:
>
> %PLATFORM-6-FLEXSTACK_UNSUPPORTED_MODULE: Unsupported FlexStack module
> inserted in Switch 1. C2960S-F-STACK
>
> Is this not supported? I'm running 15.0.2se1. How do I get it talking to
> the other switches?
>
> TIA
>
> Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/861554d9/attachment.html>

From matthnick at gmail.com Tue Jan 15 19:56:17 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Tue, 15 Jan 2013 19:56:17 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <3988242485236118541@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
Message-ID: <CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>

It looks like CUCM isn't setting the stream back to active after putting it
on hold. It sends the re-invite, and the 200 OK from the ITSP has the SDP
continued with a=inactive.

I don't have some good traces in front of me, but somewhere it needs to
take that off. I don't think Asterisks is acting incorrectly by responding
to a delayed offer INVITE that was previously a=inactive with a=inactive.

What's also odd is that CUCM is sending the exact same INVITE after the
first one completes, for both the hold and the resume. The CSeq isn't
increasing, which I would expect it to.

If you were to check 'MTP' required it may work around the problem, but I
don't consider inserting MTP's to be a best practice.

-nick

On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Bind your media and source to your outbound interface on your voice
> service voip.
>
> Sent from my iPhone
>
> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Below is a show run from the router
>
>
> [OK]
> Cisco3825#sh run
> Building configuration...
>
> Current configuration : 10183 bytes
> !
> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
> version 15.1
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> !
> hostname Cisco3825
> !
> boot-start-marker
> boot-end-marker
> !
> !
> !
> aaa new-model
> !
> !
> aaa authentication login default local
> aaa authentication login vpnauth local
> aaa authorization exec default local
> aaa authorization network default local
> aaa authorization network vpnauth local
> !
> !
> !
> !
> !
> aaa session-id common
> !
> no network-clock-participate wic 0
> !
> dot11 syslog
> ip source-route
> !
> ip cef
> !
> !
> !
> !
> ip domain name datasc.local
> ip inspect udp idle-time 1800
> no ipv6 cef
> !
> multilink bundle-name authenticated
> !
> !
> !
> !
> !
> voice-card 0
> dsp services dspfarm
> !
> !
> !
> voice service voip
> ip address trusted list
> ipv4 64.154.41.150 255.255.255.255
> allow-connections sip to sip
> fax protocol pass-through g711ulaw
> sip
> !
> !
> !
> !
> voice translation-rule 1
> rule 1 /6784604564/ /200/
> rule 2 /6784563290/ /100/
> rule 3 /6784563291/ /101/
> rule 4 /6784563292/ /102/
> rule 5 /6784563293/ /103/
> rule 6 /6784563294/ /104/
> rule 7 /6784563295/ /105/
> rule 8 /6784563296/ /106/
> rule 9 /6784563297/ /107/
> rule 10 /6784563298/ /108/
> rule 11 /6784563299/ /109/
> rule 12 /6784604565/ /125/
> !
> !
> voice translation-profile incomingdid
> translate called 1
> !
> !
> crypto pki token default removal timeout 0
> !
> crypto pki trustpoint selfsigned
> enrollment selfsigned
> subject-name CN=connect.datasc.com
> revocation-check crl
> !
> !
> crypto pki certificate chain selfsigned
> certificate self-signed 02
> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
> quit
> !
> !
> license udi pid CISCO3825 sn FTX1237A1T0
> username xxxxxxx privilege 15 secret xxxxxx
> !
> redundancy
> !
> !
> controller T1 0/0/0
> !
> controller T1 0/0/1
> !
> ip ssh version 2
> !
> !
> crypto isakmp policy 10
> encr aes
> authentication pre-share
> group 2
> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
> crypto isakmp fragmentation
> !
> crypto isakmp client configuration group datasc
> key Recoil90
> dns 4.2.2.2 4.2.2.1
> domain datasc.local
> pool vpnpool
> save-password
> !
> crypto isakmp client configuration group datascsplit
> key Recoil90
> dns 4.2.2.2 4.2.2.1
> domain datasc.local
> pool vpnpool
> acl 101
> save-password
> crypto isakmp profile datasc
> match identity group datasc
> client authentication list vpnauth
> isakmp authorization list vpnauth
> client configuration address respond
> virtual-template 1
> crypto isakmp profile datascsplit
> match identity group datascsplit
> client authentication list vpnauth
> isakmp authorization list vpnauth
> client configuration address respond
> virtual-template 2
> !
> !
> crypto ipsec transform-set transformset esp-aes
> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
> !
> crypto ipsec profile VTI
> set transform-set ezvpntransform
> set isakmp-profile datasc
> !
> crypto ipsec profile VTI2
> set transform-set ezvpntransform
> set isakmp-profile datascsplit
> !
> !
> !
> !
> !
> !
> !
> interface Loopback1
> ip address 10.1.150.1 255.255.255.0
> ip nat inside
> ip virtual-reassembly in
> !
> interface GigabitEthernet0/0
> ip address dhcp
> no ip redirects
> no ip unreachables
> no ip proxy-arp
> ip nat outside
> ip virtual-reassembly in
> duplex auto
> speed auto
> media-type rj45
> hold-queue 240000 in
> !
> interface GigabitEthernet0/1
> ip address 10.1.200.1 255.255.255.252
> ip nat inside
> ip virtual-reassembly in
> duplex auto
> speed auto
> media-type rj45
> !
> interface Virtual-Template1 type tunnel
> ip unnumbered GigabitEthernet0/0
> ip nat inside
> ip virtual-reassembly in
> tunnel source GigabitEthernet0/0
> tunnel mode ipsec ipv4
> tunnel protection ipsec profile VTI
> !
> interface Virtual-Template2 type tunnel
> ip unnumbered GigabitEthernet0/0
> ip nat inside
> ip virtual-reassembly in
> tunnel source GigabitEthernet0/0
> tunnel mode ipsec ipv4
> tunnel protection ipsec profile VTI2
> !
> interface Virtual-Template3
> ip unnumbered GigabitEthernet0/0
> ip nat outside
> ip virtual-reassembly in
> ip policy route-map anyconnecthop
> !
> !
> router eigrp 1
> maximum-paths 1
> network 10.0.0.0
> redistribute static
> !
> ip local pool vpnpool 10.1.100.10 10.1.100.200
> ip forward-protocol nd
> ip http server
> ip http secure-server
> !
> !
> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0 overload
> ip nat inside source static tcp 10.1.50.150 80 interface
> GigabitEthernet0/0 80
> ip nat inside source static tcp 10.1.80.100 5001 interface
> GigabitEthernet0/0 5001
> ip nat inside source static udp 10.1.80.100 5001 interface
> GigabitEthernet0/0 5001
> !
> ip access-list extended NATNETWORKS
> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
> permit ip 10.0.0.0 0.255.255.255 any
> ip access-list extended anyconnecthop
> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
> permit ip 10.0.0.0 0.255.255.255 any
> !
> access-list 50 permit 10.0.0.0 0.255.255.255
> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
> !
> !
> !
> !
> route-map anyconnecthop permit 10
> match ip address anyconnecthop
> set ip next-hop 10.1.150.2
> !
> !
> !
> !
> !
> control-plane
> !
> !
> !
> !
> mgcp profile default
> !
> !
> dial-peer voice 100 voip
> description Publisher
> preference 1
> destination-pattern 1..
> session protocol sipv2
> session target ipv4:10.1.80.10
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 101 voip
> description Subscriber
> preference 2
> destination-pattern 1..
> session target ipv4:10.1.80.11
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 200 voip
> description Publisher
> preference 1
> destination-pattern 2..
> progress_ind setup enable 3
> progress_ind progress enable 8
> session protocol sipv2
> session target ipv4:10.1.80.10
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 300 voip
> description incoming Calldid
> translation-profile incoming incomingdid
> preference 1
> session protocol sipv2
> session target sip-server
> incoming called-number 678456329.
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 301 voip
> description incoming Calldid
> translation-profile incoming incomingdid
> preference 1
> session protocol sipv2
> session target sip-server
> incoming called-number 6784604565
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 302 voip
> description incoming Calldid
> translation-profile incoming incomingdid
> preference 1
> session protocol sipv2
> session target sip-server
> incoming called-number 6784604564
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 201 voip
> description Publisher
> preference 2
> destination-pattern 2..
> progress_ind setup enable 3
> progress_ind progress enable 8
> session protocol sipv2
> session target ipv4:10.1.80.11
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> dial-peer voice 500 voip
> description outgoing
> preference 1
> destination-pattern .T
> session protocol sipv2
> session target dns:sip.talkinip.net
> dtmf-relay rtp-nte
> codec g711ulaw
> !
> !
> sip-ua
> credentials username xxxxxxxx password 7 xxxxxxx realm
> sipconnect.ipcomms.net
> authentication username xxxxxx password 7 xxxxxxx
> authentication username xxxxx password 7 xxxxxxx realm
> sipconnect.ipcomms.net
> set pstn-cause 3 sip-status 486
> set pstn-cause 34 sip-status 486
> set pstn-cause 47 sip-status 486
> registrar dns:sipconnect.ipcomms.net expires 60
> sip-server dns:sipconnect.ipcomms.net:5060
> !
> !
> !
> gatekeeper
> shutdown
> !
> !
> call-manager-fallback
> max-conferences 8 gain -6
> transfer-system full-consult
> ip source-address 10.1.200.1 port 2000
> max-ephones 20
> max-dn 40
> !
> !
> !
> line con 0
> line aux 0
> line vty 0 4
> privilege level 15
> transport input ssh
> line vty 5 15
> privilege level 15
> transport input ssh
> !
> scheduler allocate 20000 1000
> !
> webvpn gateway gateway_1
> ip interface GigabitEthernet0/0 port 443
> ssl trustpoint selfsigned
> inservice
> !
> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg sequence
> 1
> !
> webvpn context datasc
> title "DataSC VPN"
> secondary-color white
> title-color #CCCC66
> text-color black
> ssl authenticate verify all
> !
> url-list "Servers"
> heading "Server"
> !
> !
> policy group datasc
> url-list "Servers"
> functions svc-enabled
> svc address-pool "vpnpool" netmask 255.255.255.0
> svc keep-client-installed
> svc dns-server primary 4.2.2.2
> svc dtls
> virtual-template 3
> default-group-policy datasc
> aaa authentication list vpnauth
> gateway gateway_1 domain datasc
> inservice
> !
> !
> webvpn context datascsplit
> title "DataSC VPN Split"
> secondary-color white
> title-color #CCCC66
> text-color black
> ssl authenticate verify all
> !
> url-list "Servers"
> heading "Server"
> !
> !
> policy group datascsplit
> url-list "Servers"
> functions svc-enabled
> svc address-pool "vpnpool" netmask 255.255.255.0
> svc split include acl 50
> svc dns-server primary 4.2.2.2
> svc dtls
> default-group-policy datascsplit
> aaa authentication list vpnauth
> gateway gateway_1 domain datascsplit
> inservice
> !
> end
> Cisco3825#
>
> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>
>> What do your media resources look like?
>>
>>
>> Also can you show me a copy of your voice service voip config?
>>
>> Sent from my iPad
>>
>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Thanks Ryan
>>
>> I see I am always getting a 200 ok message after my invites from the debug
>>
>> *Putting a call on HOLD*
>>
>>
>>
>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Supported: timer,resource-priority,replaces
>>
>> Min-SE: 1800
>>
>> User-Agent: Cisco-CUCM8.6
>>
>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY
>>
>> CSeq: 102 INVITE
>>
>> Max-Forwards: 70
>>
>> Expires: 180
>>
>> Allow-Events: presence
>>
>> Supported: X-cisco-srtp-fallback
>>
>> Supported: Geolocation
>>
>> Session-Expires: 1800;refresher=uas
>>
>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>
>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;party=calling;screen=yes;privacy=off
>>
>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 240
>>
>> v=0
>>
>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>
>> s=SIP Call
>>
>> c=IN IP4 0.0.0.0
>>
>> b=TIAS:64000
>>
>> b=AS:64
>>
>> t=0 0
>>
>> m=audio 21476 RTP/AVP 0 101
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-15
>>
>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>
>> Min-SE: 1800
>>
>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>
>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> CSeq: 103 INVITE
>>
>> Max-Forwards: 70
>>
>> Timestamp: 1358281168
>>
>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>
>> Expires: 180
>>
>> Allow-Events: telephone-event
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 289
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>
>> s=SIP Call
>>
>> c=IN IP4 98.192.104.214
>>
>> t=0 0
>>
>> m=audio 19458 RTP/AVP 0 101 19
>>
>> c=IN IP4 98.192.104.214
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-15
>>
>> a=rtpmap:19 CN/8000
>>
>> a=ptime:20
>>
>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 102 INVITE
>>
>> Allow-Events: telephone-event
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 103 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 103 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 239
>>
>> v=0
>>
>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>
>> s=Asterisk PBX 1.6.2.13
>>
>> c=IN IP4 64.154.41.150
>>
>> t=0 0
>>
>> m=audio 13014 RTP/AVP 0 101
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 102 INVITE
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> Allow-Events: telephone-event
>>
>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>> >;party=called;screen=no;privacy=off
>>
>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>
>> Supported: replaces
>>
>> Supported: sdp-anat
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Require: timer
>>
>> Supported: timer
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 253
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.200.1
>>
>> t=0 0
>>
>> m=audio 19514 RTP/AVP 0 101
>>
>> c=IN IP4 10.1.200.1
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Max-Forwards: 70
>>
>> CSeq: 103 ACK
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Allow-Events: telephone-event
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Max-Forwards: 70
>>
>> CSeq: 102 ACK
>>
>> Allow-Events: presence
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Supported: timer,resource-priority,replaces
>>
>> Min-SE: 1800
>>
>> User-Agent: Cisco-CUCM8.6
>>
>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY
>>
>> CSeq: 103 INVITE
>>
>> Max-Forwards: 70
>>
>> Expires: 180
>>
>> Allow-Events: presence
>>
>> Supported: X-cisco-srtp-fallback
>>
>> Supported: Geolocation
>>
>> Session-Expires: 1800;refresher=uas
>>
>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>
>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;party=calling;screen=yes;privacy=off
>>
>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Supported: timer,resource-priority,replaces,sdp-anat
>>
>> Min-SE: 1800
>>
>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>
>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> CSeq: 104 INVITE
>>
>> Max-Forwards: 70
>>
>> Timestamp: 1358281168
>>
>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>
>> Expires: 180
>>
>> Allow-Events: telephone-event
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 103 INVITE
>>
>> Allow-Events: telephone-event
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 104 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 104 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 333
>>
>> v=0
>>
>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>
>> s=Asterisk PBX 1.6.2.13
>>
>> c=IN IP4 64.154.41.150
>>
>> t=0 0
>>
>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>
>> a=rtpmap:3 GSM/8000
>>
>> a=rtpmap:8 PCMA/8000
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:18 G729/8000
>>
>> a=fmtp:18 annexb=no
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 103 INVITE
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> Allow-Events: telephone-event
>>
>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>> >;party=called;screen=no;privacy=off
>>
>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>
>> Supported: replaces
>>
>> Supported: sdp-anat
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Require: timer
>>
>> Supported: timer
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 277
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.200.1
>>
>> t=0 0
>>
>> m=audio 19514 RTP/AVP 0 101 19
>>
>> c=IN IP4 10.1.200.1
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=rtpmap:19 CN/8000
>>
>> a=ptime:20
>>
>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Max-Forwards: 70
>>
>> CSeq: 103 ACK
>>
>> Allow-Events: presence
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 209
>>
>> v=0
>>
>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>
>> s=SIP Call
>>
>> c=IN IP4 0.0.0.0
>>
>> b=TIAS:64000
>>
>> b=AS:64
>>
>> t=0 0
>>
>> m=audio 21476 RTP/AVP 0
>>
>> a=X-cisco-media:nomedia
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Max-Forwards: 70
>>
>> CSeq: 104 ACK
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Allow-Events: telephone-event
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 251
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>
>> s=SIP Call
>>
>> c=IN IP4 0.0.0.0
>>
>> t=0 0
>>
>> m=audio 19458 RTP/AVP 0 101
>>
>> c=IN IP4 0.0.0.0
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>>
>>
>> *Unholding the call the MOH continues on the previously held caller
>> while the user hears nothing*
>>
>> **
>>
>>
>>
>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Supported: timer,resource-priority,replaces
>>
>> Min-SE: 1800
>>
>> User-Agent: Cisco-CUCM8.6
>>
>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY
>>
>> CSeq: 104 INVITE
>>
>> Max-Forwards: 70
>>
>> Expires: 180
>>
>> Allow-Events: presence
>>
>> Supported: X-cisco-srtp-fallback
>>
>> Supported: Geolocation
>>
>> Session-Expires: 1800;refresher=uas
>>
>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>
>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;party=calling;screen=yes;privacy=off
>>
>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Supported: timer,resource-priority,replaces,sdp-anat
>>
>> Min-SE: 1800
>>
>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>
>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> CSeq: 105 INVITE
>>
>> Max-Forwards: 70
>>
>> Timestamp: 1358281175
>>
>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>
>> Expires: 180
>>
>> Allow-Events: telephone-event
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 104 INVITE
>>
>> Allow-Events: telephone-event
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 105 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 105 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 333
>>
>> v=0
>>
>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>
>> s=Asterisk PBX 1.6.2.13
>>
>> c=IN IP4 64.154.41.150
>>
>> t=0 0
>>
>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>
>> a=rtpmap:3 GSM/8000
>>
>> a=rtpmap:8 PCMA/8000
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:18 G729/8000
>>
>> a=fmtp:18 annexb=no
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 104 INVITE
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> Allow-Events: telephone-event
>>
>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>> >;party=called;screen=no;privacy=off
>>
>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>
>> Supported: replaces
>>
>> Supported: sdp-anat
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Require: timer
>>
>> Supported: timer
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 277
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.200.1
>>
>> t=0 0
>>
>> m=audio 19514 RTP/AVP 0 101 19
>>
>> c=IN IP4 10.1.200.1
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=rtpmap:19 CN/8000
>>
>> a=ptime:20
>>
>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Max-Forwards: 70
>>
>> CSeq: 104 ACK
>>
>> Allow-Events: presence, kpml
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 243
>>
>> v=0
>>
>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.10.18
>>
>> b=TIAS:64000
>>
>> b=AS:64
>>
>> t=0 0
>>
>> m=audio 21476 RTP/AVP 0 101
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-15
>>
>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Max-Forwards: 70
>>
>> CSeq: 105 ACK
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Allow-Events: telephone-event
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 265
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>
>> s=SIP Call
>>
>> c=IN IP4 98.192.104.214
>>
>> t=0 0
>>
>> m=audio 19458 RTP/AVP 0 101
>>
>> c=IN IP4 98.192.104.214
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> Cisco3825#
>>
>> Cisco3825#
>>
>>
>>
>> Cisco3825#
>>
>>
>>
>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Supported: timer,resource-priority,replaces
>>
>> Min-SE: 1800
>>
>> User-Agent: Cisco-CUCM8.6
>>
>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY
>>
>> CSeq: 104 INVITE
>>
>> Max-Forwards: 70
>>
>> Expires: 180
>>
>> Allow-Events: presence
>>
>> Supported: X-cisco-srtp-fallback
>>
>> Supported: Geolocation
>>
>> Session-Expires: 1800;refresher=uas
>>
>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>
>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;party=calling;screen=yes;privacy=off
>>
>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Supported: timer,resource-priority,replaces,sdp-anat
>>
>> Min-SE: 1800
>>
>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>
>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> CSeq: 105 INVITE
>>
>> Max-Forwards: 70
>>
>> Timestamp: 1358281175
>>
>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>
>> Expires: 180
>>
>> Allow-Events: telephone-event
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 104 INVITE
>>
>> Allow-Events: telephone-event
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 100 Trying
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 105 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Length: 0
>>
>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060
>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> CSeq: 105 INVITE
>>
>> Server: Asterisk PBX 1.6.2.13
>>
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>
>> Supported: replaces, timer
>>
>> Require: timer
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Contact: <sip:17705439047 at 64.154.41.150>
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 333
>>
>> v=0
>>
>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>
>> s=Asterisk PBX 1.6.2.13
>>
>> c=IN IP4 64.154.41.150
>>
>> t=0 0
>>
>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>
>> a=rtpmap:3 GSM/8000
>>
>> a=rtpmap:8 PCMA/8000
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:18 G729/8000
>>
>> a=fmtp:18 annexb=no
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> SIP/2.0 200 OK
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> CSeq: 104 INVITE
>>
>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>
>> Allow-Events: telephone-event
>>
>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>> >;party=called;screen=no;privacy=off
>>
>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>
>> Supported: replaces
>>
>> Supported: sdp-anat
>>
>> Server: Cisco-SIPGateway/IOS-12.x
>>
>> Session-Expires: 1800;refresher=uas
>>
>> Require: timer
>>
>> Supported: timer
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 277
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.200.1
>>
>> t=0 0
>>
>> m=audio 19514 RTP/AVP 0 101 19
>>
>> c=IN IP4 10.1.200.1
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=rtpmap:19 CN/8000
>>
>> a=ptime:20
>>
>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>
>> Received:
>>
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>
>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>
>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>
>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>
>> Max-Forwards: 70
>>
>> CSeq: 104 ACK
>>
>> Allow-Events: presence, kpml
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 243
>>
>> v=0
>>
>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>
>> s=SIP Call
>>
>> c=IN IP4 10.1.10.18
>>
>> b=TIAS:64000
>>
>> b=AS:64
>>
>> t=0 0
>>
>> m=audio 21476 RTP/AVP 0 101
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=ptime:20
>>
>> a=inactive
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-15
>>
>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>
>> Sent:
>>
>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>
>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>
>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>> >;tag=2E6BC0B0-2268
>>
>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>
>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>
>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>
>> Max-Forwards: 70
>>
>> CSeq: 105 ACK
>>
>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>> sip:17705439047 at 64.154.41.150:5060
>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>
>> Allow-Events: telephone-event
>>
>> Content-Type: application/sdp
>>
>> Content-Length: 265
>>
>> v=0
>>
>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>
>> s=SIP Call
>>
>> c=IN IP4 98.192.104.214
>>
>> t=0 0
>>
>> m=audio 19458 RTP/AVP 0 101
>>
>> c=IN IP4 98.192.104.214
>>
>> a=inactive
>>
>> a=rtpmap:0 PCMU/8000
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> a=fmtp:101 0-16
>>
>> a=ptime:20
>>
>> Cisco3825#
>>
>>
>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> ccsip message is what I'd go with just to see the signaling with no
>>> other stuff. Depending on what that shows and what your gateway is doing
>>> to the signals you may need to expand from there.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Ryan
>>>
>>> What is the proper debug to use to caputre the useful information?
>>>
>>> Dane
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> Without sip messages I can't get any clues from that.
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>> wrote:
>>>>
>>>> Thanks Ryan for the input
>>>>
>>>>
>>>> *On the call when I hold the call the following debug pops out....*
>>>>
>>>>
>>>> *Jan 15 17:56:05.246:
>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>> passthru hdrs to
>>>> container
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1
>>>> not found.
>>>> *Jan 15 17:56:05.274:
>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>> passthru headers to container
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>> not found.
>>>> *Jan 15 17:56:05.286:
>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>> passthru hdrs to
>>>> container
>>>> *Jan 15 17:56:05.302:
>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>> passthru headers to container
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>> not found.
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> *Jan 15 17:56:05.322:
>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>> params for midcall INVITE
>>>>
>>>> *After I try to unhold the call the following debug comes out....*
>>>> **
>>>>
>>>> *Jan 15 17:56:18.874:
>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>> passthru hdrs to
>>>> container
>>>> *Jan 15 17:56:18.894:
>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>> passthru headers to container
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>> not found.
>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>> *Jan 15 17:56:18.906:
>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>> params for midcall INVITE
>>>> Cisco3825#
>>>> Cisco3825#
>>>> Cisco3825#
>>>>
>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>
>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>> haven't noticed already this is also very likely causing transfers to fail.
>>>>>
>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>> common cause to this is the ITSP not handling our transition from
>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> *Hello Kenneth*
>>>>> **
>>>>> *I have restarted both CUCM servers so this should have restarted the
>>>>> services when the utils system restart happened*
>>>>> **
>>>>>
>>>>> *on my router I see I am using g711 from the debug *
>>>>> **
>>>>> *I ran a debug voip ccapi inout *
>>>>> **
>>>>> *I connected a call calling from an external number to a DiD inside
>>>>> of my system. Once the call was connected I put the call on hold and the
>>>>> following debug came out..the music on hold played for the external caller
>>>>> *
>>>>>
>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>> *Jan 14 23:47:40.783:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>>> *Jan 14 23:47:40.783:
>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>> *Jan 14 23:47:40.783:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=170, Call Id=12742
>>>>> *Jan 14 23:47:40.783:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.811:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=171, Call Id=12741
>>>>> *Jan 14 23:47:40.811:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>> *Jan 14 23:47:40.819:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=96, Call Id=12742
>>>>> *Jan 14 23:47:40.819:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.839:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>>> *Jan 14 23:47:40.839:
>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.843:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=170, Call Id=12741
>>>>> *Jan 14 23:47:40.843:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>> *Jan 14 23:47:40.863:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=171, Call Id=12742
>>>>> *Jan 14 23:47:40.863:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>>
>>>>>
>>>>> *I then after that took off the hold and the following debug came
>>>>> out. The call on the PSDN side still played the hold music while there was
>>>>> no voice on the deskphone side.*
>>>>>
>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>> *Jan 14 23:47:40.783:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742, Xmit Function=0x64204BAC
>>>>> *Jan 14 23:47:40.783:
>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>> *Jan 14 23:47:40.783:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=170, Call Id=12742
>>>>> *Jan 14 23:47:40.783:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.811:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=171, Call Id=12741
>>>>> *Jan 14 23:47:40.811:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>> *Jan 14 23:47:40.819:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=96, Call Id=12742
>>>>> *Jan 14 23:47:40.819:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.839:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741, Xmit Function=0x64204BAC
>>>>> *Jan 14 23:47:40.839:
>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>> *Jan 14 23:47:40.843:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=170, Call Id=12741
>>>>> *Jan 14 23:47:40.843:
>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source
>>>>> Call Id=12742,
>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source
>>>>> Call Id=12741,
>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>> *Jan 14 23:47:40.863:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event=171, Call Id=12742
>>>>> *Jan 14 23:47:40.863:
>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>>
>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>> kennethwhayes at gmail.com> wrote:
>>>>>
>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>>> hard coded it with me when I was initially setting it up.
>>>>>>
>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>> identifying if it is?
>>>>>>
>>>>>> Dane
>>>>>>
>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>
>>>>>>> Have you tried different audio codecs?
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>
>>>>>>> Thanks for the Reply
>>>>>>> Oddly enough we are.
>>>>>>> This probably has something to do with MOH in general?
>>>>>>>
>>>>>>> Internally when I user puts another user on hold everything works.
>>>>>>> No MOH plays and they can hold and unhold the call just fine.
>>>>>>> I tested calling from an external number. Once I put the external
>>>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>>>> hit resume on the deskphone the MOH still played to the external caller and
>>>>>>> there was no sound on the deskphone.
>>>>>>>
>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>>
>>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>>> outside SNR features?
>>>>>>>>
>>>>>>>> -Ryan
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>
>>>>>>>> Password:
>>>>>>>>
>>>>>>>>
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>> Cisco3825#sh ver
>>>>>>>>
>>>>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M),
>>>>>>>> Version 15.1
>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>
>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>
>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>
>>>>>>>>
>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>>>>
>>>>>>>>
>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>
>>>>>>>> System returned to ROM by power-on
>>>>>>>>
>>>>>>>> System image file is
>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>> Last reload type: Normal Reload
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>> United
>>>>>>>> States and local country laws governing import, export, transfer
>>>>>>>> and
>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>
>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>> encryption.
>>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>>
>>>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>>>> you
>>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>>> unable
>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>> immediately.
>>>>>>>>
>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may
>>>>>>>> be found at:
>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>
>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>> email to
>>>>>>>> export at cisco.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>
>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>
>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>
>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>
>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>
>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>
>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>
>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> License Info:
>>>>>>>>
>>>>>>>>
>>>>>>>> License UDI:
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------
>>>>>>>>
>>>>>>>> Device# PID SN
>>>>>>>>
>>>>>>>> Sent from my mobile device
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>> up the the mobile number it just plays what sounds like hold music on both
>>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>
>>>>>>>> In another senario with what I believe is the same issue. If a user
>>>>>>>> picks up on there cell phone first (using single number reach) opposed to
>>>>>>>> the deskphone the call is connected with 2 way voice and no issues exist.
>>>>>>>> If the user then hangs up his cell phone with the intent to take the call
>>>>>>>> on his deskphone the calling party starts hearing the hold music. Once
the
>>>>>>>> user picks up the call on his deskphone he hears nothing but the calling
>>>>>>>> party is still hearing the hold music. It is not working as intended
where
>>>>>>>> 2 way voice happens once the user hangs up his mobile phone and picks up
on
>>>>>>>> his deskphone 2 way voice should happen.
>>>>>>>>
>>>>>>>> My topology is as follows..
>>>>>>>>
>>>>>>>>
>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>
>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
>>>>>>>> connect/snr.
>>>>>>>>
>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/c029983d/attachment.html>

From dane.newman at gmail.com Tue Jan 15 20:39:09 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Tue, 15 Jan 2013 20:39:09 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
Message-ID: <CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>

Nick

Thanks for the assistance.

This is the first time I am setting up a direct sip connection from cucm to
cube. I am used to making it an h323 connection. Attached are screen
shots of my trunk setup. MTP is checked off I believe already. Is there
a best way to go about troubleshooting cucm to figure out why its not
setting the stream back to active?

On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com> wrote:

> It looks like CUCM isn't setting the stream back to active after putting
> it on hold. It sends the re-invite, and the 200 OK from the ITSP has the
> SDP continued with a=inactive.
>
> I don't have some good traces in front of me, but somewhere it needs to
> take that off. I don't think Asterisks is acting incorrectly by responding
> to a delayed offer INVITE that was previously a=inactive with a=inactive.
>
> What's also odd is that CUCM is sending the exact same INVITE after the
> first one completes, for both the hold and the resume. The CSeq isn't
> increasing, which I would expect it to.
>
> If you were to check 'MTP' required it may work around the problem, but I
> don't consider inserting MTP's to be a best practice.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>
>> Bind your media and source to your outbound interface on your voice
>> service voip.
>>
>> Sent from my iPhone
>>
>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Below is a show run from the router
>>
>>
>> [OK]
>> Cisco3825#sh run
>> Building configuration...
>>
>> Current configuration : 10183 bytes
>> !
>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>> version 15.1
>> service timestamps debug datetime msec
>> service timestamps log datetime msec
>> no service password-encryption
>> !
>> hostname Cisco3825
>> !
>> boot-start-marker
>> boot-end-marker
>> !
>> !
>> !
>> aaa new-model
>> !
>> !
>> aaa authentication login default local
>> aaa authentication login vpnauth local
>> aaa authorization exec default local
>> aaa authorization network default local
>> aaa authorization network vpnauth local
>> !
>> !
>> !
>> !
>> !
>> aaa session-id common
>> !
>> no network-clock-participate wic 0
>> !
>> dot11 syslog
>> ip source-route
>> !
>> ip cef
>> !
>> !
>> !
>> !
>> ip domain name datasc.local
>> ip inspect udp idle-time 1800
>> no ipv6 cef
>> !
>> multilink bundle-name authenticated
>> !
>> !
>> !
>> !
>> !
>> voice-card 0
>> dsp services dspfarm
>> !
>> !
>> !
>> voice service voip
>> ip address trusted list
>> ipv4 64.154.41.150 255.255.255.255
>> allow-connections sip to sip
>> fax protocol pass-through g711ulaw
>> sip
>> !
>> !
>> !
>> !
>> voice translation-rule 1
>> rule 1 /6784604564/ /200/
>> rule 2 /6784563290/ /100/
>> rule 3 /6784563291/ /101/
>> rule 4 /6784563292/ /102/
>> rule 5 /6784563293/ /103/
>> rule 6 /6784563294/ /104/
>> rule 7 /6784563295/ /105/
>> rule 8 /6784563296/ /106/
>> rule 9 /6784563297/ /107/
>> rule 10 /6784563298/ /108/
>> rule 11 /6784563299/ /109/
>> rule 12 /6784604565/ /125/
>> !
>> !
>> voice translation-profile incomingdid
>> translate called 1
>> !
>> !
>> crypto pki token default removal timeout 0
>> !
>> crypto pki trustpoint selfsigned
>> enrollment selfsigned
>> subject-name CN=connect.datasc.com
>> revocation-check crl
>> !
>> !
>> crypto pki certificate chain selfsigned
>> certificate self-signed 02
>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>> quit
>> !
>> !
>> license udi pid CISCO3825 sn FTX1237A1T0
>> username xxxxxxx privilege 15 secret xxxxxx
>> !
>> redundancy
>> !
>> !
>> controller T1 0/0/0
>> !
>> controller T1 0/0/1
>> !
>> ip ssh version 2
>> !
>> !
>> crypto isakmp policy 10
>> encr aes
>> authentication pre-share
>> group 2
>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>> crypto isakmp fragmentation
>> !
>> crypto isakmp client configuration group datasc
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> save-password
>> !
>> crypto isakmp client configuration group datascsplit
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> acl 101
>> save-password
>> crypto isakmp profile datasc
>> match identity group datasc
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 1
>> crypto isakmp profile datascsplit
>> match identity group datascsplit
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 2
>> !
>> !
>> crypto ipsec transform-set transformset esp-aes
>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>> !
>> crypto ipsec profile VTI
>> set transform-set ezvpntransform
>> set isakmp-profile datasc
>> !
>> crypto ipsec profile VTI2
>> set transform-set ezvpntransform
>> set isakmp-profile datascsplit
>> !
>> !
>> !
>> !
>> !
>> !
>> !
>> interface Loopback1
>> ip address 10.1.150.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly in
>> !
>> interface GigabitEthernet0/0
>> ip address dhcp
>> no ip redirects
>> no ip unreachables
>> no ip proxy-arp
>> ip nat outside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> hold-queue 240000 in
>> !
>> interface GigabitEthernet0/1
>> ip address 10.1.200.1 255.255.255.252
>> ip nat inside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> !
>> interface Virtual-Template1 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI
>> !
>> interface Virtual-Template2 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI2
>> !
>> interface Virtual-Template3
>> ip unnumbered GigabitEthernet0/0
>> ip nat outside
>> ip virtual-reassembly in
>> ip policy route-map anyconnecthop
>> !
>> !
>> router eigrp 1
>> maximum-paths 1
>> network 10.0.0.0
>> redistribute static
>> !
>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>> ip forward-protocol nd
>> ip http server
>> ip http secure-server
>> !
>> !
>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>> overload
>> ip nat inside source static tcp 10.1.50.150 80 interface
>> GigabitEthernet0/0 80
>> ip nat inside source static tcp 10.1.80.100 5001 interface
>> GigabitEthernet0/0 5001
>> ip nat inside source static udp 10.1.80.100 5001 interface
>> GigabitEthernet0/0 5001
>> !
>> ip access-list extended NATNETWORKS
>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> ip access-list extended anyconnecthop
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> !
>> access-list 50 permit 10.0.0.0 0.255.255.255
>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>> !
>> !
>> !
>> !
>> route-map anyconnecthop permit 10
>> match ip address anyconnecthop
>> set ip next-hop 10.1.150.2
>> !
>> !
>> !
>> !
>> !
>> control-plane
>> !
>> !
>> !
>> !
>> mgcp profile default
>> !
>> !
>> dial-peer voice 100 voip
>> description Publisher
>> preference 1
>> destination-pattern 1..
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 101 voip
>> description Subscriber
>> preference 2
>> destination-pattern 1..
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 200 voip
>> description Publisher
>> preference 1
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 300 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 678456329.
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 301 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604565
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 302 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604564
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 201 voip
>> description Publisher
>> preference 2
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 500 voip
>> description outgoing
>> preference 1
>> destination-pattern .T
>> session protocol sipv2
>> session target dns:sip.talkinip.net
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> !
>> sip-ua
>> credentials username xxxxxxxx password 7 xxxxxxx realm
>> sipconnect.ipcomms.net
>> authentication username xxxxxx password 7 xxxxxxx
>> authentication username xxxxx password 7 xxxxxxx realm
>> sipconnect.ipcomms.net
>> set pstn-cause 3 sip-status 486
>> set pstn-cause 34 sip-status 486
>> set pstn-cause 47 sip-status 486
>> registrar dns:sipconnect.ipcomms.net expires 60
>> sip-server dns:sipconnect.ipcomms.net:5060
>> !
>> !
>> !
>> gatekeeper
>> shutdown
>> !
>> !
>> call-manager-fallback
>> max-conferences 8 gain -6
>> transfer-system full-consult
>> ip source-address 10.1.200.1 port 2000
>> max-ephones 20
>> max-dn 40
>> !
>> !
>> !
>> line con 0
>> line aux 0
>> line vty 0 4
>> privilege level 15
>> transport input ssh
>> line vty 5 15
>> privilege level 15
>> transport input ssh
>> !
>> scheduler allocate 20000 1000
>> !
>> webvpn gateway gateway_1
>> ip interface GigabitEthernet0/0 port 443
>> ssl trustpoint selfsigned
>> inservice
>> !
>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>> sequence 1
>> !
>> webvpn context datasc
>> title "DataSC VPN"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datasc
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc keep-client-installed
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> virtual-template 3
>> default-group-policy datasc
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datasc
>> inservice
>> !
>> !
>> webvpn context datascsplit
>> title "DataSC VPN Split"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datascsplit
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc split include acl 50
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> default-group-policy datascsplit
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datascsplit
>> inservice
>> !
>> end
>> Cisco3825#
>>
>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> What do your media resources look like?
>>>
>>>
>>> Also can you show me a copy of your voice service voip config?
>>>
>>> Sent from my iPad
>>>
>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Thanks Ryan
>>>
>>> I see I am always getting a 200 ok message after my invites from the
>>> debug
>>>
>>> *Putting a call on HOLD*
>>>
>>>
>>>
>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 102 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 240
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 289
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 239
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>> >;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 253
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 102 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>> >;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 209
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0
>>>
>>> a=X-cisco-media:nomedia
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 251
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>>
>>>
>>> *Unholding the call the MOH continues on the previously held caller
>>> while the user hears nothing*
>>>
>>> **
>>>
>>>
>>>
>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>> ;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>> >;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>> Cisco3825#
>>>
>>>
>>>
>>> Cisco3825#
>>>
>>>
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>> ;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>> >;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>> >;tag=2E6BC0B0-2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>> sip:17705439047 at 64.154.41.150:5060
>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>>
>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> ccsip message is what I'd go with just to see the signaling with no
>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>> to the signals you may need to expand from there.
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Ryan
>>>>
>>>> What is the proper debug to use to caputre the useful information?
>>>>
>>>> Dane
>>>>
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>
>>>>> Without sip messages I can't get any clues from that.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thanks Ryan for the input
>>>>>
>>>>>
>>>>> *On the call when I hold the call the following debug pops out....*
>>>>>
>>>>>
>>>>> *Jan 15 17:56:05.246:
>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>> passthru hdrs to
>>>>> container
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1
>>>>> not found.
>>>>> *Jan 15 17:56:05.274:
>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>> passthru headers to
>>>>> container
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>> not found.
>>>>> *Jan 15 17:56:05.286:
>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>> passthru hdrs to
>>>>> container
>>>>> *Jan 15 17:56:05.302:
>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>> passthru headers to
>>>>> container
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>> not found.
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> *Jan 15 17:56:05.322:
>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>> params for midcall INVITE
>>>>>
>>>>> *After I try to unhold the call the following debug comes out....*
>>>>> **
>>>>>
>>>>> *Jan 15 17:56:18.874:
>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>> passthru hdrs to
>>>>> container
>>>>> *Jan 15 17:56:18.894:
>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>> passthru headers to
>>>>> container
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>> not found.
>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>> *Jan 15 17:56:18.906:
>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>> params for midcall INVITE
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>> Cisco3825#
>>>>>
>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>> haven't noticed already this is also very likely causing transfers to fail.
>>>>>>
>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of problem.
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> *Hello Kenneth*
>>>>>> **
>>>>>> *I have restarted both CUCM servers so this should have restarted
>>>>>> the services when the utils system restart happened*
>>>>>> **
>>>>>>
>>>>>> *on my router I see I am using g711 from the debug *
>>>>>> **
>>>>>> *I ran a debug voip ccapi inout *
>>>>>> **
>>>>>> *I connected a call calling from an external number to a DiD inside
>>>>>> of my system. Once the call was connected I put the call on hold and the
>>>>>> following debug came out..the music on hold played for the external caller
>>>>>> *
>>>>>>
>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=170, Call Id=12742
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.811:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=171, Call Id=12741
>>>>>> *Jan 14 23:47:40.811:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>> *Jan 14 23:47:40.819:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=96, Call Id=12742
>>>>>> *Jan 14 23:47:40.819:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.839:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>> *Jan 14 23:47:40.839:
>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.843:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=170, Call Id=12741
>>>>>> *Jan 14 23:47:40.843:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>>> *Jan 14 23:47:40.863:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=171, Call Id=12742
>>>>>> *Jan 14 23:47:40.863:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>>
>>>>>>
>>>>>> *I then after that took off the hold and the following debug came
>>>>>> out. The call on the PSDN side still played the hold music while there was
>>>>>> no voice on the deskphone side.*
>>>>>>
>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=170, Call Id=12742
>>>>>> *Jan 14 23:47:40.783:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.811:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=171, Call Id=12741
>>>>>> *Jan 14 23:47:40.811:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>> *Jan 14 23:47:40.819:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=96, Call Id=12742
>>>>>> *Jan 14 23:47:40.819:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.839:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>> *Jan 14 23:47:40.839:
>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>>>>> *Jan 14 23:47:40.843:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=170, Call Id=12741
>>>>>> *Jan 14 23:47:40.843:
>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>> Source Call Id=12742,
>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>> Source Call Id=12741,
>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>>>>> *Jan 14 23:47:40.863:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event=171, Call Id=12742
>>>>>> *Jan 14 23:47:40.863:
>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>>
>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>
>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>>>> hard coded it with me when I was initially setting it up.
>>>>>>>
>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>> identifying if it is?
>>>>>>>
>>>>>>> Dane
>>>>>>>
>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>
>>>>>>>> Have you tried different audio codecs?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>
>>>>>>>> Thanks for the Reply
>>>>>>>> Oddly enough we are.
>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>
>>>>>>>> Internally when I user puts another user on hold everything works.
>>>>>>>> No MOH plays and they can hold and unhold the call just fine.
>>>>>>>> I tested calling from an external number. Once I put the external
>>>>>>>> caller on hold the MOH played but I was unable to resume the call. When I
>>>>>>>> hit resume on the deskphone the MOH still played to the external caller
and
>>>>>>>> there was no sound on the deskphone.
>>>>>>>>
>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>
>>>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>>>> outside SNR features?
>>>>>>>>>
>>>>>>>>> -Ryan
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>
>>>>>>>>> Password:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>
>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>
>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>
>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>> (fc1)
>>>>>>>>>
>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>
>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>
>>>>>>>>> System image file is
>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>> United
>>>>>>>>> States and local country laws governing import, export, transfer
>>>>>>>>> and
>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>
>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>> encryption.
>>>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>>>
>>>>>>>>> compliance with U.S. and local country laws. By using this product
>>>>>>>>> you
>>>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>>>> unable
>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>> immediately.
>>>>>>>>>
>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may
>>>>>>>>> be found at:
>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>
>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>> email to
>>>>>>>>> export at cisco.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>>
>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>
>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>
>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>
>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>
>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>
>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>
>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> License Info:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> License UDI:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------
>>>>>>>>>
>>>>>>>>> Device# PID SN
>>>>>>>>>
>>>>>>>>> Sent from my mobile device
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>>> up the the mobile number it just plays what sounds like hold music on
both
>>>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>>
>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to take
>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing but
the
>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>
>>>>>>>>> My topology is as follows..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>>
>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>> mobile connect/snr.
>>>>>>>>>
>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ad429946/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk.jpg
Type: image/jpeg
Size: 198917 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ad429946/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk2.jpg
Type: image/jpeg
Size: 247085 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130115/ad429946/attachment-0001.jpg>

From abbaseo at gmail.com Wed Jan 16 06:28:34 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 11:28:34 +0000
Subject: [cisco-voip] vg224 fxs port facility codes
Message-ID: <CAFdHCp5Yyzc30ayfLtyhFinRV9dbDuP6BUSMgUjCXNe2f0e=pA@mail.gmail.com>

Hi,
I am required to configure VOIP phone facilities for the traditional
analogue phones connected via the FXS on VG's. Facilities like, cFwdAll and
voicemail.
in the voicemail, though they won have the softkey but they can dial the
Voicemail pilot to hit their Unity mail box. but the problem is the
notification i.e. how will we alert them for new voicemial????

we are using CUCM 8.5 with MGCP gateways

thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d5df7b87/attachment.html>

From joe.pollere at dimensiondata.com Wed Jan 16 06:49:52 2013


From: joe.pollere at dimensiondata.com (Joe Pollere (AM))
Date: Wed, 16 Jan 2013 06:49:52 -0500
Subject: [cisco-voip] vg224 fxs port facility codes
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C5007A2@USISPCLEXDB01.na.didata.local>

Set the VG224 to use SCCP and supplemental features:

http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxssccpsplmft.htm
l

You can set audible message waiting and feature codes for cfwd.

Joe

------Original Message------
From: abbas Wali
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] vg224 fxs port facility codes
Sent: Jan 16, 2013 6:28 AM

Hi,

I am required to configure VOIP phone facilities for the traditional analogue


phones connected via the FXS on VG's. Facilities like, cFwdAll and voicemail.
in the voicemail, though they won have the softkey but they can dial the Voicemail
pilot to hit their Unity mail box. but the problem is the notification i.e. how
will we alert them for new voicemial????

we are using CUCM 8.5 with MGCP gateways


thanks
--
@bbas..

itevomcid
From abbaseo at gmail.com Wed Jan 16 08:30:27 2013
From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 13:30:27 +0000
Subject: [cisco-voip] vg224 fxs port facility codes
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C5007A2@USISPCLEXDB01.na.didata.local>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C5007A2@USISPCLEXDB01.na.didata.local>
Message-ID: <CAFdHCp6VpVAqfut1NpdNqVs6=djZ=W1Uhgo+CVEmAmG57Fx4MQ@mail.gmail.com>

thanks for that,

on the cfwdall, does the GW must be on SCCP as

* 1. **enable*

* 2. **configure* *terminal*

* 3. **stcapp call-control mode feature*

*or an mgcp based VG can support the same features.*

*Thanks
*

*
*

On 16 January 2013 11:49, Joe Pollere (AM) <joe.pollere at dimensiondata.com>wrote:

> Set the VG224 to use SCCP and supplemental features:


>
>
>
http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxssccpsplmft.htm
l
>
> You can set audible message waiting and feature codes for cfwd.
>
> Joe
>
> ------Original Message------
> From: abbas Wali
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] vg224 fxs port facility codes
> Sent: Jan 16, 2013 6:28 AM
>
>
>
> Hi,
>
> I am required to configure VOIP phone facilities for the traditional
> analogue phones connected via the FXS on VG's. Facilities like, cFwdAll and
> voicemail.
> in the voicemail, though they won have the softkey but they can dial the
> Voicemail pilot to hit their Unity mail box. but the problem is the
> notification i.e. how will we alert them for new voicemial????
>
> we are using CUCM 8.5 with MGCP gateways
> thanks
> --
> @bbas..
>
>
> itevomcid
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/f42a1135/attachment.html>

From joe.pollere at dimensiondata.com Wed Jan 16 08:33:37 2013


From: joe.pollere at dimensiondata.com (Joe Pollere (AM))
Date: Wed, 16 Jan 2013 08:33:37 -0500
Subject: [cisco-voip] vg224 fxs port facility codes
In-Reply-To: <CAFdHCp6VpVAqfut1NpdNqVs6=djZ=W1Uhgo+CVEmAmG57Fx4MQ@mail.gmail.com>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C5007A2@USISPCLEXDB01.na.didata.local>
<CAFdHCp6VpVAqfut1NpdNqVs6=djZ=W1Uhgo+CVEmAmG57Fx4MQ@mail.gmail.com>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C7B6559@USISPCLEXDB01.na.didata.local>

Needs to be SCCP to support the supplemental features.

From: abbas Wali [mailto:abbaseo at gmail.com]


Sent: Wednesday, January 16, 2013 8:30 AM
To: Joe Pollere (AM)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] vg224 fxs port facility codes

thanks for that,

on the cfwdall, does the GW must be on SCCP as

1. enable

2. configure terminal

3. stcapp call-control mode feature

or an mgcp based VG can support the same features.

Thanks

On 16 January 2013 11:49, Joe Pollere (AM) <joe.pollere at


dimensiondata.com<mailto:joe.pollere at dimensiondata.com>> wrote:
Set the VG224 to use SCCP and supplemental features:

http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxssccpsplmft.htm
l

You can set audible message waiting and feature codes for cfwd.

Joe

------Original Message------
From: abbas Wali
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] vg224 fxs port facility codes
Sent: Jan 16, 2013 6:28 AM

Hi,

I am required to configure VOIP phone facilities for the traditional analogue


phones connected via the FXS on VG's. Facilities like, cFwdAll and voicemail.
in the voicemail, though they won have the softkey but they can dial the Voicemail
pilot to hit their Unity mail box. but the problem is the notification i.e. how
will we alert them for new voicemial????

we are using CUCM 8.5 with MGCP gateways


thanks
--
@bbas..

itevomcid

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/ecd63aa1/attachment.html>

From kennethwhayes at gmail.com Wed Jan 16 08:42:06 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 08:42:06 -0500
Subject: [cisco-voip] Auto Attendant/Call Handler issue
Message-ID: <5480028361612140863@unknownmsgid>

All,

I've been tasked to configure a Auto Attendant in Unity Connection 8.x and
I'm running into issues. The integration between my CUCM and Unity
Connection is SIP.

CUCM->SIP Trunk->UnityC

I've configured my Call Handler with an extension of 4000. My Standard


Greeting has been recorded via the Phone. Under the Greetings I have
"Caller Hears "My Personal Recording". The "Conversation" is set to "Caller
System Transfer". I have assigned the owner to the Call Handler which is my
extension for the recording. My Direct Routing Rule is equal to the AA
extension, so I get this looping "Sorry UCSATL_AA is unavailable" over and
over!!!

Also when I select a input Unity Connection tells me it cannot transfer me


to this person, or it will try and transfer but goes straight to the end
users voicemail box...which is weird to me, but non of the phones are
CallFwdAll to VM..

So before I route PSTN calls to the AA I want to make sure I'm configuring
it right..
Any suggestions??????

Sent from my iPad


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/4cffb1eb/attachment.html>

From matthnick at gmail.com Wed Jan 16 10:14:35 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Wed, 16 Jan 2013 10:14:35 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
<CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
Message-ID: <CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>

I'm not sure at this point, I'll let some of the CUCM experts comment. It's
possible during the hold conversation CUCM always sends delayed offer, but
I don't have some good traces in front of me to confirm.

You can check the original invite CUCM sends to see if there's SDP in that,
and it would confirm the MTP is being allocated. If it's sending the INVITE
without SDP, your MRG/MRGL or resources are misconfigured or in use.

-nick

On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
> Nick
>
> Thanks for the assistance.
>
> This is the first time I am setting up a direct sip connection from cucm
> to cube. I am used to making it an h323 connection. Attached are screen
> shots of my trunk setup. MTP is checked off I believe already. Is there
> a best way to go about troubleshooting cucm to figure out why its not
> setting the stream back to active?
>
> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>
>> It looks like CUCM isn't setting the stream back to active after putting
>> it on hold. It sends the re-invite, and the 200 OK from the ITSP has the
>> SDP continued with a=inactive.
>>
>> I don't have some good traces in front of me, but somewhere it needs to
>> take that off. I don't think Asterisks is acting incorrectly by responding
>> to a delayed offer INVITE that was previously a=inactive with a=inactive.
>>
>> What's also odd is that CUCM is sending the exact same INVITE after the
>> first one completes, for both the hold and the resume. The CSeq isn't
>> increasing, which I would expect it to.
>>
>> If you were to check 'MTP' required it may work around the problem, but I
>> don't consider inserting MTP's to be a best practice.
>>
>> -nick
>>
>>
>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> Bind your media and source to your outbound interface on your voice
>>> service voip.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Below is a show run from the router
>>>
>>>
>>> [OK]
>>> Cisco3825#sh run
>>> Building configuration...
>>>
>>> Current configuration : 10183 bytes
>>> !
>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>>> version 15.1
>>> service timestamps debug datetime msec
>>> service timestamps log datetime msec
>>> no service password-encryption
>>> !
>>> hostname Cisco3825
>>> !
>>> boot-start-marker
>>> boot-end-marker
>>> !
>>> !
>>> !
>>> aaa new-model
>>> !
>>> !
>>> aaa authentication login default local
>>> aaa authentication login vpnauth local
>>> aaa authorization exec default local
>>> aaa authorization network default local
>>> aaa authorization network vpnauth local
>>> !
>>> !
>>> !
>>> !
>>> !
>>> aaa session-id common
>>> !
>>> no network-clock-participate wic 0
>>> !
>>> dot11 syslog
>>> ip source-route
>>> !
>>> ip cef
>>> !
>>> !
>>> !
>>> !
>>> ip domain name datasc.local
>>> ip inspect udp idle-time 1800
>>> no ipv6 cef
>>> !
>>> multilink bundle-name authenticated
>>> !
>>> !
>>> !
>>> !
>>> !
>>> voice-card 0
>>> dsp services dspfarm
>>> !
>>> !
>>> !
>>> voice service voip
>>> ip address trusted list
>>> ipv4 64.154.41.150 255.255.255.255
>>> allow-connections sip to sip
>>> fax protocol pass-through g711ulaw
>>> sip
>>> !
>>> !
>>> !
>>> !
>>> voice translation-rule 1
>>> rule 1 /6784604564/ /200/
>>> rule 2 /6784563290/ /100/
>>> rule 3 /6784563291/ /101/
>>> rule 4 /6784563292/ /102/
>>> rule 5 /6784563293/ /103/
>>> rule 6 /6784563294/ /104/
>>> rule 7 /6784563295/ /105/
>>> rule 8 /6784563296/ /106/
>>> rule 9 /6784563297/ /107/
>>> rule 10 /6784563298/ /108/
>>> rule 11 /6784563299/ /109/
>>> rule 12 /6784604565/ /125/
>>> !
>>> !
>>> voice translation-profile incomingdid
>>> translate called 1
>>> !
>>> !
>>> crypto pki token default removal timeout 0
>>> !
>>> crypto pki trustpoint selfsigned
>>> enrollment selfsigned
>>> subject-name CN=connect.datasc.com
>>> revocation-check crl
>>> !
>>> !
>>> crypto pki certificate chain selfsigned
>>> certificate self-signed 02
>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>> quit
>>> !
>>> !
>>> license udi pid CISCO3825 sn FTX1237A1T0
>>> username xxxxxxx privilege 15 secret xxxxxx
>>> !
>>> redundancy
>>> !
>>> !
>>> controller T1 0/0/0
>>> !
>>> controller T1 0/0/1
>>> !
>>> ip ssh version 2
>>> !
>>> !
>>> crypto isakmp policy 10
>>> encr aes
>>> authentication pre-share
>>> group 2
>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>> crypto isakmp fragmentation
>>> !
>>> crypto isakmp client configuration group datasc
>>> key Recoil90
>>> dns 4.2.2.2 4.2.2.1
>>> domain datasc.local
>>> pool vpnpool
>>> save-password
>>> !
>>> crypto isakmp client configuration group datascsplit
>>> key Recoil90
>>> dns 4.2.2.2 4.2.2.1
>>> domain datasc.local
>>> pool vpnpool
>>> acl 101
>>> save-password
>>> crypto isakmp profile datasc
>>> match identity group datasc
>>> client authentication list vpnauth
>>> isakmp authorization list vpnauth
>>> client configuration address respond
>>> virtual-template 1
>>> crypto isakmp profile datascsplit
>>> match identity group datascsplit
>>> client authentication list vpnauth
>>> isakmp authorization list vpnauth
>>> client configuration address respond
>>> virtual-template 2
>>> !
>>> !
>>> crypto ipsec transform-set transformset esp-aes
>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>> !
>>> crypto ipsec profile VTI
>>> set transform-set ezvpntransform
>>> set isakmp-profile datasc
>>> !
>>> crypto ipsec profile VTI2
>>> set transform-set ezvpntransform
>>> set isakmp-profile datascsplit
>>> !
>>> !
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Loopback1
>>> ip address 10.1.150.1 255.255.255.0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> !
>>> interface GigabitEthernet0/0
>>> ip address dhcp
>>> no ip redirects
>>> no ip unreachables
>>> no ip proxy-arp
>>> ip nat outside
>>> ip virtual-reassembly in
>>> duplex auto
>>> speed auto
>>> media-type rj45
>>> hold-queue 240000 in
>>> !
>>> interface GigabitEthernet0/1
>>> ip address 10.1.200.1 255.255.255.252
>>> ip nat inside
>>> ip virtual-reassembly in
>>> duplex auto
>>> speed auto
>>> media-type rj45
>>> !
>>> interface Virtual-Template1 type tunnel
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> tunnel source GigabitEthernet0/0
>>> tunnel mode ipsec ipv4
>>> tunnel protection ipsec profile VTI
>>> !
>>> interface Virtual-Template2 type tunnel
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> tunnel source GigabitEthernet0/0
>>> tunnel mode ipsec ipv4
>>> tunnel protection ipsec profile VTI2
>>> !
>>> interface Virtual-Template3
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat outside
>>> ip virtual-reassembly in
>>> ip policy route-map anyconnecthop
>>> !
>>> !
>>> router eigrp 1
>>> maximum-paths 1
>>> network 10.0.0.0
>>> redistribute static
>>> !
>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>> ip forward-protocol nd
>>> ip http server
>>> ip http secure-server
>>> !
>>> !
>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>> overload
>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>> GigabitEthernet0/0 80
>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>> GigabitEthernet0/0 5001
>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>> GigabitEthernet0/0 5001
>>> !
>>> ip access-list extended NATNETWORKS
>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>> permit ip 10.0.0.0 0.255.255.255 any
>>> ip access-list extended anyconnecthop
>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>> permit ip 10.0.0.0 0.255.255.255 any
>>> !
>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>> !
>>> !
>>> !
>>> !
>>> route-map anyconnecthop permit 10
>>> match ip address anyconnecthop
>>> set ip next-hop 10.1.150.2
>>> !
>>> !
>>> !
>>> !
>>> !
>>> control-plane
>>> !
>>> !
>>> !
>>> !
>>> mgcp profile default
>>> !
>>> !
>>> dial-peer voice 100 voip
>>> description Publisher
>>> preference 1
>>> destination-pattern 1..
>>> session protocol sipv2
>>> session target ipv4:10.1.80.10
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 101 voip
>>> description Subscriber
>>> preference 2
>>> destination-pattern 1..
>>> session target ipv4:10.1.80.11
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 200 voip
>>> description Publisher
>>> preference 1
>>> destination-pattern 2..
>>> progress_ind setup enable 3
>>> progress_ind progress enable 8
>>> session protocol sipv2
>>> session target ipv4:10.1.80.10
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 300 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 678456329.
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 301 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 6784604565
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 302 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 6784604564
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 201 voip
>>> description Publisher
>>> preference 2
>>> destination-pattern 2..
>>> progress_ind setup enable 3
>>> progress_ind progress enable 8
>>> session protocol sipv2
>>> session target ipv4:10.1.80.11
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 500 voip
>>> description outgoing
>>> preference 1
>>> destination-pattern .T
>>> session protocol sipv2
>>> session target dns:sip.talkinip.net
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> !
>>> sip-ua
>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>> sipconnect.ipcomms.net
>>> authentication username xxxxxx password 7 xxxxxxx
>>> authentication username xxxxx password 7 xxxxxxx realm
>>> sipconnect.ipcomms.net
>>> set pstn-cause 3 sip-status 486
>>> set pstn-cause 34 sip-status 486
>>> set pstn-cause 47 sip-status 486
>>> registrar dns:sipconnect.ipcomms.net expires 60
>>> sip-server dns:sipconnect.ipcomms.net:5060
>>> !
>>> !
>>> !
>>> gatekeeper
>>> shutdown
>>> !
>>> !
>>> call-manager-fallback
>>> max-conferences 8 gain -6
>>> transfer-system full-consult
>>> ip source-address 10.1.200.1 port 2000
>>> max-ephones 20
>>> max-dn 40
>>> !
>>> !
>>> !
>>> line con 0
>>> line aux 0
>>> line vty 0 4
>>> privilege level 15
>>> transport input ssh
>>> line vty 5 15
>>> privilege level 15
>>> transport input ssh
>>> !
>>> scheduler allocate 20000 1000
>>> !
>>> webvpn gateway gateway_1
>>> ip interface GigabitEthernet0/0 port 443
>>> ssl trustpoint selfsigned
>>> inservice
>>> !
>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>> sequence 1
>>> !
>>> webvpn context datasc
>>> title "DataSC VPN"
>>> secondary-color white
>>> title-color #CCCC66
>>> text-color black
>>> ssl authenticate verify all
>>> !
>>> url-list "Servers"
>>> heading "Server"
>>> !
>>> !
>>> policy group datasc
>>> url-list "Servers"
>>> functions svc-enabled
>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>> svc keep-client-installed
>>> svc dns-server primary 4.2.2.2
>>> svc dtls
>>> virtual-template 3
>>> default-group-policy datasc
>>> aaa authentication list vpnauth
>>> gateway gateway_1 domain datasc
>>> inservice
>>> !
>>> !
>>> webvpn context datascsplit
>>> title "DataSC VPN Split"
>>> secondary-color white
>>> title-color #CCCC66
>>> text-color black
>>> ssl authenticate verify all
>>> !
>>> url-list "Servers"
>>> heading "Server"
>>> !
>>> !
>>> policy group datascsplit
>>> url-list "Servers"
>>> functions svc-enabled
>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>> svc split include acl 50
>>> svc dns-server primary 4.2.2.2
>>> svc dtls
>>> default-group-policy datascsplit
>>> aaa authentication list vpnauth
>>> gateway gateway_1 domain datascsplit
>>> inservice
>>> !
>>> end
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> What do your media resources look like?
>>>>
>>>>
>>>> Also can you show me a copy of your voice service voip config?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Thanks Ryan
>>>>
>>>> I see I am always getting a 200 ok message after my invites from the
>>>> debug
>>>>
>>>> *Putting a call on HOLD*
>>>>
>>>>
>>>>
>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 240
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281168
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 289
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 239
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 253
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 103 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 102 ACK
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281168
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 103 ACK
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 209
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0
>>>>
>>>> a=X-cisco-media:nomedia
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 251
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>>
>>>>
>>>> *Unholding the call the MOH continues on the previously held caller
>>>> while the user hears nothing*
>>>>
>>>> **
>>>>
>>>>
>>>>
>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>> ;transport=tcp>;video;audio;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281175
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Allow-Events: presence, kpml
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 243
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.10.18
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 105 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 265
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> Cisco3825#
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>> ;transport=tcp>;video;audio;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281175
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Allow-Events: presence, kpml
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 243
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.10.18
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 105 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 265
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>
>>>>> ccsip message is what I'd go with just to see the signaling with no
>>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>>> to the signals you may need to expand from there.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Ryan
>>>>>
>>>>> What is the proper debug to use to caputre the useful information?
>>>>>
>>>>> Dane
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> Without sip messages I can't get any clues from that.
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks Ryan for the input
>>>>>>
>>>>>>
>>>>>> *On the call when I hold the call the following debug pops out....*
>>>>>>
>>>>>>
>>>>>> *Jan 15 17:56:05.246:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> *Jan 15 17:56:05.274:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> *Jan 15 17:56:05.286:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> *Jan 15 17:56:05.302:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> *Jan 15 17:56:05.322:
>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>> params for midcall INVITE
>>>>>>
>>>>>> *After I try to unhold the call the following debug comes out....*
>>>>>> **
>>>>>>
>>>>>> *Jan 15 17:56:18.874:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> *Jan 15 17:56:18.894:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> *Jan 15 17:56:18.906:
>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>> params for midcall INVITE
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>
>>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> *Hello Kenneth*
>>>>>>> **
>>>>>>> *I have restarted both CUCM servers so this should have restarted
>>>>>>> the services when the utils system restart happened*
>>>>>>> **
>>>>>>>
>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>> **
>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>> **
>>>>>>> *I connected a call calling from an external number to a DiD inside
>>>>>>> of my system. Once the call was connected I put the call on hold and the
>>>>>>> following debug came out..the music on hold played for the external caller
>>>>>>> *
>>>>>>>
>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12742
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12741
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.815:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=96, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12741
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12742
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>>
>>>>>>> *I then after that took off the hold and the following debug came
>>>>>>> out. The call on the PSDN side still played the hold music while there was
>>>>>>> no voice on the deskphone side.*
>>>>>>>
>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12742
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12741
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.815:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=96, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12741
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12742
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>
>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>>>>> hard coded it with me when I was initially setting it up.
>>>>>>>>
>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>> identifying if it is?
>>>>>>>>
>>>>>>>> Dane
>>>>>>>>
>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>
>>>>>>>>> Thanks for the Reply
>>>>>>>>> Oddly enough we are.
>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>
>>>>>>>>> Internally when I user puts another user on hold everything works.
>>>>>>>>> No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>> When I hit resume on the deskphone the MOH still played to the external
>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>
>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>>
>>>>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>>>>> outside SNR features?
>>>>>>>>>>
>>>>>>>>>> -Ryan
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>
>>>>>>>>>> Password:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cisco3825#
>>>>>>>>>>
>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>
>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>
>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>
>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>> (fc1)
>>>>>>>>>>
>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>
>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>
>>>>>>>>>> System image file is
>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>>> United
>>>>>>>>>> States and local country laws governing import, export, transfer
>>>>>>>>>> and
>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>
>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>> encryption.
>>>>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>>>>
>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>> product you
>>>>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>>>>> unable
>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>> immediately.
>>>>>>>>>>
>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may
>>>>>>>>>> be found at:
>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>
>>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>>> email to
>>>>>>>>>> export at cisco.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>>>
>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>
>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>
>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>
>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>
>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>
>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>
>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> License Info:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> License UDI:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> Device# PID SN
>>>>>>>>>>
>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>>>> up the the mobile number it just plays what sounds like hold music on
both
>>>>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>>>
>>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to take
>>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing but
the
>>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>
>>>>>>>>>> My topology is as follows..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>>>
>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>
>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/042bab50/attachment.html>

From kennethwhayes at gmail.com Wed Jan 16 10:20:42 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 10:20:42 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
<CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
Message-ID: <8922406544240900299@unknownmsgid>

So have you looked in your media resources under music on hold server
configurations to make sure it's registered to the right UCM? Also what
audio bit rate is your MOH file?

Sent from my iPad

On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:

I'm not sure at this point, I'll let some of the CUCM experts comment. It's
possible during the hold conversation CUCM always sends delayed offer, but
I don't have some good traces in front of me to confirm.

You can check the original invite CUCM sends to see if there's SDP in that,
and it would confirm the MTP is being allocated. If it's sending the INVITE
without SDP, your MRG/MRGL or resources are misconfigured or in use.

-nick

On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com> wrote:

> Nick
>
> Thanks for the assistance.
>
> This is the first time I am setting up a direct sip connection from cucm
> to cube. I am used to making it an h323 connection. Attached are screen
> shots of my trunk setup. MTP is checked off I believe already. Is there
> a best way to go about troubleshooting cucm to figure out why its not
> setting the stream back to active?
>
> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>
>> It looks like CUCM isn't setting the stream back to active after putting
>> it on hold. It sends the re-invite, and the 200 OK from the ITSP has the
>> SDP continued with a=inactive.
>>
>> I don't have some good traces in front of me, but somewhere it needs to
>> take that off. I don't think Asterisks is acting incorrectly by responding
>> to a delayed offer INVITE that was previously a=inactive with a=inactive.
>>
>> What's also odd is that CUCM is sending the exact same INVITE after the
>> first one completes, for both the hold and the resume. The CSeq isn't
>> increasing, which I would expect it to.
>>
>> If you were to check 'MTP' required it may work around the problem, but I
>> don't consider inserting MTP's to be a best practice.
>>
>> -nick
>>
>>
>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> Bind your media and source to your outbound interface on your voice
>>> service voip.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Below is a show run from the router
>>>
>>>
>>> [OK]
>>> Cisco3825#sh run
>>> Building configuration...
>>>
>>> Current configuration : 10183 bytes
>>> !
>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>>> version 15.1
>>> service timestamps debug datetime msec
>>> service timestamps log datetime msec
>>> no service password-encryption
>>> !
>>> hostname Cisco3825
>>> !
>>> boot-start-marker
>>> boot-end-marker
>>> !
>>> !
>>> !
>>> aaa new-model
>>> !
>>> !
>>> aaa authentication login default local
>>> aaa authentication login vpnauth local
>>> aaa authorization exec default local
>>> aaa authorization network default local
>>> aaa authorization network vpnauth local
>>> !
>>> !
>>> !
>>> !
>>> !
>>> aaa session-id common
>>> !
>>> no network-clock-participate wic 0
>>> !
>>> dot11 syslog
>>> ip source-route
>>> !
>>> ip cef
>>> !
>>> !
>>> !
>>> !
>>> ip domain name datasc.local
>>> ip inspect udp idle-time 1800
>>> no ipv6 cef
>>> !
>>> multilink bundle-name authenticated
>>> !
>>> !
>>> !
>>> !
>>> !
>>> voice-card 0
>>> dsp services dspfarm
>>> !
>>> !
>>> !
>>> voice service voip
>>> ip address trusted list
>>> ipv4 64.154.41.150 255.255.255.255
>>> allow-connections sip to sip
>>> fax protocol pass-through g711ulaw
>>> sip
>>> !
>>> !
>>> !
>>> !
>>> voice translation-rule 1
>>> rule 1 /6784604564/ /200/
>>> rule 2 /6784563290/ /100/
>>> rule 3 /6784563291/ /101/
>>> rule 4 /6784563292/ /102/
>>> rule 5 /6784563293/ /103/
>>> rule 6 /6784563294/ /104/
>>> rule 7 /6784563295/ /105/
>>> rule 8 /6784563296/ /106/
>>> rule 9 /6784563297/ /107/
>>> rule 10 /6784563298/ /108/
>>> rule 11 /6784563299/ /109/
>>> rule 12 /6784604565/ /125/
>>> !
>>> !
>>> voice translation-profile incomingdid
>>> translate called 1
>>> !
>>> !
>>> crypto pki token default removal timeout 0
>>> !
>>> crypto pki trustpoint selfsigned
>>> enrollment selfsigned
>>> subject-name CN=connect.datasc.com
>>> revocation-check crl
>>> !
>>> !
>>> crypto pki certificate chain selfsigned
>>> certificate self-signed 02
>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>> quit
>>> !
>>> !
>>> license udi pid CISCO3825 sn FTX1237A1T0
>>> username xxxxxxx privilege 15 secret xxxxxx
>>> !
>>> redundancy
>>> !
>>> !
>>> controller T1 0/0/0
>>> !
>>> controller T1 0/0/1
>>> !
>>> ip ssh version 2
>>> !
>>> !
>>> crypto isakmp policy 10
>>> encr aes
>>> authentication pre-share
>>> group 2
>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>> crypto isakmp fragmentation
>>> !
>>> crypto isakmp client configuration group datasc
>>> key Recoil90
>>> dns 4.2.2.2 4.2.2.1
>>> domain datasc.local
>>> pool vpnpool
>>> save-password
>>> !
>>> crypto isakmp client configuration group datascsplit
>>> key Recoil90
>>> dns 4.2.2.2 4.2.2.1
>>> domain datasc.local
>>> pool vpnpool
>>> acl 101
>>> save-password
>>> crypto isakmp profile datasc
>>> match identity group datasc
>>> client authentication list vpnauth
>>> isakmp authorization list vpnauth
>>> client configuration address respond
>>> virtual-template 1
>>> crypto isakmp profile datascsplit
>>> match identity group datascsplit
>>> client authentication list vpnauth
>>> isakmp authorization list vpnauth
>>> client configuration address respond
>>> virtual-template 2
>>> !
>>> !
>>> crypto ipsec transform-set transformset esp-aes
>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>> !
>>> crypto ipsec profile VTI
>>> set transform-set ezvpntransform
>>> set isakmp-profile datasc
>>> !
>>> crypto ipsec profile VTI2
>>> set transform-set ezvpntransform
>>> set isakmp-profile datascsplit
>>> !
>>> !
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Loopback1
>>> ip address 10.1.150.1 255.255.255.0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> !
>>> interface GigabitEthernet0/0
>>> ip address dhcp
>>> no ip redirects
>>> no ip unreachables
>>> no ip proxy-arp
>>> ip nat outside
>>> ip virtual-reassembly in
>>> duplex auto
>>> speed auto
>>> media-type rj45
>>> hold-queue 240000 in
>>> !
>>> interface GigabitEthernet0/1
>>> ip address 10.1.200.1 255.255.255.252
>>> ip nat inside
>>> ip virtual-reassembly in
>>> duplex auto
>>> speed auto
>>> media-type rj45
>>> !
>>> interface Virtual-Template1 type tunnel
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> tunnel source GigabitEthernet0/0
>>> tunnel mode ipsec ipv4
>>> tunnel protection ipsec profile VTI
>>> !
>>> interface Virtual-Template2 type tunnel
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat inside
>>> ip virtual-reassembly in
>>> tunnel source GigabitEthernet0/0
>>> tunnel mode ipsec ipv4
>>> tunnel protection ipsec profile VTI2
>>> !
>>> interface Virtual-Template3
>>> ip unnumbered GigabitEthernet0/0
>>> ip nat outside
>>> ip virtual-reassembly in
>>> ip policy route-map anyconnecthop
>>> !
>>> !
>>> router eigrp 1
>>> maximum-paths 1
>>> network 10.0.0.0
>>> redistribute static
>>> !
>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>> ip forward-protocol nd
>>> ip http server
>>> ip http secure-server
>>> !
>>> !
>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>> overload
>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>> GigabitEthernet0/0 80
>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>> GigabitEthernet0/0 5001
>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>> GigabitEthernet0/0 5001
>>> !
>>> ip access-list extended NATNETWORKS
>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>> permit ip 10.0.0.0 0.255.255.255 any
>>> ip access-list extended anyconnecthop
>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>> permit ip 10.0.0.0 0.255.255.255 any
>>> !
>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>> !
>>> !
>>> !
>>> !
>>> route-map anyconnecthop permit 10
>>> match ip address anyconnecthop
>>> set ip next-hop 10.1.150.2
>>> !
>>> !
>>> !
>>> !
>>> !
>>> control-plane
>>> !
>>> !
>>> !
>>> !
>>> mgcp profile default
>>> !
>>> !
>>> dial-peer voice 100 voip
>>> description Publisher
>>> preference 1
>>> destination-pattern 1..
>>> session protocol sipv2
>>> session target ipv4:10.1.80.10
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 101 voip
>>> description Subscriber
>>> preference 2
>>> destination-pattern 1..
>>> session target ipv4:10.1.80.11
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 200 voip
>>> description Publisher
>>> preference 1
>>> destination-pattern 2..
>>> progress_ind setup enable 3
>>> progress_ind progress enable 8
>>> session protocol sipv2
>>> session target ipv4:10.1.80.10
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 300 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 678456329.
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 301 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 6784604565
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 302 voip
>>> description incoming Calldid
>>> translation-profile incoming incomingdid
>>> preference 1
>>> session protocol sipv2
>>> session target sip-server
>>> incoming called-number 6784604564
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 201 voip
>>> description Publisher
>>> preference 2
>>> destination-pattern 2..
>>> progress_ind setup enable 3
>>> progress_ind progress enable 8
>>> session protocol sipv2
>>> session target ipv4:10.1.80.11
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> dial-peer voice 500 voip
>>> description outgoing
>>> preference 1
>>> destination-pattern .T
>>> session protocol sipv2
>>> session target dns:sip.talkinip.net
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> !
>>> !
>>> sip-ua
>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>> sipconnect.ipcomms.net
>>> authentication username xxxxxx password 7 xxxxxxx
>>> authentication username xxxxx password 7 xxxxxxx realm
>>> sipconnect.ipcomms.net
>>> set pstn-cause 3 sip-status 486
>>> set pstn-cause 34 sip-status 486
>>> set pstn-cause 47 sip-status 486
>>> registrar dns:sipconnect.ipcomms.net expires 60
>>> sip-server dns:sipconnect.ipcomms.net:5060
>>> !
>>> !
>>> !
>>> gatekeeper
>>> shutdown
>>> !
>>> !
>>> call-manager-fallback
>>> max-conferences 8 gain -6
>>> transfer-system full-consult
>>> ip source-address 10.1.200.1 port 2000
>>> max-ephones 20
>>> max-dn 40
>>> !
>>> !
>>> !
>>> line con 0
>>> line aux 0
>>> line vty 0 4
>>> privilege level 15
>>> transport input ssh
>>> line vty 5 15
>>> privilege level 15
>>> transport input ssh
>>> !
>>> scheduler allocate 20000 1000
>>> !
>>> webvpn gateway gateway_1
>>> ip interface GigabitEthernet0/0 port 443
>>> ssl trustpoint selfsigned
>>> inservice
>>> !
>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>> sequence 1
>>> !
>>> webvpn context datasc
>>> title "DataSC VPN"
>>> secondary-color white
>>> title-color #CCCC66
>>> text-color black
>>> ssl authenticate verify all
>>> !
>>> url-list "Servers"
>>> heading "Server"
>>> !
>>> !
>>> policy group datasc
>>> url-list "Servers"
>>> functions svc-enabled
>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>> svc keep-client-installed
>>> svc dns-server primary 4.2.2.2
>>> svc dtls
>>> virtual-template 3
>>> default-group-policy datasc
>>> aaa authentication list vpnauth
>>> gateway gateway_1 domain datasc
>>> inservice
>>> !
>>> !
>>> webvpn context datascsplit
>>> title "DataSC VPN Split"
>>> secondary-color white
>>> title-color #CCCC66
>>> text-color black
>>> ssl authenticate verify all
>>> !
>>> url-list "Servers"
>>> heading "Server"
>>> !
>>> !
>>> policy group datascsplit
>>> url-list "Servers"
>>> functions svc-enabled
>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>> svc split include acl 50
>>> svc dns-server primary 4.2.2.2
>>> svc dtls
>>> default-group-policy datascsplit
>>> aaa authentication list vpnauth
>>> gateway gateway_1 domain datascsplit
>>> inservice
>>> !
>>> end
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> What do your media resources look like?
>>>>
>>>>
>>>> Also can you show me a copy of your voice service voip config?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Thanks Ryan
>>>>
>>>> I see I am always getting a 200 ok message after my invites from the
>>>> debug
>>>>
>>>> *Putting a call on HOLD*
>>>>
>>>>
>>>>
>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 240
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281168
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 289
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 239
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 102 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 253
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 103 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 102 ACK
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281168
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 103 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 103 ACK
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 209
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0
>>>>
>>>> a=X-cisco-media:nomedia
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 251
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 0.0.0.0
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>>
>>>>
>>>> *Unholding the call the MOH continues on the previously held caller
>>>> while the user hears nothing*
>>>>
>>>> **
>>>>
>>>>
>>>>
>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>> ;transport=tcp>;video;audio;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281175
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Allow-Events: presence, kpml
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 243
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.10.18
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 105 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 265
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> Cisco3825#
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>>
>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Supported: timer,resource-priority,replaces
>>>>
>>>> Min-SE: 1800
>>>>
>>>> User-Agent: Cisco-CUCM8.6
>>>>
>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: presence
>>>>
>>>> Supported: X-cisco-srtp-fallback
>>>>
>>>> Supported: Geolocation
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>
>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>> ;transport=tcp>;video;audio;video
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>
>>>> Min-SE: 1800
>>>>
>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>
>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> Timestamp: 1358281175
>>>>
>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>
>>>> Expires: 180
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 100 Trying
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Length: 0
>>>>
>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> CSeq: 105 INVITE
>>>>
>>>> Server: Asterisk PBX 1.6.2.13
>>>>
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>>
>>>> Supported: replaces, timer
>>>>
>>>> Require: timer
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 333
>>>>
>>>> v=0
>>>>
>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>
>>>> s=Asterisk PBX 1.6.2.13
>>>>
>>>> c=IN IP4 64.154.41.150
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>
>>>> a=rtpmap:3 GSM/8000
>>>>
>>>> a=rtpmap:8 PCMA/8000
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:18 G729/8000
>>>>
>>>> a=fmtp:18 annexb=no
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> CSeq: 104 INVITE
>>>>
>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>> >;party=called;screen=no;privacy=off
>>>>
>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>
>>>> Supported: replaces
>>>>
>>>> Supported: sdp-anat
>>>>
>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>
>>>> Session-Expires: 1800;refresher=uas
>>>>
>>>> Require: timer
>>>>
>>>> Supported: timer
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 277
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>
>>>> c=IN IP4 10.1.200.1
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=rtpmap:19 CN/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Received:
>>>>
>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>
>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>
>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>
>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>
>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 104 ACK
>>>>
>>>> Allow-Events: presence, kpml
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 243
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 10.1.10.18
>>>>
>>>> b=TIAS:64000
>>>>
>>>> b=AS:64
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 21476 RTP/AVP 0 101
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=ptime:20
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-15
>>>>
>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>
>>>> Sent:
>>>>
>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>
>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>
>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>> >;tag=2E6BC0B0-2268
>>>>
>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>
>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>
>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>
>>>> Max-Forwards: 70
>>>>
>>>> CSeq: 105 ACK
>>>>
>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>> sip:17705439047 at 64.154.41.150:5060
>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>
>>>> Allow-Events: telephone-event
>>>>
>>>> Content-Type: application/sdp
>>>>
>>>> Content-Length: 265
>>>>
>>>> v=0
>>>>
>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>
>>>> s=SIP Call
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> t=0 0
>>>>
>>>> m=audio 19458 RTP/AVP 0 101
>>>>
>>>> c=IN IP4 98.192.104.214
>>>>
>>>> a=inactive
>>>>
>>>> a=rtpmap:0 PCMU/8000
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> a=fmtp:101 0-16
>>>>
>>>> a=ptime:20
>>>>
>>>> Cisco3825#
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>
>>>>> ccsip message is what I'd go with just to see the signaling with no
>>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>>> to the signals you may need to expand from there.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Ryan
>>>>>
>>>>> What is the proper debug to use to caputre the useful information?
>>>>>
>>>>> Dane
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> Without sip messages I can't get any clues from that.
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks Ryan for the input
>>>>>>
>>>>>>
>>>>>> *On the call when I hold the call the following debug pops out....*
>>>>>>
>>>>>>
>>>>>> *Jan 15 17:56:05.246:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> *Jan 15 17:56:05.274:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> *Jan 15 17:56:05.286:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> *Jan 15 17:56:05.302:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> *Jan 15 17:56:05.322:
>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>> params for midcall INVITE
>>>>>>
>>>>>> *After I try to unhold the call the following debug comes out....*
>>>>>> **
>>>>>>
>>>>>> *Jan 15 17:56:18.874:
>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>> passthru hdrs to
>>>>>> container
>>>>>> *Jan 15 17:56:18.894:
>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>> passthru headers to
>>>>>> container
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>> not found.
>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>> *Jan 15 17:56:18.906:
>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>> params for midcall INVITE
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>> Cisco3825#
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>
>>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> *Hello Kenneth*
>>>>>>> **
>>>>>>> *I have restarted both CUCM servers so this should have restarted
>>>>>>> the services when the utils system restart happened*
>>>>>>> **
>>>>>>>
>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>> **
>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>> **
>>>>>>> *I connected a call calling from an external number to a DiD inside
>>>>>>> of my system. Once the call was connected I put the call on hold and the
>>>>>>> following debug came out..the music on hold played for the external caller
>>>>>>> *
>>>>>>>
>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12742
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12741
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.815:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=96, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12741
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12742
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>>
>>>>>>> *I then after that took off the hold and the following debug came
>>>>>>> out. The call on the PSDN side still played the hold music while there was
>>>>>>> no voice on the deskphone side.*
>>>>>>>
>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1046)
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12742
>>>>>>> *Jan 14 23:47:40.783:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12741
>>>>>>> *Jan 14 23:47:40.811:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.815:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=96, Call Id=12742
>>>>>>> *Jan 14 23:47:40.819:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>> *Jan 14 23:47:40.839:
>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=1516)
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=170, Call Id=12741
>>>>>>> *Jan 14 23:47:40.843:
>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>> Source Call Id=12742,
>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>> Source Call Id=12741,
>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>> Vad=ON(0x2),
>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>> Start=3996)
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event=171, Call Id=12742
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>> *Jan 14 23:47:40.863:
>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>
>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> My ITSP will only support 711ulaw for me currently I believe. They
>>>>>>>> hard coded it with me when I was initially setting it up.
>>>>>>>>
>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>> identifying if it is?
>>>>>>>>
>>>>>>>> Dane
>>>>>>>>
>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>
>>>>>>>>> Thanks for the Reply
>>>>>>>>> Oddly enough we are.
>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>
>>>>>>>>> Internally when I user puts another user on hold everything works.
>>>>>>>>> No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>> When I hit resume on the deskphone the MOH still played to the external
>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>
>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>>
>>>>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>>>>> outside SNR features?
>>>>>>>>>>
>>>>>>>>>> -Ryan
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>
>>>>>>>>>> Password:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cisco3825#
>>>>>>>>>>
>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>
>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>
>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>
>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>> (fc1)
>>>>>>>>>>
>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>
>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>
>>>>>>>>>> System image file is
>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>>> United
>>>>>>>>>> States and local country laws governing import, export, transfer
>>>>>>>>>> and
>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>
>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>> encryption.
>>>>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>>>>
>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>> product you
>>>>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>>>>> unable
>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>> immediately.
>>>>>>>>>>
>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products may
>>>>>>>>>> be found at:
>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>
>>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>>> email to
>>>>>>>>>> export at cisco.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>>>
>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>
>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>
>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>
>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>
>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>
>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>
>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> License Info:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> License UDI:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> Device# PID SN
>>>>>>>>>>
>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>>>> mobility soft key button on 9971 phones when a call is active, the phone
>>>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>>>> up the the mobile number it just plays what sounds like hold music on
both
>>>>>>>>>> ends of the call (I believe this music is coming from cucm but I haven't
>>>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>>>
>>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to take
>>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing but
the
>>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>
>>>>>>>>>> My topology is as follows..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>>>
>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>
>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/c37c0f95/attachment.html>

From mike.lydick at gmail.com Wed Jan 16 10:21:51 2013


From: mike.lydick at gmail.com (Mike Lydick)
Date: Wed, 16 Jan 2013 10:21:51 -0500
Subject: [cisco-voip] Auto Attendant/Call Handler issue
In-Reply-To: <5480028361612140863@unknownmsgid>
References: <5480028361612140863@unknownmsgid>
Message-ID: <CAFJjoZA0NB45qzdFc89=xEzz4eQ-BfyMroPRvEakUR6OYN6QFQ@mail.gmail.com>

There are several greetings for call handlers that can be setup. If you
used the standard greeting and have set the prompt to use the personal
greeting check which schedule is assigned to the call handler. Perhaps you
have weekdays assigned and you are hearing the closed greeting.

There are several settings that can affect transfer out of unity
connection.

CUCM -The SIP trunk outbound CSS should include all partitions/DNs that the
AA will transfer to

UCXN - The restriction table has transfer restrictions that can block the
transfer(default transfer and system transfer).
UCXN - If this a transfer to an non-subscriber or CH number the check the
greetings for "Allow Transfers to Numbers Not Associated with Users or Call
Handlers"

UCXN - If the transfer is using the subscriber account then (spell by name)
then check the transfer rules for the subscribers, the will have to be set
to transfer to extension.

mike

On Wed, Jan 16, 2013 at 8:42 AM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> elect a input Unity Connection tells me it cannot transfer me to this pers

Best Regards,

Mike Lydick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/ca992b77/attachment.html>

From kennethwhayes at gmail.com Wed Jan 16 10:26:10 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 10:26:10 -0500
Subject: [cisco-voip] Auto Attendant/Call Handler issue
In-Reply-To: <CAFJjoZA0NB45qzdFc89=xEzz4eQ-BfyMroPRvEakUR6OYN6QFQ@mail.gmail.com>
References: <5480028361612140863@unknownmsgid>
<CAFJjoZA0NB45qzdFc89=xEzz4eQ-BfyMroPRvEakUR6OYN6QFQ@mail.gmail.com>
Message-ID: <3821159732251180008@unknownmsgid>

So on the CUCM side the outbound CSS has access to all the DN's that I
doubled checked. On the Unity side. I checked the box for "Allow Transfers
to Numbers Not Associated with Users or Call Handlers" already, but I will
check the other items that you've recommended.

Sent from my iPad

On Jan 16, 2013, at 10:22 AM, Mike Lydick <mike.lydick at gmail.com> wrote:

There are several greetings for call handlers that can be setup. If you
used the standard greeting and have set the prompt to use the personal
greeting check which schedule is assigned to the call handler. Perhaps you
have weekdays assigned and you are hearing the closed greeting.

There are several settings that can affect transfer out of unity
connection.

CUCM -The SIP trunk outbound CSS should include all partitions/DNs that the
AA will transfer to

UCXN - The restriction table has transfer restrictions that can block the
transfer(default transfer and system transfer).
UCXN - If this a transfer to an non-subscriber or CH number the check the
greetings for "Allow Transfers to Numbers Not Associated with Users or Call
Handlers"

UCXN - If the transfer is using the subscriber account then (spell by name)
then check the transfer rules for the subscribers, the will have to be set
to transfer to extension.

mike

On Wed, Jan 16, 2013 at 8:42 AM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> elect a input Unity Connection tells me it cannot transfer me to this pers

Best Regards,

Mike Lydick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/45b4b05d/attachment.html>

From c3voip at nc.rr.com Wed Jan 16 09:52:55 2013


From: c3voip at nc.rr.com (c3voip)
Date: Wed, 16 Jan 2013 09:52:55 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
Message-ID: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call
is immediately answered by an auto-attendant, but the PRI channel does not
show as connected, so my phone does not show that the call is connected.
This is obviously some type of toll-charge avoidance. I have tried calling
from my cellphone and the behavior is the same.phone still displays
"calling" even though the AA is connected.

My problem is with trying to use Jabber either to control a hard phone or


using it as a soft phone, it cannot generate touch-tones to navigate the
auto-attendant. In the case of the soft phone, the keypad never becomes
available in the GUI and numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with
these calls?

Thanks,

-Chase
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d4689631/attachment.html>

From kennethwhayes at gmail.com Wed Jan 16 10:34:41 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 10:34:41 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
Message-ID: <1364349306572513421@unknownmsgid>

What type of gateway are you using? CUBE or H.323?

Sent from my iPad

On Jan 16, 2013, at 10:33 AM, c3voip <c3voip at nc.rr.com> wrote:

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call
is immediately answered by an auto-attendant, but the PRI channel does not
show as connected, so my phone does not show that the call is connected.
This is obviously some type of toll-charge avoidance. I have tried calling
from my cellphone and the behavior is the same?phone still displays
?calling? even though the AA is connected.

My problem is with trying to use Jabber either to control a hard phone or


using it as a soft phone, it cannot generate touch-tones to navigate the
auto-attendant. In the case of the soft phone, the keypad never becomes
available in the GUI and numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with
these calls?

Thanks,

-Chase

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/5fe22229/attachment.html>

From c3voip at nc.rr.com Wed Jan 16 10:43:56 2013


From: c3voip at nc.rr.com (c3voip)
Date: Wed, 16 Jan 2013 10:43:56 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <1364349306572513421@unknownmsgid>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
<1364349306572513421@unknownmsgid>
Message-ID: <003201cdf400$4b563290$e20297b0$@nc.rr.com>

MGCP, 2921

From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]


Sent: Wednesday, January 16, 2013 10:35 AM
To: c3voip
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call not connecting, but it's connected

What type of gateway are you using? CUBE or H.323?

Sent from my iPad

On Jan 16, 2013, at 10:33 AM, c3voip <c3voip at nc.rr.com> wrote:

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call
is immediately answered by an auto-attendant, but the PRI channel does not
show as connected, so my phone does not show that the call is connected.
This is obviously some type of toll-charge avoidance. I have tried calling
from my cellphone and the behavior is the same.phone still displays
"calling" even though the AA is connected.

My problem is with trying to use Jabber either to control a hard phone or


using it as a soft phone, it cannot generate touch-tones to navigate the
auto-attendant. In the case of the soft phone, the keypad never becomes
available in the GUI and numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with
these calls?

Thanks,

-Chase

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/ef87322b/attachment.html>

From kennethwhayes at gmail.com Wed Jan 16 10:47:02 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 10:47:02 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
Message-ID: <2890250229994222737@unknownmsgid>

Sounds like a DTMF...check your profile and make sure your sending the
right audio codec to the telco.

Sent from my iPad

On Jan 16, 2013, at 10:33 AM, c3voip <c3voip at nc.rr.com> wrote:

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call
is immediately answered by an auto-attendant, but the PRI channel does not
show as connected, so my phone does not show that the call is connected.
This is obviously some type of toll-charge avoidance. I have tried calling
from my cellphone and the behavior is the same?phone still displays
?calling? even though the AA is connected.

My problem is with trying to use Jabber either to control a hard phone or


using it as a soft phone, it cannot generate touch-tones to navigate the
auto-attendant. In the case of the soft phone, the keypad never becomes
available in the GUI and numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with
these calls?

Thanks,

-Chase

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/7c84fdd4/attachment.html>
From chrward at cisco.com Wed Jan 16 11:05:02 2013
From: chrward at cisco.com (Chris Ward (chrward))
Date: Wed, 16 Jan 2013 16:05:02 +0000
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To:
<4604610D6AAC164AA12B9E03AB79028B0B7B9E82@EXCHANGE3.local.cityofevanston.org>
References:
<4604610D6AAC164AA12B9E03AB79028B0B7B9E82@EXCHANGE3.local.cityofevanston.org>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>

I just finished working on a document with a couple other TMEs that is in the final
stages of being published to Cisco.com. Once it is, I will send you a link. The doc
team is giving it the final once over.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Madziarczyk, Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this (including moving
from physical to virtual), but they didn't think to record it, so all I have is the
powerpoint, which is sadly lacking in information. Has anyone seen a webex or
similar presentation that actually goes through the process and mentions all the
caveats?

JonM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/09500a61/attachment.html>

From abbaseo at gmail.com Wed Jan 16 11:15:25 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 16:15:25 +0000
Subject: [cisco-voip] XML service not working
Message-ID: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>

Folks,

I have added some XML services on the node but the phone goes into
Requesting when I hit the service in the phone.

any ideas!!

Thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/4105c0c0/attachment.html>
From kennethwhayes at gmail.com Wed Jan 16 11:18:56 2013
From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Wed, 16 Jan 2013 11:18:56 -0500
Subject: [cisco-voip] XML service not working
In-Reply-To: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
Message-ID: <837179558143865822@unknownmsgid>

Firewall isn't blocking anything is it?

Sent from my iPad

On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:

Folks,

I have added some XML services on the node but the phone goes into
Requesting when I hit the service in the phone.

any ideas!!

Thanks
--
@bbas..

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/65e902e6/attachment.html>

From dane.newman at gmail.com Wed Jan 16 11:26:50 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Wed, 16 Jan 2013 11:26:50 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <8922406544240900299@unknownmsgid>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
<CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
Message-ID: <CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>

Yes as per the screen shot the MOH servers are registered. How do In find
the audio bit rate? its just the default moh file I didnt change any
settings

On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> So have you looked in your media resources under music on hold server
> configurations to make sure it's registered to the right UCM? Also what
> audio bit rate is your MOH file?
>
> Sent from my iPad
>
> On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:
>
> I'm not sure at this point, I'll let some of the CUCM experts comment.
> It's possible during the hold conversation CUCM always sends delayed offer,
> but I don't have some good traces in front of me to confirm.
>
> You can check the original invite CUCM sends to see if there's SDP in
> that, and it would confirm the MTP is being allocated. If it's sending the
> INVITE without SDP, your MRG/MRGL or resources are misconfigured or in use.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com>wrote:
>
>> Nick
>>
>> Thanks for the assistance.
>>
>> This is the first time I am setting up a direct sip connection from cucm
>> to cube. I am used to making it an h323 connection. Attached are screen
>> shots of my trunk setup. MTP is checked off I believe already. Is there
>> a best way to go about troubleshooting cucm to figure out why its not
>> setting the stream back to active?
>>
>> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>
>>> It looks like CUCM isn't setting the stream back to active after putting
>>> it on hold. It sends the re-invite, and the 200 OK from the ITSP has the
>>> SDP continued with a=inactive.
>>>
>>> I don't have some good traces in front of me, but somewhere it needs to
>>> take that off. I don't think Asterisks is acting incorrectly by responding
>>> to a delayed offer INVITE that was previously a=inactive with a=inactive.
>>>
>>> What's also odd is that CUCM is sending the exact same INVITE after the
>>> first one completes, for both the hold and the resume. The CSeq isn't
>>> increasing, which I would expect it to.
>>>
>>> If you were to check 'MTP' required it may work around the problem, but
>>> I don't consider inserting MTP's to be a best practice.
>>>
>>> -nick
>>>
>>>
>>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>>
>>>> Bind your media and source to your outbound interface on your voice
>>>> service voip.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>> Below is a show run from the router
>>>>
>>>>
>>>> [OK]
>>>> Cisco3825#sh run
>>>> Building configuration...
>>>>
>>>> Current configuration : 10183 bytes
>>>> !
>>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>>>> version 15.1
>>>> service timestamps debug datetime msec
>>>> service timestamps log datetime msec
>>>> no service password-encryption
>>>> !
>>>> hostname Cisco3825
>>>> !
>>>> boot-start-marker
>>>> boot-end-marker
>>>> !
>>>> !
>>>> !
>>>> aaa new-model
>>>> !
>>>> !
>>>> aaa authentication login default local
>>>> aaa authentication login vpnauth local
>>>> aaa authorization exec default local
>>>> aaa authorization network default local
>>>> aaa authorization network vpnauth local
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> aaa session-id common
>>>> !
>>>> no network-clock-participate wic 0
>>>> !
>>>> dot11 syslog
>>>> ip source-route
>>>> !
>>>> ip cef
>>>> !
>>>> !
>>>> !
>>>> !
>>>> ip domain name datasc.local
>>>> ip inspect udp idle-time 1800
>>>> no ipv6 cef
>>>> !
>>>> multilink bundle-name authenticated
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> voice-card 0
>>>> dsp services dspfarm
>>>> !
>>>> !
>>>> !
>>>> voice service voip
>>>> ip address trusted list
>>>> ipv4 64.154.41.150 255.255.255.255
>>>> allow-connections sip to sip
>>>> fax protocol pass-through g711ulaw
>>>> sip
>>>> !
>>>> !
>>>> !
>>>> !
>>>> voice translation-rule 1
>>>> rule 1 /6784604564/ /200/
>>>> rule 2 /6784563290/ /100/
>>>> rule 3 /6784563291/ /101/
>>>> rule 4 /6784563292/ /102/
>>>> rule 5 /6784563293/ /103/
>>>> rule 6 /6784563294/ /104/
>>>> rule 7 /6784563295/ /105/
>>>> rule 8 /6784563296/ /106/
>>>> rule 9 /6784563297/ /107/
>>>> rule 10 /6784563298/ /108/
>>>> rule 11 /6784563299/ /109/
>>>> rule 12 /6784604565/ /125/
>>>> !
>>>> !
>>>> voice translation-profile incomingdid
>>>> translate called 1
>>>> !
>>>> !
>>>> crypto pki token default removal timeout 0
>>>> !
>>>> crypto pki trustpoint selfsigned
>>>> enrollment selfsigned
>>>> subject-name CN=connect.datasc.com
>>>> revocation-check crl
>>>> !
>>>> !
>>>> crypto pki certificate chain selfsigned
>>>> certificate self-signed 02
>>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101
>>>> 05050030
>>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63
>>>> 6F6D3125
>>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174
>>>> 6173632E
>>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031
>>>> 30313030
>>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461
>>>> 74617363
>>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338
>>>> 32352E64
>>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105
>>>> 0003818D
>>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2
>>>> 7729B93E
>>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0
>>>> 9A190598
>>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4
>>>> FABF9CA9
>>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC
>>>> 4EDD1712
>>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04
>>>> 05300301
>>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5
>>>> 8A571236
>>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A
>>>> 571236A1
>>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8
>>>> 8B742D4F
>>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1
>>>> B22BBB20
>>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3
>>>> EF724BD9
>>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3
>>>> 12E45933
>>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>>> quit
>>>> !
>>>> !
>>>> license udi pid CISCO3825 sn FTX1237A1T0
>>>> username xxxxxxx privilege 15 secret xxxxxx
>>>> !
>>>> redundancy
>>>> !
>>>> !
>>>> controller T1 0/0/0
>>>> !
>>>> controller T1 0/0/1
>>>> !
>>>> ip ssh version 2
>>>> !
>>>> !
>>>> crypto isakmp policy 10
>>>> encr aes
>>>> authentication pre-share
>>>> group 2
>>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>>> crypto isakmp fragmentation
>>>> !
>>>> crypto isakmp client configuration group datasc
>>>> key Recoil90
>>>> dns 4.2.2.2 4.2.2.1
>>>> domain datasc.local
>>>> pool vpnpool
>>>> save-password
>>>> !
>>>> crypto isakmp client configuration group datascsplit
>>>> key Recoil90
>>>> dns 4.2.2.2 4.2.2.1
>>>> domain datasc.local
>>>> pool vpnpool
>>>> acl 101
>>>> save-password
>>>> crypto isakmp profile datasc
>>>> match identity group datasc
>>>> client authentication list vpnauth
>>>> isakmp authorization list vpnauth
>>>> client configuration address respond
>>>> virtual-template 1
>>>> crypto isakmp profile datascsplit
>>>> match identity group datascsplit
>>>> client authentication list vpnauth
>>>> isakmp authorization list vpnauth
>>>> client configuration address respond
>>>> virtual-template 2
>>>> !
>>>> !
>>>> crypto ipsec transform-set transformset esp-aes
>>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>>> !
>>>> crypto ipsec profile VTI
>>>> set transform-set ezvpntransform
>>>> set isakmp-profile datasc
>>>> !
>>>> crypto ipsec profile VTI2
>>>> set transform-set ezvpntransform
>>>> set isakmp-profile datascsplit
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> interface Loopback1
>>>> ip address 10.1.150.1 255.255.255.0
>>>> ip nat inside
>>>> ip virtual-reassembly in
>>>> !
>>>> interface GigabitEthernet0/0
>>>> ip address dhcp
>>>> no ip redirects
>>>> no ip unreachables
>>>> no ip proxy-arp
>>>> ip nat outside
>>>> ip virtual-reassembly in
>>>> duplex auto
>>>> speed auto
>>>> media-type rj45
>>>> hold-queue 240000 in
>>>> !
>>>> interface GigabitEthernet0/1
>>>> ip address 10.1.200.1 255.255.255.252
>>>> ip nat inside
>>>> ip virtual-reassembly in
>>>> duplex auto
>>>> speed auto
>>>> media-type rj45
>>>> !
>>>> interface Virtual-Template1 type tunnel
>>>> ip unnumbered GigabitEthernet0/0
>>>> ip nat inside
>>>> ip virtual-reassembly in
>>>> tunnel source GigabitEthernet0/0
>>>> tunnel mode ipsec ipv4
>>>> tunnel protection ipsec profile VTI
>>>> !
>>>> interface Virtual-Template2 type tunnel
>>>> ip unnumbered GigabitEthernet0/0
>>>> ip nat inside
>>>> ip virtual-reassembly in
>>>> tunnel source GigabitEthernet0/0
>>>> tunnel mode ipsec ipv4
>>>> tunnel protection ipsec profile VTI2
>>>> !
>>>> interface Virtual-Template3
>>>> ip unnumbered GigabitEthernet0/0
>>>> ip nat outside
>>>> ip virtual-reassembly in
>>>> ip policy route-map anyconnecthop
>>>> !
>>>> !
>>>> router eigrp 1
>>>> maximum-paths 1
>>>> network 10.0.0.0
>>>> redistribute static
>>>> !
>>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>>> ip forward-protocol nd
>>>> ip http server
>>>> ip http secure-server
>>>> !
>>>> !
>>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>>> overload
>>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>>> GigabitEthernet0/0 80
>>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>>> GigabitEthernet0/0 5001
>>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>>> GigabitEthernet0/0 5001
>>>> !
>>>> ip access-list extended NATNETWORKS
>>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>> ip access-list extended anyconnecthop
>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>> !
>>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>>> !
>>>> !
>>>> !
>>>> !
>>>> route-map anyconnecthop permit 10
>>>> match ip address anyconnecthop
>>>> set ip next-hop 10.1.150.2
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> control-plane
>>>> !
>>>> !
>>>> !
>>>> !
>>>> mgcp profile default
>>>> !
>>>> !
>>>> dial-peer voice 100 voip
>>>> description Publisher
>>>> preference 1
>>>> destination-pattern 1..
>>>> session protocol sipv2
>>>> session target ipv4:10.1.80.10
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 101 voip
>>>> description Subscriber
>>>> preference 2
>>>> destination-pattern 1..
>>>> session target ipv4:10.1.80.11
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 200 voip
>>>> description Publisher
>>>> preference 1
>>>> destination-pattern 2..
>>>> progress_ind setup enable 3
>>>> progress_ind progress enable 8
>>>> session protocol sipv2
>>>> session target ipv4:10.1.80.10
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 300 voip
>>>> description incoming Calldid
>>>> translation-profile incoming incomingdid
>>>> preference 1
>>>> session protocol sipv2
>>>> session target sip-server
>>>> incoming called-number 678456329.
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 301 voip
>>>> description incoming Calldid
>>>> translation-profile incoming incomingdid
>>>> preference 1
>>>> session protocol sipv2
>>>> session target sip-server
>>>> incoming called-number 6784604565
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 302 voip
>>>> description incoming Calldid
>>>> translation-profile incoming incomingdid
>>>> preference 1
>>>> session protocol sipv2
>>>> session target sip-server
>>>> incoming called-number 6784604564
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 201 voip
>>>> description Publisher
>>>> preference 2
>>>> destination-pattern 2..
>>>> progress_ind setup enable 3
>>>> progress_ind progress enable 8
>>>> session protocol sipv2
>>>> session target ipv4:10.1.80.11
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> dial-peer voice 500 voip
>>>> description outgoing
>>>> preference 1
>>>> destination-pattern .T
>>>> session protocol sipv2
>>>> session target dns:sip.talkinip.net
>>>> dtmf-relay rtp-nte
>>>> codec g711ulaw
>>>> !
>>>> !
>>>> sip-ua
>>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>>> sipconnect.ipcomms.net
>>>> authentication username xxxxxx password 7 xxxxxxx
>>>> authentication username xxxxx password 7 xxxxxxx realm
>>>> sipconnect.ipcomms.net
>>>> set pstn-cause 3 sip-status 486
>>>> set pstn-cause 34 sip-status 486
>>>> set pstn-cause 47 sip-status 486
>>>> registrar dns:sipconnect.ipcomms.net expires 60
>>>> sip-server dns:sipconnect.ipcomms.net:5060
>>>> !
>>>> !
>>>> !
>>>> gatekeeper
>>>> shutdown
>>>> !
>>>> !
>>>> call-manager-fallback
>>>> max-conferences 8 gain -6
>>>> transfer-system full-consult
>>>> ip source-address 10.1.200.1 port 2000
>>>> max-ephones 20
>>>> max-dn 40
>>>> !
>>>> !
>>>> !
>>>> line con 0
>>>> line aux 0
>>>> line vty 0 4
>>>> privilege level 15
>>>> transport input ssh
>>>> line vty 5 15
>>>> privilege level 15
>>>> transport input ssh
>>>> !
>>>> scheduler allocate 20000 1000
>>>> !
>>>> webvpn gateway gateway_1
>>>> ip interface GigabitEthernet0/0 port 443
>>>> ssl trustpoint selfsigned
>>>> inservice
>>>> !
>>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>>> sequence 1
>>>> !
>>>> webvpn context datasc
>>>> title "DataSC VPN"
>>>> secondary-color white
>>>> title-color #CCCC66
>>>> text-color black
>>>> ssl authenticate verify all
>>>> !
>>>> url-list "Servers"
>>>> heading "Server"
>>>> !
>>>> !
>>>> policy group datasc
>>>> url-list "Servers"
>>>> functions svc-enabled
>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>> svc keep-client-installed
>>>> svc dns-server primary 4.2.2.2
>>>> svc dtls
>>>> virtual-template 3
>>>> default-group-policy datasc
>>>> aaa authentication list vpnauth
>>>> gateway gateway_1 domain datasc
>>>> inservice
>>>> !
>>>> !
>>>> webvpn context datascsplit
>>>> title "DataSC VPN Split"
>>>> secondary-color white
>>>> title-color #CCCC66
>>>> text-color black
>>>> ssl authenticate verify all
>>>> !
>>>> url-list "Servers"
>>>> heading "Server"
>>>> !
>>>> !
>>>> policy group datascsplit
>>>> url-list "Servers"
>>>> functions svc-enabled
>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>> svc split include acl 50
>>>> svc dns-server primary 4.2.2.2
>>>> svc dtls
>>>> default-group-policy datascsplit
>>>> aaa authentication list vpnauth
>>>> gateway gateway_1 domain datascsplit
>>>> inservice
>>>> !
>>>> end
>>>> Cisco3825#
>>>>
>>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> What do your media resources look like?
>>>>>
>>>>>
>>>>> Also can you show me a copy of your voice service voip config?
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thanks Ryan
>>>>>
>>>>> I see I am always getting a 200 ok message after my invites from the
>>>>> debug
>>>>>
>>>>> *Putting a call on HOLD*
>>>>>
>>>>>
>>>>>
>>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Supported: timer,resource-priority,replaces
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> User-Agent: Cisco-CUCM8.6
>>>>>
>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY
>>>>>
>>>>> CSeq: 102 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Supported: X-cisco-srtp-fallback
>>>>>
>>>>> Supported: Geolocation
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>
>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;party=calling;screen=yes;privacy=off
>>>>>
>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 240
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 0.0.0.0
>>>>>
>>>>> b=TIAS:64000
>>>>>
>>>>> b=AS:64
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-15
>>>>>
>>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>
>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Timestamp: 1358281168
>>>>>
>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 289
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-15
>>>>>
>>>>> a=rtpmap:19 CN/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 102 INVITE
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 239
>>>>>
>>>>> v=0
>>>>>
>>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>>
>>>>> s=Asterisk PBX 1.6.2.13
>>>>>
>>>>> c=IN IP4 64.154.41.150
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 13014 RTP/AVP 0 101
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 102 INVITE
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>> >;party=called;screen=no;privacy=off
>>>>>
>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>
>>>>> Supported: replaces
>>>>>
>>>>> Supported: sdp-anat
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Supported: timer
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 253
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19514 RTP/AVP 0 101
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 103 ACK
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 102 ACK
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Supported: timer,resource-priority,replaces
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> User-Agent: Cisco-CUCM8.6
>>>>>
>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Supported: X-cisco-srtp-fallback
>>>>>
>>>>> Supported: Geolocation
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>
>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;party=calling;screen=yes;privacy=off
>>>>>
>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>
>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Timestamp: 1358281168
>>>>>
>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 333
>>>>>
>>>>> v=0
>>>>>
>>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>>
>>>>> s=Asterisk PBX 1.6.2.13
>>>>>
>>>>> c=IN IP4 64.154.41.150
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>
>>>>> a=rtpmap:3 GSM/8000
>>>>>
>>>>> a=rtpmap:8 PCMA/8000
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:18 G729/8000
>>>>>
>>>>> a=fmtp:18 annexb=no
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 103 INVITE
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>> >;party=called;screen=no;privacy=off
>>>>>
>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>
>>>>> Supported: replaces
>>>>>
>>>>> Supported: sdp-anat
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Supported: timer
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 277
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=rtpmap:19 CN/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 103 ACK
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 209
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 0.0.0.0
>>>>>
>>>>> b=TIAS:64000
>>>>>
>>>>> b=AS:64
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 21476 RTP/AVP 0
>>>>>
>>>>> a=X-cisco-media:nomedia
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 104 ACK
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 251
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 0.0.0.0
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>
>>>>> c=IN IP4 0.0.0.0
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>>
>>>>>
>>>>> *Unholding the call the MOH continues on the previously held caller
>>>>> while the user hears nothing*
>>>>>
>>>>> **
>>>>>
>>>>>
>>>>>
>>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Supported: timer,resource-priority,replaces
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> User-Agent: Cisco-CUCM8.6
>>>>>
>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Supported: X-cisco-srtp-fallback
>>>>>
>>>>> Supported: Geolocation
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>
>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;party=calling;screen=yes;privacy=off
>>>>>
>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>> ;transport=tcp>;video;audio;video
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>
>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Timestamp: 1358281175
>>>>>
>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 333
>>>>>
>>>>> v=0
>>>>>
>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>
>>>>> s=Asterisk PBX 1.6.2.13
>>>>>
>>>>> c=IN IP4 64.154.41.150
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>
>>>>> a=rtpmap:3 GSM/8000
>>>>>
>>>>> a=rtpmap:8 PCMA/8000
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:18 G729/8000
>>>>>
>>>>> a=fmtp:18 annexb=no
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>> >;party=called;screen=no;privacy=off
>>>>>
>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>
>>>>> Supported: replaces
>>>>>
>>>>> Supported: sdp-anat
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Supported: timer
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 277
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=rtpmap:19 CN/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 104 ACK
>>>>>
>>>>> Allow-Events: presence, kpml
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 243
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.10.18
>>>>>
>>>>> b=TIAS:64000
>>>>>
>>>>> b=AS:64
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-15
>>>>>
>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 105 ACK
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 265
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> Cisco3825#
>>>>>
>>>>> Cisco3825#
>>>>>
>>>>>
>>>>>
>>>>> Cisco3825#
>>>>>
>>>>>
>>>>>
>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Supported: timer,resource-priority,replaces
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> User-Agent: Cisco-CUCM8.6
>>>>>
>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: presence
>>>>>
>>>>> Supported: X-cisco-srtp-fallback
>>>>>
>>>>> Supported: Geolocation
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>
>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;party=calling;screen=yes;privacy=off
>>>>>
>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>> ;transport=tcp>;video;audio;video
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>
>>>>> Min-SE: 1800
>>>>>
>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>
>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> Timestamp: 1358281175
>>>>>
>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>
>>>>> Expires: 180
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 100 Trying
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Length: 0
>>>>>
>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> CSeq: 105 INVITE
>>>>>
>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>> INFO
>>>>>
>>>>> Supported: replaces, timer
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 333
>>>>>
>>>>> v=0
>>>>>
>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>
>>>>> s=Asterisk PBX 1.6.2.13
>>>>>
>>>>> c=IN IP4 64.154.41.150
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>
>>>>> a=rtpmap:3 GSM/8000
>>>>>
>>>>> a=rtpmap:8 PCMA/8000
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:18 G729/8000
>>>>>
>>>>> a=fmtp:18 annexb=no
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> SIP/2.0 200 OK
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> CSeq: 104 INVITE
>>>>>
>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>> >;party=called;screen=no;privacy=off
>>>>>
>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>
>>>>> Supported: replaces
>>>>>
>>>>> Supported: sdp-anat
>>>>>
>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>
>>>>> Session-Expires: 1800;refresher=uas
>>>>>
>>>>> Require: timer
>>>>>
>>>>> Supported: timer
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 277
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>
>>>>> c=IN IP4 10.1.200.1
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=rtpmap:19 CN/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Received:
>>>>>
>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>
>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>
>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>
>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 104 ACK
>>>>>
>>>>> Allow-Events: presence, kpml
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 243
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 10.1.10.18
>>>>>
>>>>> b=TIAS:64000
>>>>>
>>>>> b=AS:64
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-15
>>>>>
>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>
>>>>> Sent:
>>>>>
>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>
>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>
>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>> >;tag=2E6BC0B0-2268
>>>>>
>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>
>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>
>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>
>>>>> Max-Forwards: 70
>>>>>
>>>>> CSeq: 105 ACK
>>>>>
>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>
>>>>> Allow-Events: telephone-event
>>>>>
>>>>> Content-Type: application/sdp
>>>>>
>>>>> Content-Length: 265
>>>>>
>>>>> v=0
>>>>>
>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>
>>>>> s=SIP Call
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> t=0 0
>>>>>
>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>
>>>>> c=IN IP4 98.192.104.214
>>>>>
>>>>> a=inactive
>>>>>
>>>>> a=rtpmap:0 PCMU/8000
>>>>>
>>>>> a=rtpmap:101 telephone-event/8000
>>>>>
>>>>> a=fmtp:101 0-16
>>>>>
>>>>> a=ptime:20
>>>>>
>>>>> Cisco3825#
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>
>>>>>> ccsip message is what I'd go with just to see the signaling with no
>>>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>>>> to the signals you may need to expand from there.
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>> What is the proper debug to use to caputre the useful information?
>>>>>>
>>>>>> Dane
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> Without sip messages I can't get any clues from that.
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks Ryan for the input
>>>>>>>
>>>>>>>
>>>>>>> *On the call when I hold the call the following debug pops out....*
>>>>>>>
>>>>>>>
>>>>>>> *Jan 15 17:56:05.246:
>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>> passthru hdrs to
>>>>>>> container
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1
>>>>>>> not found.
>>>>>>> *Jan 15 17:56:05.274:
>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>> passthru headers to
>>>>>>> container
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>>> not found.
>>>>>>> *Jan 15 17:56:05.286:
>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>> passthru hdrs to
>>>>>>> container
>>>>>>> *Jan 15 17:56:05.302:
>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>> passthru headers to
>>>>>>> container
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>>> not found.
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> *Jan 15 17:56:05.322:
>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>>> params for midcall INVITE
>>>>>>>
>>>>>>> *After I try to unhold the call the following debug comes out....*
>>>>>>> **
>>>>>>>
>>>>>>> *Jan 15 17:56:18.874:
>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>> passthru hdrs to
>>>>>>> container
>>>>>>> *Jan 15 17:56:18.894:
>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>> passthru headers to
>>>>>>> container
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1
>>>>>>> not found.
>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>> *Jan 15 17:56:18.906:
>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>>> params for midcall INVITE
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>>
>>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>>
>>>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>>
>>>>>>>> -Ryan
>>>>>>>>
>>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> *Hello Kenneth*
>>>>>>>> **
>>>>>>>> *I have restarted both CUCM servers so this should have restarted
>>>>>>>> the services when the utils system restart happened*
>>>>>>>> **
>>>>>>>>
>>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>>> **
>>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>>> **
>>>>>>>> *I connected a call calling from an external number to a DiD
>>>>>>>> inside of my system. Once the call was connected I put the call on hold
>>>>>>>> and the following debug came out..the music on hold played for the
external
>>>>>>>> caller*
>>>>>>>>
>>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1046)
>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1046)
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=170, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=171, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=96, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=170, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=3996)
>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=3996)
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=171, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>>
>>>>>>>> *I then after that took off the hold and the following debug came
>>>>>>>> out. The call on the PSDN side still played the hold music while there
was
>>>>>>>> no voice on the deskphone side.*
>>>>>>>>
>>>>>>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1046)
>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1046)
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=170, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=171, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=96, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=1516)
>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=170, Call Id=12741
>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>> Source Call Id=12742,
>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=3996)
>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>> Source Call Id=12741,
>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>> Vad=ON(0x2),
>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>> Start=3996)
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event=171, Call Id=12742
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> My ITSP will only support 711ulaw for me currently I believe.
>>>>>>>>> They hard coded it with me when I was initially setting it up.
>>>>>>>>>
>>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>>> identifying if it is?
>>>>>>>>>
>>>>>>>>> Dane
>>>>>>>>>
>>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>>
>>>>>>>>>> Thanks for the Reply
>>>>>>>>>> Oddly enough we are.
>>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>>
>>>>>>>>>> Internally when I user puts another user on hold everything
>>>>>>>>>> works. No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>>> When I hit resume on the deskphone the MOH still played to the external
>>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Do you get similar behavior if you just hold and resume the call
>>>>>>>>>>> outside SNR features?
>>>>>>>>>>>
>>>>>>>>>>> -Ryan
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>>
>>>>>>>>>>> Password:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>
>>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>>
>>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>>
>>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>>
>>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>>> (fc1)
>>>>>>>>>>>
>>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>>
>>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>>
>>>>>>>>>>> System image file is
>>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>>>> United
>>>>>>>>>>> States and local country laws governing import, export, transfer
>>>>>>>>>>> and
>>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>>
>>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>>> encryption.
>>>>>>>>>>> Importers, exporters, distributors and users are responsible for
>>>>>>>>>>>
>>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>>> product you
>>>>>>>>>>> agree to comply with applicable laws and regulations. If you are
>>>>>>>>>>> unable
>>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>>> immediately.
>>>>>>>>>>>
>>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products
>>>>>>>>>>> may be found at:
>>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>>
>>>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>>>> email to
>>>>>>>>>>> export at cisco.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>>>>
>>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>>
>>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>>
>>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>>
>>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>>
>>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>>
>>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>>
>>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> License Info:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> License UDI:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> Device# PID SN
>>>>>>>>>>>
>>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>>>>> mobility soft key button on 9971 phones when a call is active, the
phone
>>>>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>>>>> up the the mobile number it just plays what sounds like hold music on
both
>>>>>>>>>>> ends of the call (I believe this music is coming from cucm but I
haven't
>>>>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>>>>
>>>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to
take
>>>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing but
the
>>>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>>
>>>>>>>>>>> My topology is as follows..
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>>>>
>>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/520d5285/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: moh.jpg
Type: image/jpeg
Size: 193494 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/520d5285/attachment.jpg>

From btalley at gmail.com Wed Jan 16 11:29:16 2013


From: btalley at gmail.com (Bill Talley)
Date: Wed, 16 Jan 2013 10:29:16 -0600
Subject: [cisco-voip] XML service not working
In-Reply-To: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
Message-ID: <36026140136594389@unknownmsgid>

Try accessing the service URL from your web browser. You don't need the
port numbers in the URL. I did the same and eventually found this info for
the service you're trying to utilize.

http://www.andtek.com/communications-products-freexml.html

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

On Jan 16, 2013, at 10:18 AM, abbas Wali <abbaseo at gmail.com> wrote:

Folks,

I have added some XML services on the node but the phone goes into
Requesting when I hit the service in the phone.

any ideas!!

Thanks
--
@bbas..

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/0129d147/attachment.html>

From abbaseo at gmail.com Wed Jan 16 11:30:28 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 16:30:28 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <837179558143865822@unknownmsgid>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
Message-ID: <CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>

not a firewall guy, but just wondering if i can access their main website
http://www.andtek.com/communications-products-freexml.html
and also i have checked nothing comes up when I go to the URL
*http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from web
browers too (proxy disabled)*

On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:

> Firewall isn't blocking anything is it?


>
> Sent from my iPad
>
> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>
> Folks,
>
> I have added some XML services on the node but the phone goes into
> Requesting when I hit the service in the phone.
>
>
>
> any ideas!!
>
> Thanks
> --
> @bbas..
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/c96216b9/attachment.html>

From abbaseo at gmail.com Wed Jan 16 11:34:12 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 16:34:12 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
Message-ID: <CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>

sorry just confirmed, it does work from the web b.


*http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
which means there is no issue with the firewall or DNS
*
On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:
> not a firewall guy, but just wondering if i can access their main website
> http://www.andtek.com/communications-products-freexml.html
> and also i have checked nothing comes up when I go to the URL
> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from web
> browers too (proxy disabled)*
>
>
> On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>
>> Firewall isn't blocking anything is it?
>>
>> Sent from my iPad
>>
>> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> Folks,
>>
>> I have added some XML services on the node but the phone goes into
>> Requesting when I hit the service in the phone.
>>
>>
>>
>> any ideas!!
>>
>> Thanks
>> --
>> @bbas..
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/a608a442/attachment.html>

From c3voip at nc.rr.com Wed Jan 16 11:38:46 2013


From: c3voip at nc.rr.com (c3voip)
Date: Wed, 16 Jan 2013 11:38:46 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <2890250229994222737@unknownmsgid>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
<2890250229994222737@unknownmsgid>
Message-ID: <004601cdf407$f4a2a2a0$dde7e7e0$@nc.rr.com>
This is not a DTMF issue, this is a problem with Jabber where it doesn't
enable the keypad until it sees that the call is connected.

From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]


Sent: Wednesday, January 16, 2013 10:47 AM
To: c3voip
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call not connecting, but it's connected

Sounds like a DTMF...check your profile and make sure your sending the right
audio codec to the telco.

Sent from my iPad

On Jan 16, 2013, at 10:33 AM, c3voip <c3voip at nc.rr.com> wrote:

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call
is immediately answered by an auto-attendant, but the PRI channel does not
show as connected, so my phone does not show that the call is connected.
This is obviously some type of toll-charge avoidance. I have tried calling
from my cellphone and the behavior is the same.phone still displays
"calling" even though the AA is connected.

My problem is with trying to use Jabber either to control a hard phone or


using it as a soft phone, it cannot generate touch-tones to navigate the
auto-attendant. In the case of the soft phone, the keypad never becomes
available in the GUI and numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with
these calls?

Thanks,

-Chase

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/8d17938b/attachment.html>

From jmad at cityofevanston.org Wed Jan 16 11:45:22 2013


From: jmad at cityofevanston.org (Madziarczyk, Jonathan)
Date: Wed, 16 Jan 2013 10:45:22 -0600
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
References:
<4604610D6AAC164AA12B9E03AB79028B0B7B9E82@EXCHANGE3.local.cityofevanston.org>
<C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
Message-ID:
<4604610D6AAC164AA12B9E03AB79028B0B7B9E98@EXCHANGE3.local.cityofevanston.org>

You are the man Chris!

Unless Chris is short for Christine, at which point you are probably a
woman, but even then you are still the man...in the gender-neutral,
colloquial, congratulatory way.

Thanks!

JonM

From: Chris Ward (chrward) [mailto:chrward at cisco.com]


Sent: Wednesday, January 16, 2013 10:05 AM
To: Madziarczyk, Jonathan; cisco-voip at puck.nether.net
Subject: RE: Upgrading from 6x to 9x?

I just finished working on a document with a couple other TMEs that is


in the final stages of being published to Cisco.com. Once it is, I will
send you a link. The doc team is giving it the final once over.

+Chris

Unity Connection TME

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Madziarczyk,
Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this


(including moving from physical to virtual), but they didn't think to
record it, so all I have is the powerpoint, which is sadly lacking in
information. Has anyone seen a webex or similar presentation that
actually goes through the process and mentions all the caveats?

JonM

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/fb0d0fac/attachment.html>

From lelio at uoguelph.ca Wed Jan 16 11:49:17 2013


From: lelio at uoguelph.ca (Lelio Fulgenzi)
Date: Wed, 16 Jan 2013 11:49:17 -0500 (EST)
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
Message-ID: <396590408.1220246.1358354957310.JavaMail.root@squeaky.cs.uoguelph.ca>

if you could post to the list, that would be helpful. thanks!

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)

----- Original Message -----


From: "Chris Ward (chrward)" <chrward at cisco.com>
To: "Jonathan Madziarczyk" <jmad at cityofevanston.org>, cisco-voip at
puck.nether.net
Sent: Wednesday, January 16, 2013 11:05:02 AM
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

I just finished working on a document with a couple other TMEs that is in the final
stages of being published to Cisco.com. Once it is, I will send you a link. The doc
team is giving it the final once over.

+Chris

Unity Connection TME


From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Madziarczyk, Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this (including moving
from physical to virtual), but they didn?t think to record it, so all I have is the
powerpoint, which is sadly lacking in information. Has anyone seen a webex or
similar presentation that actually goes through the process and mentions all the
caveats?

JonM
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/6ebc78f8/attachment.html>

From rratliff at cisco.com Wed Jan 16 12:18:09 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 16 Jan 2013 12:18:09 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid> <CA!
M-K-NpMyUYafvt4HcEgghMyfWY0xnzB0xw9JqZrNPU4Lf8vEA@mail.gmail.com>
<CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
Message-ID: <36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
Having the MOH servers registered is step 1 of about 10 that have to happen for MOH
to be allocated for the call.
In the SIP signaling you sent there was no possibility you heard MOH from CUCM
because the media stream never went back to active after the hold. Can your
Asterix play MOH?

You need to look at ccm traces to debug this further. If you can't figure it out,
then it's time to call TAC.

You should also take a look at your active call before it's getting put on hold.
You've got MTP Required set on the SIP trunk, but if an MTP was really getting
allocated I don't believe we'd ever set the media inactive to the trunk, we'd be
telling the MTP about media changes and the trunk would just see one media stream
to the MTP for the entire call. At the same time if we tried to allocate an MTP
but failed, that usually ends up disabling supplementary services for the call,
which means you never would have been allowed to hold in the first place. It's
certainly possible that has changed for SIP EO MTPs but for now what is in that
signaling doesn't jive with what you've sent in your config and description of
events.

Have you tried resetting the SIP trunk in CUCM yet?

-Ryan

On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com> wrote:

Yes as per the screen shot the MOH servers are registered. How do In find the
audio bit rate? its just the default moh file I didnt change any settings

On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
So have you looked in your media resources under music on hold server
configurations to make sure it's registered to the right UCM? Also what audio bit
rate is your MOH file?

Sent from my iPad

On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:

> I'm not sure at this point, I'll let some of the CUCM experts comment. It's
possible during the hold conversation CUCM always sends delayed offer, but I don't
have some good traces in front of me to confirm.
>
> You can check the original invite CUCM sends to see if there's SDP in that, and
it would confirm the MTP is being allocated. If it's sending the INVITE without
SDP, your MRG/MRGL or resources are misconfigured or in use.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
> Nick
>
> Thanks for the assistance.
>
> This is the first time I am setting up a direct sip connection from cucm to cube.
I am used to making it an h323 connection. Attached are screen shots of my trunk
setup. MTP is checked off I believe already. Is there a best way to go about
troubleshooting cucm to figure out why its not setting the stream back to active?
>
> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com> wrote:
> It looks like CUCM isn't setting the stream back to active after putting it on
hold. It sends the re-invite, and the 200 OK from the ITSP has the SDP continued
with a=inactive.
>
> I don't have some good traces in front of me, but somewhere it needs to take that
off. I don't think Asterisks is acting incorrectly by responding to a delayed offer
INVITE that was previously a=inactive with a=inactive.
>
> What's also odd is that CUCM is sending the exact same INVITE after the first one
completes, for both the hold and the resume. The CSeq isn't increasing, which I
would expect it to.
>
> If you were to check 'MTP' required it may work around the problem, but I don't
consider inserting MTP's to be a best practice.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
> Bind your media and source to your outbound interface on your voice service voip.
>
> Sent from my iPhone
>
> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Below is a show run from the router
>>
>>
>> [OK]
>> Cisco3825#sh run
>> Building configuration...
>>
>> Current configuration : 10183 bytes
>> !
>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>> version 15.1
>> service timestamps debug datetime msec
>> service timestamps log datetime msec
>> no service password-encryption
>> !
>> hostname Cisco3825
>> !
>> boot-start-marker
>> boot-end-marker
>> !
>> !
>> !
>> aaa new-model
>> !
>> !
>> aaa authentication login default local
>> aaa authentication login vpnauth local
>> aaa authorization exec default local
>> aaa authorization network default local
>> aaa authorization network vpnauth local
>> !
>> !
>> !
>> !
>> !
>> aaa session-id common
>> !
>> no network-clock-participate wic 0
>> !
>> dot11 syslog
>> ip source-route
>> !
>> ip cef
>> !
>> !
>> !
>> !
>> ip domain name datasc.local
>> ip inspect udp idle-time 1800
>> no ipv6 cef
>> !
>> multilink bundle-name authenticated
>> !
>> !
>> !
>> !
>> !
>> voice-card 0
>> dsp services dspfarm
>> !
>> !
>> !
>> voice service voip
>> ip address trusted list
>> ipv4 64.154.41.150 255.255.255.255
>> allow-connections sip to sip
>> fax protocol pass-through g711ulaw
>> sip
>> !
>> !
>> !
>> !
>> voice translation-rule 1
>> rule 1 /6784604564/ /200/
>> rule 2 /6784563290/ /100/
>> rule 3 /6784563291/ /101/
>> rule 4 /6784563292/ /102/
>> rule 5 /6784563293/ /103/
>> rule 6 /6784563294/ /104/
>> rule 7 /6784563295/ /105/
>> rule 8 /6784563296/ /106/
>> rule 9 /6784563297/ /107/
>> rule 10 /6784563298/ /108/
>> rule 11 /6784563299/ /109/
>> rule 12 /6784604565/ /125/
>> !
>> !
>> voice translation-profile incomingdid
>> translate called 1
>> !
>> !
>> crypto pki token default removal timeout 0
>> !
>> crypto pki trustpoint selfsigned
>> enrollment selfsigned
>> subject-name CN=connect.datasc.com
>> revocation-check crl
>> !
>> !
>> crypto pki certificate chain selfsigned
>> certificate self-signed 02
>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>> quit
>> !
>> !
>> license udi pid CISCO3825 sn FTX1237A1T0
>> username xxxxxxx privilege 15 secret xxxxxx
>> !
>> redundancy
>> !
>> !
>> controller T1 0/0/0
>> !
>> controller T1 0/0/1
>> !
>> ip ssh version 2
>> !
>> !
>> crypto isakmp policy 10
>> encr aes
>> authentication pre-share
>> group 2
>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>> crypto isakmp fragmentation
>> !
>> crypto isakmp client configuration group datasc
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> save-password
>> !
>> crypto isakmp client configuration group datascsplit
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> acl 101
>> save-password
>> crypto isakmp profile datasc
>> match identity group datasc
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 1
>> crypto isakmp profile datascsplit
>> match identity group datascsplit
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 2
>> !
>> !
>> crypto ipsec transform-set transformset esp-aes
>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>> !
>> crypto ipsec profile VTI
>> set transform-set ezvpntransform
>> set isakmp-profile datasc
>> !
>> crypto ipsec profile VTI2
>> set transform-set ezvpntransform
>> set isakmp-profile datascsplit
>> !
>> !
>> !
>> !
>> !
>> !
>> !
>> interface Loopback1
>> ip address 10.1.150.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly in
>> !
>> interface GigabitEthernet0/0
>> ip address dhcp
>> no ip redirects
>> no ip unreachables
>> no ip proxy-arp
>> ip nat outside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> hold-queue 240000 in
>> !
>> interface GigabitEthernet0/1
>> ip address 10.1.200.1 255.255.255.252
>> ip nat inside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> !
>> interface Virtual-Template1 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI
>> !
>> interface Virtual-Template2 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI2
>> !
>> interface Virtual-Template3
>> ip unnumbered GigabitEthernet0/0
>> ip nat outside
>> ip virtual-reassembly in
>> ip policy route-map anyconnecthop
>> !
>> !
>> router eigrp 1
>> maximum-paths 1
>> network 10.0.0.0
>> redistribute static
>> !
>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>> ip forward-protocol nd
>> ip http server
>> ip http secure-server
>> !
>> !
>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0 overload
>> ip nat inside source static tcp 10.1.50.150 80 interface GigabitEthernet0/0 80
>> ip nat inside source static tcp 10.1.80.100 5001 interface GigabitEthernet0/0
5001
>> ip nat inside source static udp 10.1.80.100 5001 interface GigabitEthernet0/0
5001
>> !
>> ip access-list extended NATNETWORKS
>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> ip access-list extended anyconnecthop
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> !
>> access-list 50 permit 10.0.0.0 0.255.255.255
>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>> !
>> !
>> !
>> !
>> route-map anyconnecthop permit 10
>> match ip address anyconnecthop
>> set ip next-hop 10.1.150.2
>> !
>> !
>> !
>> !
>> !
>> control-plane
>> !
>> !
>> !
>> !
>> mgcp profile default
>> !
>> !
>> dial-peer voice 100 voip
>> description Publisher
>> preference 1
>> destination-pattern 1..
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 101 voip
>> description Subscriber
>> preference 2
>> destination-pattern 1..
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 200 voip
>> description Publisher
>> preference 1
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 300 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 678456329.
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 301 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604565
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 302 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604564
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 201 voip
>> description Publisher
>> preference 2
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 500 voip
>> description outgoing
>> preference 1
>> destination-pattern .T
>> session protocol sipv2
>> session target dns:sip.talkinip.net
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> !
>> sip-ua
>> credentials username xxxxxxxx password 7 xxxxxxx realm sipconnect.ipcomms.net
>> authentication username xxxxxx password 7 xxxxxxx
>> authentication username xxxxx password 7 xxxxxxx realm sipconnect.ipcomms.net
>> set pstn-cause 3 sip-status 486
>> set pstn-cause 34 sip-status 486
>> set pstn-cause 47 sip-status 486
>> registrar dns:sipconnect.ipcomms.net expires 60
>> sip-server dns:sipconnect.ipcomms.net:5060
>> !
>> !
>> !
>> gatekeeper
>> shutdown
>> !
>> !
>> call-manager-fallback
>> max-conferences 8 gain -6
>> transfer-system full-consult
>> ip source-address 10.1.200.1 port 2000
>> max-ephones 20
>> max-dn 40
>> !
>> !
>> !
>> line con 0
>> line aux 0
>> line vty 0 4
>> privilege level 15
>> transport input ssh
>> line vty 5 15
>> privilege level 15
>> transport input ssh
>> !
>> scheduler allocate 20000 1000
>> !
>> webvpn gateway gateway_1
>> ip interface GigabitEthernet0/0 port 443
>> ssl trustpoint selfsigned
>> inservice
>> !
>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg sequence 1
>> !
>> webvpn context datasc
>> title "DataSC VPN"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datasc
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc keep-client-installed
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> virtual-template 3
>> default-group-policy datasc
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datasc
>> inservice
>> !
>> !
>> webvpn context datascsplit
>> title "DataSC VPN Split"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datascsplit
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc split include acl 50
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> default-group-policy datascsplit
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datascsplit
>> inservice
>> !
>> end
>> Cisco3825#
>>
>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>> What do your media resources look like?
>>
>>
>> Also can you show me a copy of your voice service voip config?
>>
>> Sent from my iPad
>>
>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>>> Thanks Ryan
>>>
>>> I see I am always getting a 200 ok message after my invites from the debug
>>>
>>> Putting a call on HOLD
>>>
>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 102 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 240
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 289
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 239
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 253
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 102 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 209
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0
>>>
>>> a=X-cisco-media:nomedia
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 251
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>>
>>> Unholding the call the MOH continues on the previously held caller while the
user hears nothing
>>>
>>>
>>>
>>>
>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>> Cisco3825#
>>>
>>>
>>> Cisco3825#
>>>
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> ccsip message is what I'd go with just to see the signaling with no other
stuff. Depending on what that shows and what your gateway is doing to the signals
you may need to expand from there.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Ryan
>>>
>>> What is the proper debug to use to caputre the useful information?
>>>
>>> Dane
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> Without sip messages I can't get any clues from that.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Thanks Ryan for the input
>>>
>>>
>>> On the call when I hold the call the following debug pops out....
>>>
>>>
>>> *Jan 15 17:56:05.246: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> *Jan 15 17:56:05.274: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> *Jan 15 17:56:05.286: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> *Jan 15 17:56:05.302: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:05.322: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE
>>>
>>> After I try to unhold the call the following debug comes out....
>>>
>>>
>>> *Jan 15 17:56:18.874: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> *Jan 15 17:56:18.894: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:18.906: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> Given you have an ITSP it's most likely the initial hold that's failing, which
is only manifesting when you try to resume it. If you haven't noticed already
this is also very likely causing transfers to fail.
>>>
>>> Take a look at the SIP signaling for a call. I believe the most common cause
to this is the ITSP not handling our transition from active->inactive->sendonly-
>active from hold to MOH to resume. The "Duplex Streaming Enabled" parameter is
there just for this type of problem.
>>>
>>> -Ryan
>>>
>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Hello Kenneth
>>>
>>> I have restarted both CUCM servers so this should have restarted the services
when the utils system restart happened
>>>
>>>
>>> on my router I see I am using g711 from the debug
>>>
>>> I ran a debug voip ccapi inout
>>>
>>> I connected a call calling from an external number to a DiD inside of my
system. Once the call was connected I put the call on hold and the following debug
came out..the music on hold played for the external caller
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>>
>>> I then after that took off the hold and the following debug came out. The call
on the PSDN side still played the hold music while there was no voice on the
deskphone side.
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>> Have you also restarted the Cisco IP Media Services?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>>> My ITSP will only support 711ulaw for me currently I believe. They hard coded
it with me when I was initially setting it up.
>>>>
>>>> Do you think this could be a codec issue? How would I go about identifying if
it is?
>>>>
>>>> Dane
>>>>
>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>>> Have you tried different audio codecs?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>>> Ryan (sorry I forgot to reply to all)
>>>>>
>>>>> Thanks for the Reply
>>>>> Oddly enough we are.
>>>>> This probably has something to do with MOH in general?
>>>>>
>>>>> Internally when I user puts another user on hold everything works. No MOH
plays and they can hold and unhold the call just fine.
>>>>> I tested calling from an external number. Once I put the external caller on
hold the MOH played but I was unable to resume the call. When I hit resume on the
deskphone the MOH still played to the external caller and there was no sound on the
deskphone.
>>>>>
>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>>>> Do you get similar behavior if you just hold and resume the call outside SNR
features?
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>>
>>>>> Using keyboard-interactive authentication.
>>>>> Password:
>>>>>
>>>>> Cisco3825#
>>>>> Cisco3825#sh ver
>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version
15.1
>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>
>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>
>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>> System returned to ROM by power-on
>>>>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>> Last reload type: Normal Reload
>>>>>
>>>>>
>>>>> This product contains cryptographic features and is subject to United
>>>>> States and local country laws governing import, export, transfer and
>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>> third-party authority to import, export, distribute or use encryption.
>>>>> Importers, exporters, distributors and users are responsible for
>>>>> compliance with U.S. and local country laws. By using this product you
>>>>> agree to comply with applicable laws and regulations. If you are unable
>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>
>>>>> A summary of U.S. laws governing Cisco cryptographic products may be found
at:
>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>
>>>>> If you require further assistance please contact us by sending email to
>>>>> export at cisco.com.
>>>>>
>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>> Processor board ID FTX1237A1T0
>>>>> 2 Gigabit Ethernet interfaces
>>>>> 2 Channelized T1/PRI ports
>>>>> 1 Virtual Private Network (VPN) Module
>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>> 479K bytes of NVRAM.
>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>
>>>>>
>>>>> License Info:
>>>>>
>>>>> License UDI:
>>>>>
>>>>> -------------------------------------------------
>>>>> Device# PID SN
>>>>>
>>>>> Sent from my mobile device
>>>>>
>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>>>>
>>>>>> What version of code are you running on the CUBE?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I have an issue when users are connected to a call and hit the mobility
soft key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>>>>>
>>>>>>> In another senario with what I believe is the same issue. If a user picks
up on there cell phone first (using single number reach) opposed to the deskphone
the call is connected with 2 way voice and no issues exist. If the user then hangs
up his cell phone with the intent to take the call on his deskphone the calling
party starts hearing the hold music. Once the user picks up the call on his
deskphone he hears nothing but the calling party is still hearing the hold music.
It is not working as intended where 2 way voice happens once the user hangs up his
mobile phone and picks up on his deskphone 2 way voice should happen.
>>>>>>>
>>>>>>> My topology is as follows..
>>>>>>>
>>>>>>>
>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>
>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>>>>>
>>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>

<moh.jpg>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/ac9923b8/attachment.html>

From rratliff at cisco.com Wed Jan 16 12:24:02 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 16 Jan 2013 12:24:02 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <004601cdf407$f4a2a2a0$dde7e7e0$@nc.rr.com>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
<2890250229994222737@unknownmsgid>
<004601cdf407$f4a2a2a0$dde7e7e0$@nc.rr.com>
Message-ID: <C10BDC2E-E4B6-4F54-9C9E-6CF7C8871E58@cisco.com>

And that would be a bug or feature request. The endpoint has to allow DTMF entry
any time media is established regardless of call state. The fact it happens
during CTI control of a desk phone is particularly ugly.

Let me see if I can dig up a bug.

-Ryan

On Jan 16, 2013, at 11:38 AM, c3voip <c3voip at nc.rr.com> wrote:


This is not a DTMF issue, this is a problem with Jabber where it doesn?t enable the
keypad until it sees that the call is connected.

From: Kenneth Hayes [mailto:kennethwhayes at gmail.com]


Sent: Wednesday, January 16, 2013 10:47 AM
To: c3voip
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call not connecting, but it's connected

Sounds like a DTMF...check your profile and make sure your sending the right audio
codec to the telco.

Sent from my iPad

On Jan 16, 2013, at 10:33 AM, c3voip <c3voip at nc.rr.com> wrote:

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call is
immediately answered by an auto-attendant, but the PRI channel does not show as
connected, so my phone does not show that the call is connected. This is obviously
some type of toll-charge avoidance. I have tried calling from my cellphone and the
behavior is the same?phone still displays ?calling? even though the AA is
connected.

My problem is with trying to use Jabber either to control a hard phone or using it
as a soft phone, it cannot generate touch-tones to navigate the auto-attendant. In
the case of the soft phone, the keypad never becomes available in the GUI and
numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with these
calls?

Thanks,
-Chase
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/25806a47/attachment.html>

From rratliff at cisco.com Wed Jan 16 12:27:42 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 16 Jan 2013 12:27:42 -0500
Subject: [cisco-voip] XML service not working
In-Reply-To: <CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
Message-ID: <A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>

You've got HTTPS enabled so the phone is going to try that. Does your CUCM have
the certs for that site imported so TVS can authenticate the cert the web server is
going to pass down to the phone?

-Ryan

On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:

sorry just confirmed, it does work from the web b.


http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
which means there is no issue with the firewall or DNS

On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:


not a firewall guy, but just wondering if i can access their main website
http://www.andtek.com/communications-products-freexml.html
and also i have checked nothing comes up when I go to the URL
http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from web browers too
(proxy disabled)

On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:


Firewall isn't blocking anything is it?

Sent from my iPad

On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:

> Folks,
>
> I have added some XML services on the node but the phone goes into Requesting
when I hit the service in the phone.
>
>
>
> any ideas!!
>
> Thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

--
@bbas..

--
@bbas..
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/1abb5083/attachment.html>

From dane.newman at gmail.com Wed Jan 16 12:35:13 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Wed, 16 Jan 2013 12:35:13 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAL-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
<36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
Message-ID: <CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>

All

Thank you for the infromation you are providing me on this thread. It is a
great learning exp for me.

I just got off the phone with the ITSP and they confirmed the MOH was
coming from them. They believe if I am typing this correctly they
(ITSP) claim when I press the hold button I am sending an invite message
and that is resulting in the MOH being played by them.

I assumed when I pressed the hold key on an external call CUCM would
continue to send the uninterupted audio stream with the MOH mixed in?

I have reset the trunk and rebooted cucm also...

Thanks again for the assistance and advice it's much appericated

Dane

On Wed, Jan 16, 2013 at 12:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> Having the MOH servers registered is step 1 of about 10 that have to
> happen for MOH to be allocated for the call.
> In the SIP signaling you sent there was no possibility you heard MOH from
> CUCM because the media stream never went back to active after the hold.
> Can your Asterix play MOH?
>
> You need to look at ccm traces to debug this further. If you can't figure
> it out, then it's time to call TAC.
>
> You should also take a look at your active call before it's getting put on
> hold. You've got MTP Required set on the SIP trunk, but if an MTP was
> really getting allocated I don't believe we'd ever set the media inactive
> to the trunk, we'd be telling the MTP about media changes and the trunk
> would just see one media stream to the MTP for the entire call. At the
> same time if we tried to allocate an MTP but failed, that usually ends up
> disabling supplementary services for the call, which means you never would
> have been allowed to hold in the first place. It's certainly possible
> that has changed for SIP EO MTPs but for now what is in that signaling
> doesn't jive with what you've sent in your config and description of
> events.
>
> Have you tried resetting the SIP trunk in CUCM yet?
>
> -Ryan
>
> On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com> wrote:
>
> Yes as per the screen shot the MOH servers are registered. How do In find
> the audio bit rate? its just the default moh file I didnt change any
> settings
>
> On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>
>> So have you looked in your media resources under music on hold server
>> configurations to make sure it's registered to the right UCM? Also what
>> audio bit rate is your MOH file?
>>
>> Sent from my iPad
>>
>> On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:
>>
>> I'm not sure at this point, I'll let some of the CUCM experts comment.
>> It's possible during the hold conversation CUCM always sends delayed offer,
>> but I don't have some good traces in front of me to confirm.
>>
>> You can check the original invite CUCM sends to see if there's SDP in
>> that, and it would confirm the MTP is being allocated. If it's sending the
>> INVITE without SDP, your MRG/MRGL or resources are misconfigured or in use.
>>
>> -nick
>>
>>
>> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com>wrote:
>>
>>> Nick
>>>
>>> Thanks for the assistance.
>>>
>>> This is the first time I am setting up a direct sip connection from cucm
>>> to cube. I am used to making it an h323 connection. Attached are screen
>>> shots of my trunk setup. MTP is checked off I believe already. Is there
>>> a best way to go about troubleshooting cucm to figure out why its not
>>> setting the stream back to active?
>>>
>>> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>>
>>>> It looks like CUCM isn't setting the stream back to active after
>>>> putting it on hold. It sends the re-invite, and the 200 OK from the ITSP
>>>> has the SDP continued with a=inactive.
>>>>
>>>> I don't have some good traces in front of me, but somewhere it needs to
>>>> take that off. I don't think Asterisks is acting incorrectly by responding
>>>> to a delayed offer INVITE that was previously a=inactive with a=inactive.
>>>>
>>>> What's also odd is that CUCM is sending the exact same INVITE after the
>>>> first one completes, for both the hold and the resume. The CSeq isn't
>>>> increasing, which I would expect it to.
>>>>
>>>> If you were to check 'MTP' required it may work around the problem, but
>>>> I don't consider inserting MTP's to be a best practice.
>>>>
>>>> -nick
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at gmail.com
>>>> > wrote:
>>>>
>>>>> Bind your media and source to your outbound interface on your voice
>>>>> service voip.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Below is a show run from the router
>>>>>
>>>>>
>>>>> [OK]
>>>>> Cisco3825#sh run
>>>>> Building configuration...
>>>>>
>>>>> Current configuration : 10183 bytes
>>>>> !
>>>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>>>>> version 15.1
>>>>> service timestamps debug datetime msec
>>>>> service timestamps log datetime msec
>>>>> no service password-encryption
>>>>> !
>>>>> hostname Cisco3825
>>>>> !
>>>>> boot-start-marker
>>>>> boot-end-marker
>>>>> !
>>>>> !
>>>>> !
>>>>> aaa new-model
>>>>> !
>>>>> !
>>>>> aaa authentication login default local
>>>>> aaa authentication login vpnauth local
>>>>> aaa authorization exec default local
>>>>> aaa authorization network default local
>>>>> aaa authorization network vpnauth local
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> aaa session-id common
>>>>> !
>>>>> no network-clock-participate wic 0
>>>>> !
>>>>> dot11 syslog
>>>>> ip source-route
>>>>> !
>>>>> ip cef
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> ip domain name datasc.local
>>>>> ip inspect udp idle-time 1800
>>>>> no ipv6 cef
>>>>> !
>>>>> multilink bundle-name authenticated
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> voice-card 0
>>>>> dsp services dspfarm
>>>>> !
>>>>> !
>>>>> !
>>>>> voice service voip
>>>>> ip address trusted list
>>>>> ipv4 64.154.41.150 255.255.255.255
>>>>> allow-connections sip to sip
>>>>> fax protocol pass-through g711ulaw
>>>>> sip
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> voice translation-rule 1
>>>>> rule 1 /6784604564/ /200/
>>>>> rule 2 /6784563290/ /100/
>>>>> rule 3 /6784563291/ /101/
>>>>> rule 4 /6784563292/ /102/
>>>>> rule 5 /6784563293/ /103/
>>>>> rule 6 /6784563294/ /104/
>>>>> rule 7 /6784563295/ /105/
>>>>> rule 8 /6784563296/ /106/
>>>>> rule 9 /6784563297/ /107/
>>>>> rule 10 /6784563298/ /108/
>>>>> rule 11 /6784563299/ /109/
>>>>> rule 12 /6784604565/ /125/
>>>>> !
>>>>> !
>>>>> voice translation-profile incomingdid
>>>>> translate called 1
>>>>> !
>>>>> !
>>>>> crypto pki token default removal timeout 0
>>>>> !
>>>>> crypto pki trustpoint selfsigned
>>>>> enrollment selfsigned
>>>>> subject-name CN=connect.datasc.com
>>>>> revocation-check crl
>>>>> !
>>>>> !
>>>>> crypto pki certificate chain selfsigned
>>>>> certificate self-signed 02
>>>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101
>>>>> 05050030
>>>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63
>>>>> 6F6D3125
>>>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174
>>>>> 6173632E
>>>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031
>>>>> 30313030
>>>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461
>>>>> 74617363
>>>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338
>>>>> 32352E64
>>>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105
>>>>> 0003818D
>>>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2
>>>>> 7729B93E
>>>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0
>>>>> 9A190598
>>>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4
>>>>> FABF9CA9
>>>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC
>>>>> 4EDD1712
>>>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04
>>>>> 05300301
>>>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5
>>>>> 8A571236
>>>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A
>>>>> 571236A1
>>>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8
>>>>> 8B742D4F
>>>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1
>>>>> B22BBB20
>>>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3
>>>>> EF724BD9
>>>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3
>>>>> 12E45933
>>>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>>>> quit
>>>>> !
>>>>> !
>>>>> license udi pid CISCO3825 sn FTX1237A1T0
>>>>> username xxxxxxx privilege 15 secret xxxxxx
>>>>> !
>>>>> redundancy
>>>>> !
>>>>> !
>>>>> controller T1 0/0/0
>>>>> !
>>>>> controller T1 0/0/1
>>>>> !
>>>>> ip ssh version 2
>>>>> !
>>>>> !
>>>>> crypto isakmp policy 10
>>>>> encr aes
>>>>> authentication pre-share
>>>>> group 2
>>>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>>>> crypto isakmp fragmentation
>>>>> !
>>>>> crypto isakmp client configuration group datasc
>>>>> key Recoil90
>>>>> dns 4.2.2.2 4.2.2.1
>>>>> domain datasc.local
>>>>> pool vpnpool
>>>>> save-password
>>>>> !
>>>>> crypto isakmp client configuration group datascsplit
>>>>> key Recoil90
>>>>> dns 4.2.2.2 4.2.2.1
>>>>> domain datasc.local
>>>>> pool vpnpool
>>>>> acl 101
>>>>> save-password
>>>>> crypto isakmp profile datasc
>>>>> match identity group datasc
>>>>> client authentication list vpnauth
>>>>> isakmp authorization list vpnauth
>>>>> client configuration address respond
>>>>> virtual-template 1
>>>>> crypto isakmp profile datascsplit
>>>>> match identity group datascsplit
>>>>> client authentication list vpnauth
>>>>> isakmp authorization list vpnauth
>>>>> client configuration address respond
>>>>> virtual-template 2
>>>>> !
>>>>> !
>>>>> crypto ipsec transform-set transformset esp-aes
>>>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>>>> !
>>>>> crypto ipsec profile VTI
>>>>> set transform-set ezvpntransform
>>>>> set isakmp-profile datasc
>>>>> !
>>>>> crypto ipsec profile VTI2
>>>>> set transform-set ezvpntransform
>>>>> set isakmp-profile datascsplit
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> interface Loopback1
>>>>> ip address 10.1.150.1 255.255.255.0
>>>>> ip nat inside
>>>>> ip virtual-reassembly in
>>>>> !
>>>>> interface GigabitEthernet0/0
>>>>> ip address dhcp
>>>>> no ip redirects
>>>>> no ip unreachables
>>>>> no ip proxy-arp
>>>>> ip nat outside
>>>>> ip virtual-reassembly in
>>>>> duplex auto
>>>>> speed auto
>>>>> media-type rj45
>>>>> hold-queue 240000 in
>>>>> !
>>>>> interface GigabitEthernet0/1
>>>>> ip address 10.1.200.1 255.255.255.252
>>>>> ip nat inside
>>>>> ip virtual-reassembly in
>>>>> duplex auto
>>>>> speed auto
>>>>> media-type rj45
>>>>> !
>>>>> interface Virtual-Template1 type tunnel
>>>>> ip unnumbered GigabitEthernet0/0
>>>>> ip nat inside
>>>>> ip virtual-reassembly in
>>>>> tunnel source GigabitEthernet0/0
>>>>> tunnel mode ipsec ipv4
>>>>> tunnel protection ipsec profile VTI
>>>>> !
>>>>> interface Virtual-Template2 type tunnel
>>>>> ip unnumbered GigabitEthernet0/0
>>>>> ip nat inside
>>>>> ip virtual-reassembly in
>>>>> tunnel source GigabitEthernet0/0
>>>>> tunnel mode ipsec ipv4
>>>>> tunnel protection ipsec profile VTI2
>>>>> !
>>>>> interface Virtual-Template3
>>>>> ip unnumbered GigabitEthernet0/0
>>>>> ip nat outside
>>>>> ip virtual-reassembly in
>>>>> ip policy route-map anyconnecthop
>>>>> !
>>>>> !
>>>>> router eigrp 1
>>>>> maximum-paths 1
>>>>> network 10.0.0.0
>>>>> redistribute static
>>>>> !
>>>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>>>> ip forward-protocol nd
>>>>> ip http server
>>>>> ip http secure-server
>>>>> !
>>>>> !
>>>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>>>> overload
>>>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>>>> GigabitEthernet0/0 80
>>>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>>>> GigabitEthernet0/0 5001
>>>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>>>> GigabitEthernet0/0 5001
>>>>> !
>>>>> ip access-list extended NATNETWORKS
>>>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>> ip access-list extended anyconnecthop
>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>> !
>>>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> route-map anyconnecthop permit 10
>>>>> match ip address anyconnecthop
>>>>> set ip next-hop 10.1.150.2
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> control-plane
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> mgcp profile default
>>>>> !
>>>>> !
>>>>> dial-peer voice 100 voip
>>>>> description Publisher
>>>>> preference 1
>>>>> destination-pattern 1..
>>>>> session protocol sipv2
>>>>> session target ipv4:10.1.80.10
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 101 voip
>>>>> description Subscriber
>>>>> preference 2
>>>>> destination-pattern 1..
>>>>> session target ipv4:10.1.80.11
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 200 voip
>>>>> description Publisher
>>>>> preference 1
>>>>> destination-pattern 2..
>>>>> progress_ind setup enable 3
>>>>> progress_ind progress enable 8
>>>>> session protocol sipv2
>>>>> session target ipv4:10.1.80.10
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 300 voip
>>>>> description incoming Calldid
>>>>> translation-profile incoming incomingdid
>>>>> preference 1
>>>>> session protocol sipv2
>>>>> session target sip-server
>>>>> incoming called-number 678456329.
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 301 voip
>>>>> description incoming Calldid
>>>>> translation-profile incoming incomingdid
>>>>> preference 1
>>>>> session protocol sipv2
>>>>> session target sip-server
>>>>> incoming called-number 6784604565
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 302 voip
>>>>> description incoming Calldid
>>>>> translation-profile incoming incomingdid
>>>>> preference 1
>>>>> session protocol sipv2
>>>>> session target sip-server
>>>>> incoming called-number 6784604564
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 201 voip
>>>>> description Publisher
>>>>> preference 2
>>>>> destination-pattern 2..
>>>>> progress_ind setup enable 3
>>>>> progress_ind progress enable 8
>>>>> session protocol sipv2
>>>>> session target ipv4:10.1.80.11
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> dial-peer voice 500 voip
>>>>> description outgoing
>>>>> preference 1
>>>>> destination-pattern .T
>>>>> session protocol sipv2
>>>>> session target dns:sip.talkinip.net
>>>>> dtmf-relay rtp-nte
>>>>> codec g711ulaw
>>>>> !
>>>>> !
>>>>> sip-ua
>>>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>>>> sipconnect.ipcomms.net
>>>>> authentication username xxxxxx password 7 xxxxxxx
>>>>> authentication username xxxxx password 7 xxxxxxx realm
>>>>> sipconnect.ipcomms.net
>>>>> set pstn-cause 3 sip-status 486
>>>>> set pstn-cause 34 sip-status 486
>>>>> set pstn-cause 47 sip-status 486
>>>>> registrar dns:sipconnect.ipcomms.net expires 60
>>>>> sip-server dns:sipconnect.ipcomms.net:5060
>>>>> !
>>>>> !
>>>>> !
>>>>> gatekeeper
>>>>> shutdown
>>>>> !
>>>>> !
>>>>> call-manager-fallback
>>>>> max-conferences 8 gain -6
>>>>> transfer-system full-consult
>>>>> ip source-address 10.1.200.1 port 2000
>>>>> max-ephones 20
>>>>> max-dn 40
>>>>> !
>>>>> !
>>>>> !
>>>>> line con 0
>>>>> line aux 0
>>>>> line vty 0 4
>>>>> privilege level 15
>>>>> transport input ssh
>>>>> line vty 5 15
>>>>> privilege level 15
>>>>> transport input ssh
>>>>> !
>>>>> scheduler allocate 20000 1000
>>>>> !
>>>>> webvpn gateway gateway_1
>>>>> ip interface GigabitEthernet0/0 port 443
>>>>> ssl trustpoint selfsigned
>>>>> inservice
>>>>> !
>>>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>>>> sequence 1
>>>>> !
>>>>> webvpn context datasc
>>>>> title "DataSC VPN"
>>>>> secondary-color white
>>>>> title-color #CCCC66
>>>>> text-color black
>>>>> ssl authenticate verify all
>>>>> !
>>>>> url-list "Servers"
>>>>> heading "Server"
>>>>> !
>>>>> !
>>>>> policy group datasc
>>>>> url-list "Servers"
>>>>> functions svc-enabled
>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>> svc keep-client-installed
>>>>> svc dns-server primary 4.2.2.2
>>>>> svc dtls
>>>>> virtual-template 3
>>>>> default-group-policy datasc
>>>>> aaa authentication list vpnauth
>>>>> gateway gateway_1 domain datasc
>>>>> inservice
>>>>> !
>>>>> !
>>>>> webvpn context datascsplit
>>>>> title "DataSC VPN Split"
>>>>> secondary-color white
>>>>> title-color #CCCC66
>>>>> text-color black
>>>>> ssl authenticate verify all
>>>>> !
>>>>> url-list "Servers"
>>>>> heading "Server"
>>>>> !
>>>>> !
>>>>> policy group datascsplit
>>>>> url-list "Servers"
>>>>> functions svc-enabled
>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>> svc split include acl 50
>>>>> svc dns-server primary 4.2.2.2
>>>>> svc dtls
>>>>> default-group-policy datascsplit
>>>>> aaa authentication list vpnauth
>>>>> gateway gateway_1 domain datascsplit
>>>>> inservice
>>>>> !
>>>>> end
>>>>> Cisco3825#
>>>>>
>>>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <
>>>>> kennethwhayes at gmail.com> wrote:
>>>>>
>>>>>> What do your media resources look like?
>>>>>>
>>>>>>
>>>>>> Also can you show me a copy of your voice service voip config?
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks Ryan
>>>>>>
>>>>>> I see I am always getting a 200 ok message after my invites from the
>>>>>> debug
>>>>>>
>>>>>> *Putting a call on HOLD*
>>>>>>
>>>>>>
>>>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY
>>>>>>
>>>>>> CSeq: 102 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>
>>>>>> Supported: Geolocation
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>
>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>
>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 240
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 0.0.0.0
>>>>>>
>>>>>> b=TIAS:64000
>>>>>>
>>>>>> b=AS:64
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-15
>>>>>>
>>>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>
>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Timestamp: 1358281168
>>>>>>
>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 289
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-15
>>>>>>
>>>>>> a=rtpmap:19 CN/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 102 INVITE
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 239
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>>>
>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> c=IN IP4 64.154.41.150
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 13014 RTP/AVP 0 101
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 102 INVITE
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>> >;party=called;screen=no;privacy=off
>>>>>>
>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>
>>>>>> Supported: replaces
>>>>>>
>>>>>> Supported: sdp-anat
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Supported: timer
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 253
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19514 RTP/AVP 0 101
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 103 ACK
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 102 ACK
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>
>>>>>> Supported: Geolocation
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>
>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>
>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>
>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Timestamp: 1358281168
>>>>>>
>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 333
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>>>
>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> c=IN IP4 64.154.41.150
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>
>>>>>> a=rtpmap:3 GSM/8000
>>>>>>
>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:18 G729/8000
>>>>>>
>>>>>> a=fmtp:18 annexb=no
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 103 INVITE
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>> >;party=called;screen=no;privacy=off
>>>>>>
>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>
>>>>>> Supported: replaces
>>>>>>
>>>>>> Supported: sdp-anat
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Supported: timer
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 277
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=rtpmap:19 CN/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 103 ACK
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 209
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 0.0.0.0
>>>>>>
>>>>>> b=TIAS:64000
>>>>>>
>>>>>> b=AS:64
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 21476 RTP/AVP 0
>>>>>>
>>>>>> a=X-cisco-media:nomedia
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 104 ACK
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 251
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 0.0.0.0
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>
>>>>>> c=IN IP4 0.0.0.0
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>>
>>>>>> *Unholding the call the MOH continues on the previously held caller
>>>>>> while the user hears nothing*
>>>>>>
>>>>>> **
>>>>>>
>>>>>>
>>>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>
>>>>>> Supported: Geolocation
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>
>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>
>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>> ;transport=tcp>;video;audio;video
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>
>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Timestamp: 1358281175
>>>>>>
>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 333
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>
>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> c=IN IP4 64.154.41.150
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>
>>>>>> a=rtpmap:3 GSM/8000
>>>>>>
>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:18 G729/8000
>>>>>>
>>>>>> a=fmtp:18 annexb=no
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>> >;party=called;screen=no;privacy=off
>>>>>>
>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>
>>>>>> Supported: replaces
>>>>>>
>>>>>> Supported: sdp-anat
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Supported: timer
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 277
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=rtpmap:19 CN/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 104 ACK
>>>>>>
>>>>>> Allow-Events: presence, kpml
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 243
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.10.18
>>>>>>
>>>>>> b=TIAS:64000
>>>>>>
>>>>>> b=AS:64
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-15
>>>>>>
>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 105 ACK
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 265
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>>
>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: presence
>>>>>>
>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>
>>>>>> Supported: Geolocation
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>
>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>
>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>> ;transport=tcp>;video;audio;video
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>
>>>>>> Min-SE: 1800
>>>>>>
>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>
>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> Timestamp: 1358281175
>>>>>>
>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>
>>>>>> Expires: 180
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 100 Trying
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Length: 0
>>>>>>
>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> CSeq: 105 INVITE
>>>>>>
>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>> INFO
>>>>>>
>>>>>> Supported: replaces, timer
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 333
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>
>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>
>>>>>> c=IN IP4 64.154.41.150
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>
>>>>>> a=rtpmap:3 GSM/8000
>>>>>>
>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:18 G729/8000
>>>>>>
>>>>>> a=fmtp:18 annexb=no
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> SIP/2.0 200 OK
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> CSeq: 104 INVITE
>>>>>>
>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>> >;party=called;screen=no;privacy=off
>>>>>>
>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>
>>>>>> Supported: replaces
>>>>>>
>>>>>> Supported: sdp-anat
>>>>>>
>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>
>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>
>>>>>> Require: timer
>>>>>>
>>>>>> Supported: timer
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 277
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>
>>>>>> c=IN IP4 10.1.200.1
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=rtpmap:19 CN/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Received:
>>>>>>
>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>
>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>
>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 104 ACK
>>>>>>
>>>>>> Allow-Events: presence, kpml
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 243
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 10.1.10.18
>>>>>>
>>>>>> b=TIAS:64000
>>>>>>
>>>>>> b=AS:64
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-15
>>>>>>
>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>
>>>>>> Sent:
>>>>>>
>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>
>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>
>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>> >;tag=2E6BC0B0-2268
>>>>>>
>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>
>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>
>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>
>>>>>> Max-Forwards: 70
>>>>>>
>>>>>> CSeq: 105 ACK
>>>>>>
>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>> ",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>
>>>>>> Allow-Events: telephone-event
>>>>>>
>>>>>> Content-Type: application/sdp
>>>>>>
>>>>>> Content-Length: 265
>>>>>>
>>>>>> v=0
>>>>>>
>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>
>>>>>> s=SIP Call
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> t=0 0
>>>>>>
>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>
>>>>>> c=IN IP4 98.192.104.214
>>>>>>
>>>>>> a=inactive
>>>>>>
>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>
>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>
>>>>>> a=fmtp:101 0-16
>>>>>>
>>>>>> a=ptime:20
>>>>>>
>>>>>> Cisco3825#
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>
>>>>>>> ccsip message is what I'd go with just to see the signaling with no
>>>>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>>>>> to the signals you may need to expand from there.
>>>>>>>
>>>>>>> -Ryan
>>>>>>>
>>>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Ryan
>>>>>>>
>>>>>>> What is the proper debug to use to caputre the useful information?
>>>>>>>
>>>>>>> Dane
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>
>>>>>>>> Without sip messages I can't get any clues from that.
>>>>>>>>
>>>>>>>> -Ryan
>>>>>>>>
>>>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Thanks Ryan for the input
>>>>>>>>
>>>>>>>>
>>>>>>>> *On the call when I hold the call the following debug pops out....*
>>>>>>>>
>>>>>>>>
>>>>>>>> *Jan 15 17:56:05.246:
>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>> passthru hdrs to
>>>>>>>> container
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance
>>>>>>>> 1 not found.
>>>>>>>> *Jan 15 17:56:05.274:
>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>> passthru headers to
>>>>>>>> container
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>> 1 not found.
>>>>>>>> *Jan 15 17:56:05.286:
>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>> passthru hdrs to
>>>>>>>> container
>>>>>>>> *Jan 15 17:56:05.302:
>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>> passthru headers to
>>>>>>>> container
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>> 1 not found.
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> *Jan 15 17:56:05.322:
>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>>>> params for midcall INVITE
>>>>>>>>
>>>>>>>> *After I try to unhold the call the following debug comes out....*
>>>>>>>> **
>>>>>>>>
>>>>>>>> *Jan 15 17:56:18.874:
>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>> passthru hdrs to
>>>>>>>> container
>>>>>>>> *Jan 15 17:56:18.894:
>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>> passthru headers to
>>>>>>>> container
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>> 1 not found.
>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>> *Jan 15 17:56:18.906:
>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify QoS
>>>>>>>> params for midcall INVITE
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>
>>>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>>>
>>>>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>>>
>>>>>>>>> -Ryan
>>>>>>>>>
>>>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> *Hello Kenneth*
>>>>>>>>> **
>>>>>>>>> *I have restarted both CUCM servers so this should have restarted
>>>>>>>>> the services when the utils system restart happened*
>>>>>>>>> **
>>>>>>>>>
>>>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>>>> **
>>>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>>>> **
>>>>>>>>> *I connected a call calling from an external number to a DiD
>>>>>>>>> inside of my system. Once the call was connected I put the call on hold
>>>>>>>>> and the following debug came out..the music on hold played for the
external
>>>>>>>>> caller*
>>>>>>>>>
>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1046)
>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1046)
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=3996)
>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=3996)
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *I then after that took off the hold and the following debug came
>>>>>>>>> out. The call on the PSDN side still played the hold music while there
was
>>>>>>>>> no voice on the deskphone side.*
>>>>>>>>>
>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1046)
>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1046)
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=1516)
>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>> Source Call Id=12742,
>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=3996)
>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>> Source Call Id=12741,
>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>> Vad=ON(0x2),
>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>> Start=3996)
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> My ITSP will only support 711ulaw for me currently I believe.
>>>>>>>>>> They hard coded it with me when I was initially setting it up.
>>>>>>>>>>
>>>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>>>> identifying if it is?
>>>>>>>>>>
>>>>>>>>>> Dane
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the Reply
>>>>>>>>>>> Oddly enough we are.
>>>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>>>
>>>>>>>>>>> Internally when I user puts another user on hold everything
>>>>>>>>>>> works. No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>>>> When I hit resume on the deskphone the MOH still played to the external
>>>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <
>>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Do you get similar behavior if you just hold and resume the
>>>>>>>>>>>> call outside SNR features?
>>>>>>>>>>>>
>>>>>>>>>>>> -Ryan
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>>>
>>>>>>>>>>>> Password:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>
>>>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>>>
>>>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>>>
>>>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>>>
>>>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>>>> (fc1)
>>>>>>>>>>>>
>>>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>>>
>>>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>>>
>>>>>>>>>>>> System image file is
>>>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>>>>> United
>>>>>>>>>>>> States and local country laws governing import, export,
>>>>>>>>>>>> transfer and
>>>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>>>
>>>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>>>> encryption.
>>>>>>>>>>>> Importers, exporters, distributors and users are responsible
>>>>>>>>>>>> for
>>>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>>>> product you
>>>>>>>>>>>> agree to comply with applicable laws and regulations. If you
>>>>>>>>>>>> are unable
>>>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>>>> immediately.
>>>>>>>>>>>>
>>>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products
>>>>>>>>>>>> may be found at:
>>>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>>>
>>>>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>>>>> email to
>>>>>>>>>>>> export at cisco.com.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>>>>>>>>>
>>>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>>>
>>>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>>>
>>>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>>>
>>>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>>>
>>>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>>>
>>>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>>>
>>>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> License Info:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> License UDI:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> Device# PID SN
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello
>>>>>>>>>>>>
>>>>>>>>>>>> I have an issue when users are connected to a call and hit the
>>>>>>>>>>>> mobility soft key button on 9971 phones when a call is active, the
phone
>>>>>>>>>>>> system rings on the mobile number configured in the system. When they
pick
>>>>>>>>>>>> up the the mobile number it just plays what sounds like hold music on
both
>>>>>>>>>>>> ends of the call (I believe this music is coming from cucm but I
haven't
>>>>>>>>>>>> heard it before) instead of providing 2 way voice.
>>>>>>>>>>>>
>>>>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to
take
>>>>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing but
the
>>>>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>>>
>>>>>>>>>>>> My topology is as follows..
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>>>>>>
>>>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>
> <moh.jpg>_______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/8f944ccc/attachment.html>

From rratliff at cisco.com Wed Jan 16 12:59:07 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 16 Jan 2013 12:59:07 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid> <CA!
L-DCK3GrQOW9C-U-eTFdJE-5AnR_uFYX_pmejagQfH3oY2zfw@mail.gmail.com>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
<36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
<CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>
Message-ID: <DD3CCA65-34A2-4EEA-ADA4-380F5CE35DE8@cisco.com>

What they are doing is interpreting us sending them an Invite with a=inactive in
the SDP as the Cisco phone putting them on hold. That is a valid assumption.
What is incorrect (IMO) is them assuming that they need to generate MOH. CUCM is
the one initiating the hold, it will be the one to play MOH or not, based upon the
way you configure it. When they respond to our inactive SDP with one of their
own, CUCM sees that as them putting us on hold. The end result you see is that in
order to get the call off of hold both sides need to resume it, which isn't
happening.

I still think you need to look at an active call (no hold) on your CUBE to see
where it's sending media to on the internal side. That IP address is going to be
an MTP (CUCM server, hardware resource) or an IP phone. If it's directly to a
phone you may as well remove "MTP Required" on the trunk because you're not
actually allocating an MTP.

-Ryan

On Jan 16, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:

All

Thank you for the infromation you are providing me on this thread. It is a great
learning exp for me.

I just got off the phone with the ITSP and they confirmed the MOH was coming from
them. They believe if I am typing this correctly they (ITSP) claim when I press
the hold button I am sending an invite message and that is resulting in the MOH
being played by them.

I assumed when I pressed the hold key on an external call CUCM would continue to
send the uninterupted audio stream with the MOH mixed in?

I have reset the trunk and rebooted cucm also...

Thanks again for the assistance and advice it's much appericated

Dane

On Wed, Jan 16, 2013 at 12:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Having the MOH servers registered is step 1 of about 10 that have to happen for MOH
to be allocated for the call.
In the SIP signaling you sent there was no possibility you heard MOH from CUCM
because the media stream never went back to active after the hold. Can your
Asterix play MOH?

You need to look at ccm traces to debug this further. If you can't figure it out,
then it's time to call TAC.

You should also take a look at your active call before it's getting put on hold.
You've got MTP Required set on the SIP trunk, but if an MTP was really getting
allocated I don't believe we'd ever set the media inactive to the trunk, we'd be
telling the MTP about media changes and the trunk would just see one media stream
to the MTP for the entire call. At the same time if we tried to allocate an MTP
but failed, that usually ends up disabling supplementary services for the call,
which means you never would have been allowed to hold in the first place. It's
certainly possible that has changed for SIP EO MTPs but for now what is in that
signaling doesn't jive with what you've sent in your config and description of
events.

Have you tried resetting the SIP trunk in CUCM yet?

-Ryan

On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com> wrote:

Yes as per the screen shot the MOH servers are registered. How do In find the
audio bit rate? its just the default moh file I didnt change any settings

On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
So have you looked in your media resources under music on hold server
configurations to make sure it's registered to the right UCM? Also what audio bit
rate is your MOH file?

Sent from my iPad

On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:

> I'm not sure at this point, I'll let some of the CUCM experts comment. It's
possible during the hold conversation CUCM always sends delayed offer, but I don't
have some good traces in front of me to confirm.
>
> You can check the original invite CUCM sends to see if there's SDP in that, and
it would confirm the MTP is being allocated. If it's sending the INVITE without
SDP, your MRG/MRGL or resources are misconfigured or in use.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
> Nick
>
> Thanks for the assistance.
>
> This is the first time I am setting up a direct sip connection from cucm to cube.
I am used to making it an h323 connection. Attached are screen shots of my trunk
setup. MTP is checked off I believe already. Is there a best way to go about
troubleshooting cucm to figure out why its not setting the stream back to active?
>
> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com> wrote:
> It looks like CUCM isn't setting the stream back to active after putting it on
hold. It sends the re-invite, and the 200 OK from the ITSP has the SDP continued
with a=inactive.
>
> I don't have some good traces in front of me, but somewhere it needs to take that
off. I don't think Asterisks is acting incorrectly by responding to a delayed offer
INVITE that was previously a=inactive with a=inactive.
>
> What's also odd is that CUCM is sending the exact same INVITE after the first one
completes, for both the hold and the resume. The CSeq isn't increasing, which I
would expect it to.
>
> If you were to check 'MTP' required it may work around the problem, but I don't
consider inserting MTP's to be a best practice.
>
> -nick
>
>
> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
> Bind your media and source to your outbound interface on your voice service voip.
>
> Sent from my iPhone
>
> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
>> Below is a show run from the router
>>
>>
>> [OK]
>> Cisco3825#sh run
>> Building configuration...
>>
>> Current configuration : 10183 bytes
>> !
>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>> version 15.1
>> service timestamps debug datetime msec
>> service timestamps log datetime msec
>> no service password-encryption
>> !
>> hostname Cisco3825
>> !
>> boot-start-marker
>> boot-end-marker
>> !
>> !
>> !
>> aaa new-model
>> !
>> !
>> aaa authentication login default local
>> aaa authentication login vpnauth local
>> aaa authorization exec default local
>> aaa authorization network default local
>> aaa authorization network vpnauth local
>> !
>> !
>> !
>> !
>> !
>> aaa session-id common
>> !
>> no network-clock-participate wic 0
>> !
>> dot11 syslog
>> ip source-route
>> !
>> ip cef
>> !
>> !
>> !
>> !
>> ip domain name datasc.local
>> ip inspect udp idle-time 1800
>> no ipv6 cef
>> !
>> multilink bundle-name authenticated
>> !
>> !
>> !
>> !
>> !
>> voice-card 0
>> dsp services dspfarm
>> !
>> !
>> !
>> voice service voip
>> ip address trusted list
>> ipv4 64.154.41.150 255.255.255.255
>> allow-connections sip to sip
>> fax protocol pass-through g711ulaw
>> sip
>> !
>> !
>> !
>> !
>> voice translation-rule 1
>> rule 1 /6784604564/ /200/
>> rule 2 /6784563290/ /100/
>> rule 3 /6784563291/ /101/
>> rule 4 /6784563292/ /102/
>> rule 5 /6784563293/ /103/
>> rule 6 /6784563294/ /104/
>> rule 7 /6784563295/ /105/
>> rule 8 /6784563296/ /106/
>> rule 9 /6784563297/ /107/
>> rule 10 /6784563298/ /108/
>> rule 11 /6784563299/ /109/
>> rule 12 /6784604565/ /125/
>> !
>> !
>> voice translation-profile incomingdid
>> translate called 1
>> !
>> !
>> crypto pki token default removal timeout 0
>> !
>> crypto pki trustpoint selfsigned
>> enrollment selfsigned
>> subject-name CN=connect.datasc.com
>> revocation-check crl
>> !
>> !
>> crypto pki certificate chain selfsigned
>> certificate self-signed 02
>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101 05050030
>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63 6F6D3125
>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174 6173632E
>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031 30313030
>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461 74617363
>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338 32352E64
>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105 0003818D
>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2 7729B93E
>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0 9A190598
>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4 FABF9CA9
>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC 4EDD1712
>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04 05300301
>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5 8A571236
>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A 571236A1
>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8 8B742D4F
>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1 B22BBB20
>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3 EF724BD9
>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3 12E45933
>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>> quit
>> !
>> !
>> license udi pid CISCO3825 sn FTX1237A1T0
>> username xxxxxxx privilege 15 secret xxxxxx
>> !
>> redundancy
>> !
>> !
>> controller T1 0/0/0
>> !
>> controller T1 0/0/1
>> !
>> ip ssh version 2
>> !
>> !
>> crypto isakmp policy 10
>> encr aes
>> authentication pre-share
>> group 2
>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>> crypto isakmp fragmentation
>> !
>> crypto isakmp client configuration group datasc
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> save-password
>> !
>> crypto isakmp client configuration group datascsplit
>> key Recoil90
>> dns 4.2.2.2 4.2.2.1
>> domain datasc.local
>> pool vpnpool
>> acl 101
>> save-password
>> crypto isakmp profile datasc
>> match identity group datasc
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 1
>> crypto isakmp profile datascsplit
>> match identity group datascsplit
>> client authentication list vpnauth
>> isakmp authorization list vpnauth
>> client configuration address respond
>> virtual-template 2
>> !
>> !
>> crypto ipsec transform-set transformset esp-aes
>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>> !
>> crypto ipsec profile VTI
>> set transform-set ezvpntransform
>> set isakmp-profile datasc
>> !
>> crypto ipsec profile VTI2
>> set transform-set ezvpntransform
>> set isakmp-profile datascsplit
>> !
>> !
>> !
>> !
>> !
>> !
>> !
>> interface Loopback1
>> ip address 10.1.150.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly in
>> !
>> interface GigabitEthernet0/0
>> ip address dhcp
>> no ip redirects
>> no ip unreachables
>> no ip proxy-arp
>> ip nat outside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> hold-queue 240000 in
>> !
>> interface GigabitEthernet0/1
>> ip address 10.1.200.1 255.255.255.252
>> ip nat inside
>> ip virtual-reassembly in
>> duplex auto
>> speed auto
>> media-type rj45
>> !
>> interface Virtual-Template1 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI
>> !
>> interface Virtual-Template2 type tunnel
>> ip unnumbered GigabitEthernet0/0
>> ip nat inside
>> ip virtual-reassembly in
>> tunnel source GigabitEthernet0/0
>> tunnel mode ipsec ipv4
>> tunnel protection ipsec profile VTI2
>> !
>> interface Virtual-Template3
>> ip unnumbered GigabitEthernet0/0
>> ip nat outside
>> ip virtual-reassembly in
>> ip policy route-map anyconnecthop
>> !
>> !
>> router eigrp 1
>> maximum-paths 1
>> network 10.0.0.0
>> redistribute static
>> !
>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>> ip forward-protocol nd
>> ip http server
>> ip http secure-server
>> !
>> !
>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0 overload
>> ip nat inside source static tcp 10.1.50.150 80 interface GigabitEthernet0/0 80
>> ip nat inside source static tcp 10.1.80.100 5001 interface GigabitEthernet0/0
5001
>> ip nat inside source static udp 10.1.80.100 5001 interface GigabitEthernet0/0
5001
>> !
>> ip access-list extended NATNETWORKS
>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> ip access-list extended anyconnecthop
>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>> permit ip 10.0.0.0 0.255.255.255 any
>> !
>> access-list 50 permit 10.0.0.0 0.255.255.255
>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>> !
>> !
>> !
>> !
>> route-map anyconnecthop permit 10
>> match ip address anyconnecthop
>> set ip next-hop 10.1.150.2
>> !
>> !
>> !
>> !
>> !
>> control-plane
>> !
>> !
>> !
>> !
>> mgcp profile default
>> !
>> !
>> dial-peer voice 100 voip
>> description Publisher
>> preference 1
>> destination-pattern 1..
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 101 voip
>> description Subscriber
>> preference 2
>> destination-pattern 1..
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 200 voip
>> description Publisher
>> preference 1
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.10
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 300 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 678456329.
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 301 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604565
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 302 voip
>> description incoming Calldid
>> translation-profile incoming incomingdid
>> preference 1
>> session protocol sipv2
>> session target sip-server
>> incoming called-number 6784604564
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 201 voip
>> description Publisher
>> preference 2
>> destination-pattern 2..
>> progress_ind setup enable 3
>> progress_ind progress enable 8
>> session protocol sipv2
>> session target ipv4:10.1.80.11
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> dial-peer voice 500 voip
>> description outgoing
>> preference 1
>> destination-pattern .T
>> session protocol sipv2
>> session target dns:sip.talkinip.net
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> !
>> !
>> sip-ua
>> credentials username xxxxxxxx password 7 xxxxxxx realm sipconnect.ipcomms.net
>> authentication username xxxxxx password 7 xxxxxxx
>> authentication username xxxxx password 7 xxxxxxx realm sipconnect.ipcomms.net
>> set pstn-cause 3 sip-status 486
>> set pstn-cause 34 sip-status 486
>> set pstn-cause 47 sip-status 486
>> registrar dns:sipconnect.ipcomms.net expires 60
>> sip-server dns:sipconnect.ipcomms.net:5060
>> !
>> !
>> !
>> gatekeeper
>> shutdown
>> !
>> !
>> call-manager-fallback
>> max-conferences 8 gain -6
>> transfer-system full-consult
>> ip source-address 10.1.200.1 port 2000
>> max-ephones 20
>> max-dn 40
>> !
>> !
>> !
>> line con 0
>> line aux 0
>> line vty 0 4
>> privilege level 15
>> transport input ssh
>> line vty 5 15
>> privilege level 15
>> transport input ssh
>> !
>> scheduler allocate 20000 1000
>> !
>> webvpn gateway gateway_1
>> ip interface GigabitEthernet0/0 port 443
>> ssl trustpoint selfsigned
>> inservice
>> !
>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg sequence 1
>> !
>> webvpn context datasc
>> title "DataSC VPN"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datasc
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc keep-client-installed
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> virtual-template 3
>> default-group-policy datasc
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datasc
>> inservice
>> !
>> !
>> webvpn context datascsplit
>> title "DataSC VPN Split"
>> secondary-color white
>> title-color #CCCC66
>> text-color black
>> ssl authenticate verify all
>> !
>> url-list "Servers"
>> heading "Server"
>> !
>> !
>> policy group datascsplit
>> url-list "Servers"
>> functions svc-enabled
>> svc address-pool "vpnpool" netmask 255.255.255.0
>> svc split include acl 50
>> svc dns-server primary 4.2.2.2
>> svc dtls
>> default-group-policy datascsplit
>> aaa authentication list vpnauth
>> gateway gateway_1 domain datascsplit
>> inservice
>> !
>> end
>> Cisco3825#
>>
>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>> What do your media resources look like?
>>
>>
>> Also can you show me a copy of your voice service voip config?
>>
>> Sent from my iPad
>>
>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>>> Thanks Ryan
>>>
>>> I see I am always getting a 200 ok message after my invites from the debug
>>>
>>> Putting a call on HOLD
>>>
>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 102 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 240
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 289
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 103 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 239
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 102 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 253
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 102 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 103 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281168
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 104 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 103 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 103 ACK
>>>
>>> Allow-Events: presence
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 209
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0
>>>
>>> a=X-cisco-media:nomedia
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 251
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>>
>>> Unholding the call the MOH continues on the previously held caller while the
user hears nothing
>>>
>>>
>>>
>>>
>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>> Cisco3825#
>>>
>>>
>>> Cisco3825#
>>>
>>>
>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Supported: timer,resource-priority,replaces
>>>
>>> Min-SE: 1800
>>>
>>> User-Agent: Cisco-CUCM8.6
>>>
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
>>>
>>> CSeq: 104 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Expires: 180
>>>
>>> Allow-Events: presence
>>>
>>> Supported: X-cisco-srtp-fallback
>>>
>>> Supported: Geolocation
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>
>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at
10.1.80.10>;party=calling;screen=yes;privacy=off
>>>
>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video;audio;video
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>
>>> Min-SE: 1800
>>>
>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>
>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> CSeq: 105 INVITE
>>>
>>> Max-Forwards: 70
>>>
>>> Timestamp: 1358281175
>>>
>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>
>>> Expires: 180
>>>
>>> Allow-Events: telephone-event
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow-Events: telephone-event
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 100 Trying
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Length: 0
>>>
>>> ?
>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/UDP
98.192.104.214:5060;branch=z9hG4bK69232672;received=98.192.104.214
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> CSeq: 105 INVITE
>>>
>>> Server: Asterisk PBX 1.6.2.13
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>
>>> Supported: replaces, timer
>>>
>>> Require: timer
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 333
>>>
>>> v=0
>>>
>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>
>>> s=Asterisk PBX 1.6.2.13
>>>
>>> c=IN IP4 64.154.41.150
>>>
>>> t=0 0
>>>
>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>
>>> a=rtpmap:3 GSM/8000
>>>
>>> a=rtpmap:8 PCMA/8000
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:18 G729/8000
>>>
>>> a=fmtp:18 annexb=no
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> SIP/2.0 200 OK
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> CSeq: 104 INVITE
>>>
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
>>>
>>> Allow-Events: telephone-event
>>>
>>> Remote-Party-ID: <sip:17705439047 at
10.1.200.1>;party=called;screen=no;privacy=off
>>>
>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>
>>> Supported: replaces
>>>
>>> Supported: sdp-anat
>>>
>>> Server: Cisco-SIPGateway/IOS-12.x
>>>
>>> Session-Expires: 1800;refresher=uas
>>>
>>> Require: timer
>>>
>>> Supported: timer
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 277
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> t=0 0
>>>
>>> m=audio 19514 RTP/AVP 0 101 19
>>>
>>> c=IN IP4 10.1.200.1
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=rtpmap:19 CN/8000
>>>
>>> a=ptime:20
>>>
>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Received:
>>>
>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>
>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>
>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10>;tag=7322~d8eefedd-7473-4e00-
a4a0-ce8f65d30766-30500957
>>>
>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>
>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>
>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 104 ACK
>>>
>>> Allow-Events: presence, kpml
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 243
>>>
>>> v=0
>>>
>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 10.1.10.18
>>>
>>> b=TIAS:64000
>>>
>>> b=AS:64
>>>
>>> t=0 0
>>>
>>> m=audio 21476 RTP/AVP 0 101
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=ptime:20
>>>
>>> a=inactive
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-15
>>>
>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>
>>> Sent:
>>>
>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>
>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>
>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net>;tag=2E6BC0B0-
2268
>>>
>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>
>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>
>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>
>>> Max-Forwards: 70
>>>
>>> CSeq: 105 ACK
>>>
>>> Authorization: Digest
username="6784563290",realm="asterisk",uri="sip:17705439047 at
64.154.41.150:5060",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",al
gorithm=MD5
>>>
>>> Allow-Events: telephone-event
>>>
>>> Content-Type: application/sdp
>>>
>>> Content-Length: 265
>>>
>>> v=0
>>>
>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>
>>> s=SIP Call
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> t=0 0
>>>
>>> m=audio 19458 RTP/AVP 0 101
>>>
>>> c=IN IP4 98.192.104.214
>>>
>>> a=inactive
>>>
>>> a=rtpmap:0 PCMU/8000
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> a=fmtp:101 0-16
>>>
>>> a=ptime:20
>>>
>>> Cisco3825#
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> ccsip message is what I'd go with just to see the signaling with no other
stuff. Depending on what that shows and what your gateway is doing to the signals
you may need to expand from there.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Ryan
>>>
>>> What is the proper debug to use to caputre the useful information?
>>>
>>> Dane
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> Without sip messages I can't get any clues from that.
>>>
>>> -Ryan
>>>
>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Thanks Ryan for the input
>>>
>>>
>>> On the call when I hold the call the following debug pops out....
>>>
>>>
>>> *Jan 15 17:56:05.246: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> *Jan 15 17:56:05.274: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> *Jan 15 17:56:05.286: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> *Jan 15 17:56:05.302: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:05.322: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE
>>>
>>> After I try to unhold the call the following debug comes out....
>>>
>>>
>>> *Jan 15 17:56:18.874: //13939/922252E78D73/SIP/Error/ccsip_api_request_offer:
Unable to add passthru hdrs to
>>> container
>>> *Jan 15 17:56:18.894: //13938/922252E78D73/SIP/Error/ccsip_api_response_answer:
Unable to add
>>> passthru headers to container
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance 1 not found.
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Jan 15 17:56:18.906: //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia:
Could not modify QoS params for midcall INVITE
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>> Given you have an ITSP it's most likely the initial hold that's failing, which
is only manifesting when you try to resume it. If you haven't noticed already
this is also very likely causing transfers to fail.
>>>
>>> Take a look at the SIP signaling for a call. I believe the most common cause
to this is the ITSP not handling our transition from active->inactive->sendonly-
>active from hold to MOH to resume. The "Duplex Streaming Enabled" parameter is
there just for this type of problem.
>>>
>>> -Ryan
>>>
>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Hello Kenneth
>>>
>>> I have restarted both CUCM servers so this should have restarted the services
when the utils system restart happened
>>>
>>>
>>> on my router I see I am using g711 from the debug
>>>
>>> I ran a debug voip ccapi inout
>>>
>>> I connected a call calling from an external number to a DiD inside of my
system. Once the call was connected I put the call on hold and the following debug
came out..the music on hold played for the external caller
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>>
>>> I then after that took off the hold and the following debug came out. The call
on the PSDN side still played the hold music while there was no voice on the
deskphone side.
>>>
>>> *Jan 14 23:47:40.779: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.783: //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1046)
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12742
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12741
>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.815: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> *Jan 14 23:47:40.819: //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>> Stop Tone On Digit=FALSE, Tone=Null,
>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=96, Call Id=12742
>>> *Jan 14 23:47:40.819: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.839: //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741, Xmit Function=0x64204BAC
>>> *Jan 14 23:47:40.839: //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=1516)
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=170, Call Id=12741
>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12741, Source Call
Id=12742,
>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>> Destination Interface=0xC05A65AC, Destination Call Id=12742, Source Call
Id=12741,
>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1), Vad=ON(0x2),
>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3996)
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event=171, Call Id=12742
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>> Event Is Sent To Conferenced SPI(s) Directly
>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>> Interface=0xC05A65AC, Call Id=12742
>>> Cisco3825#
>>> Cisco3825#
>>> Cisco3825#
>>>
>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>> Have you also restarted the Cisco IP Media Services?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>>> My ITSP will only support 711ulaw for me currently I believe. They hard coded
it with me when I was initially setting it up.
>>>>
>>>> Do you think this could be a codec issue? How would I go about identifying if
it is?
>>>>
>>>> Dane
>>>>
>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>>> Have you tried different audio codecs?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>
>>>>> Ryan (sorry I forgot to reply to all)
>>>>>
>>>>> Thanks for the Reply
>>>>> Oddly enough we are.
>>>>> This probably has something to do with MOH in general?
>>>>>
>>>>> Internally when I user puts another user on hold everything works. No MOH
plays and they can hold and unhold the call just fine.
>>>>> I tested calling from an external number. Once I put the external caller on
hold the MOH played but I was unable to resume the call. When I hit resume on the
deskphone the MOH still played to the external caller and there was no sound on the
deskphone.
>>>>>
>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>>>> Do you get similar behavior if you just hold and resume the call outside SNR
features?
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>>
>>>>> Using keyboard-interactive authentication.
>>>>> Password:
>>>>>
>>>>> Cisco3825#
>>>>> Cisco3825#sh ver
>>>>> Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9_IVS_LI-M), Version
15.1
>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>
>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)
>>>>>
>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>> System returned to ROM by power-on
>>>>> System image file is "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>> Last reload type: Normal Reload
>>>>>
>>>>>
>>>>> This product contains cryptographic features and is subject to United
>>>>> States and local country laws governing import, export, transfer and
>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>> third-party authority to import, export, distribute or use encryption.
>>>>> Importers, exporters, distributors and users are responsible for
>>>>> compliance with U.S. and local country laws. By using this product you
>>>>> agree to comply with applicable laws and regulations. If you are unable
>>>>> to comply with U.S. and local laws, return this product immediately.
>>>>>
>>>>> A summary of U.S. laws governing Cisco cryptographic products may be found
at:
>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>
>>>>> If you require further assistance please contact us by sending email to
>>>>> export at cisco.com.
>>>>>
>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of memory.
>>>>> Processor board ID FTX1237A1T0
>>>>> 2 Gigabit Ethernet interfaces
>>>>> 2 Channelized T1/PRI ports
>>>>> 1 Virtual Private Network (VPN) Module
>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>> 479K bytes of NVRAM.
>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>
>>>>>
>>>>> License Info:
>>>>>
>>>>> License UDI:
>>>>>
>>>>> -------------------------------------------------
>>>>> Device# PID SN
>>>>>
>>>>> Sent from my mobile device
>>>>>
>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com>
wrote:
>>>>>
>>>>>> What version of code are you running on the CUBE?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I have an issue when users are connected to a call and hit the mobility
soft key button on 9971 phones when a call is active, the phone system rings on the
mobile number configured in the system. When they pick up the the mobile number it
just plays what sounds like hold music on both ends of the call (I believe this
music is coming from cucm but I haven't heard it before) instead of providing 2 way
voice.
>>>>>>>
>>>>>>> In another senario with what I believe is the same issue. If a user picks
up on there cell phone first (using single number reach) opposed to the deskphone
the call is connected with 2 way voice and no issues exist. If the user then hangs
up his cell phone with the intent to take the call on his deskphone the calling
party starts hearing the hold music. Once the user picks up the call on his
deskphone he hears nothing but the calling party is still hearing the hold music.
It is not working as intended where 2 way voice happens once the user hangs up his
mobile phone and picks up on his deskphone 2 way voice should happen.
>>>>>>>
>>>>>>> My topology is as follows..
>>>>>>>
>>>>>>>
>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM -->DESKPHOHE
>>>>>>>
>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using mobile
connect/snr.
>>>>>>>
>>>>>>> Does anyone have any ideas how I can make 2 way voice happen instead of the
hold music when the calls are picked up?
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>

<moh.jpg>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/2346511d/attachment.html>

From jsteinberg at gmail.com Wed Jan 16 13:01:09 2013


From: jsteinberg at gmail.com (Justin Steinberg)
Date: Wed, 16 Jan 2013 13:01:09 -0500
Subject: [cisco-voip] Reporting / Alerting on Device Mobility
Message-ID: <CACCAghb9ttEahsPzAH==xzvvGVW8H84g65TNGxQ1twYkAGTdhg@mail.gmail.com>

Is there a way to see which phones are current roaming according to Device
Mobility ? Second question, is there a way to have CM generate an alert
when a phone registers in a roaming location ?

I didnt see anything in RTMT or perform to cover device mobility.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/537547f6/attachment.html>

From abbaseo at gmail.com Wed Jan 16 13:02:14 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 18:02:14 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
<A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
Message-ID: <CAFdHCp7ZrCWqKT+Sa7dHWLdW_CF9S3_3i26oSjcuLB88nSpUPQ@mail.gmail.com>

how/where we can disable the HTTPS?


On 16 January 2013 17:27, Ryan Ratliff <rratliff at cisco.com> wrote:

> You've got HTTPS enabled so the phone is going to try that. Does your
> CUCM have the certs for that site imported so TVS can authenticate the cert
> the web server is going to pass down to the phone?
>
> -Ryan
>
> On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:
>
> sorry just confirmed, it does work from the web b.
> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
> which means there is no issue with the firewall or DNS
> *
> On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:
>
>> not a firewall guy, but just wondering if i can access their main website
>> http://www.andtek.com/communications-products-freexml.html
>> and also i have checked nothing comes up when I go to the URL
>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from web
>> browers too (proxy disabled)*
>>
>>
>> On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>
>>> Firewall isn't blocking anything is it?
>>>
>>> Sent from my iPad
>>>
>>> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>>
>>> Folks,
>>>
>>> I have added some XML services on the node but the phone goes into
>>> Requesting when I hit the service in the phone.
>>>
>>>
>>>
>>> any ideas!!
>>>
>>> Thanks
>>> --
>>> @bbas..
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> @bbas..
>>
>
>
>
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/f7d29c6e/attachment.html>

From dane.newman at gmail.com Wed Jan 16 13:27:17 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Wed, 16 Jan 2013 13:27:17 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <DD3CCA65-34A2-4EEA-ADA4-380F5CE35DE8@cisco.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
<36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
<CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>
<DD3CCA65-34A2-4EEA-ADA4-380F5CE35DE8@cisco.com>
Message-ID: <CAL-DCK3zTRk7JEpre_=fqtfnvwDxRuJq5Nns3P-eL2tSR29UzQ@mail.gmail.com>

Ryan

Thank you again for responding and sharing your wisdom.

I am unsure if I am doing the test to verify your thoughts correctly but I


debugged the SIP messages once again. I placed a call and picked up the
call with and without the MTP checkbox checked on the SIP trunk in cucm.

I then did a search for the IP address of my IP phone 10.1.10.18.

In both debugs with and without it checked I found my IP phone's IP address


in the debug. I believe this might verify your idea that the MTP is not
working correctly?

*With MTP unchecked on the SIP TRUNk*


*Jan 16 18:33:28.384: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK4e47f806d
From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>;tag=673~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145612
To: <sip:17705439047 at 10.1.200.1>;tag=333141D8-1492
Date: Wed, 16 Jan 2013 18:11:29 GMT
Call-ID: 24e56400-f61ed51-12-a50010a at 10.1.80.10
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 230
v=0
o=CiscoSystemsCCM-SIP 673 1 IN IP4 10.1.80.10
s=SIP Call
c=IN IP4 10.1.10.18
b=TIAS:64000
b=AS:64
t=0 0
m=audio 20116 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

*With MTP checked on the SIP TRUNk*

*Jan 16 18:39:09.732: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:


Received:
ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK60b810f25
From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>;tag=723~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145637
To: <sip:17705439047 at 10.1.200.1>;tag=3336625C-1CBB
Date: Wed, 16 Jan 2013 18:17:05 GMT
Call-ID: ed2aec00-f61eea1-16-a50010a at 10.1.80.10
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 230
v=0
o=CiscoSystemsCCM-SIP 723 2 IN IP4 10.1.80.10
s=SIP Call
c=IN IP4 10.1.10.18
b=TIAS:64000
b=AS:64
t=0 0
m=audio 16452 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
On Wed, Jan 16, 2013 at 12:59 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> What they are doing is interpreting us sending them an Invite with
> a=inactive in the SDP as the Cisco phone putting them on hold. That is a
> valid assumption. What is incorrect (IMO) is them assuming that they need
> to generate MOH. CUCM is the one initiating the hold, it will be the one
> to play MOH or not, based upon the way you configure it. When they
> respond to our inactive SDP with one of their own, CUCM sees that as them
> putting us on hold. The end result you see is that in order to get the
> call off of hold both sides need to resume it, which isn't happening.
>
> I still think you need to look at an active call (no hold) on your CUBE to
> see where it's sending media to on the internal side. That IP address is
> going to be an MTP (CUCM server, hardware resource) or an IP phone. If
> it's directly to a phone you may as well remove "MTP Required" on the trunk
> because you're not actually allocating an MTP.
>
> -Ryan
>
> On Jan 16, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>
> All
>
> Thank you for the infromation you are providing me on this thread. It is
> a great learning exp for me.
>
> I just got off the phone with the ITSP and they confirmed the MOH was
> coming from them. They believe if I am typing this correctly they
> (ITSP) claim when I press the hold button I am sending an invite message
> and that is resulting in the MOH being played by them.
>
> I assumed when I pressed the hold key on an external call CUCM would
> continue to send the uninterupted audio stream with the MOH mixed in?
>
> I have reset the trunk and rebooted cucm also...
>
> Thanks again for the assistance and advice it's much appericated
>
> Dane
>
>
>
> On Wed, Jan 16, 2013 at 12:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Having the MOH servers registered is step 1 of about 10 that have to
>> happen for MOH to be allocated for the call.
>> In the SIP signaling you sent there was no possibility you heard MOH from
>> CUCM because the media stream never went back to active after the hold.
>> Can your Asterix play MOH?
>>
>> You need to look at ccm traces to debug this further. If you can't
>> figure it out, then it's time to call TAC.
>>
>> You should also take a look at your active call before it's getting put
>> on hold. You've got MTP Required set on the SIP trunk, but if an MTP was
>> really getting allocated I don't believe we'd ever set the media inactive
>> to the trunk, we'd be telling the MTP about media changes and the trunk
>> would just see one media stream to the MTP for the entire call. At the
>> same time if we tried to allocate an MTP but failed, that usually ends up
>> disabling supplementary services for the call, which means you never would
>> have been allowed to hold in the first place. It's certainly possible
>> that has changed for SIP EO MTPs but for now what is in that signaling
>> doesn't jive with what you've sent in your config and description of
>> events.
>>
>> Have you tried resetting the SIP trunk in CUCM yet?
>>
>> -Ryan
>>
>> On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> Yes as per the screen shot the MOH servers are registered. How do In
>> find the audio bit rate? its just the default moh file I didnt change any
>> settings
>>
>> On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at
gmail.com>wrote:
>>
>>> So have you looked in your media resources under music on hold server
>>> configurations to make sure it's registered to the right UCM? Also what
>>> audio bit rate is your MOH file?
>>>
>>> Sent from my iPad
>>>
>>> On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com> wrote:
>>>
>>> I'm not sure at this point, I'll let some of the CUCM experts comment.
>>> It's possible during the hold conversation CUCM always sends delayed offer,
>>> but I don't have some good traces in front of me to confirm.
>>>
>>> You can check the original invite CUCM sends to see if there's SDP in
>>> that, and it would confirm the MTP is being allocated. If it's sending the
>>> INVITE without SDP, your MRG/MRGL or resources are misconfigured or in use.
>>>
>>> -nick
>>>
>>>
>>> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com>wrote:
>>>
>>>> Nick
>>>>
>>>> Thanks for the assistance.
>>>>
>>>> This is the first time I am setting up a direct sip connection from
>>>> cucm to cube. I am used to making it an h323 connection. Attached are
>>>> screen shots of my trunk setup. MTP is checked off I believe already.
>>>> Is there a best way to go about troubleshooting cucm to figure out why its
>>>> not setting the stream back to active?
>>>>
>>>> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>>>
>>>>> It looks like CUCM isn't setting the stream back to active after
>>>>> putting it on hold. It sends the re-invite, and the 200 OK from the ITSP
>>>>> has the SDP continued with a=inactive.
>>>>>
>>>>> I don't have some good traces in front of me, but somewhere it needs
>>>>> to take that off. I don't think Asterisks is acting incorrectly by
>>>>> responding to a delayed offer INVITE that was previously a=inactive with
>>>>> a=inactive.
>>>>>
>>>>> What's also odd is that CUCM is sending the exact same INVITE after
>>>>> the first one completes, for both the hold and the resume. The CSeq isn't
>>>>> increasing, which I would expect it to.
>>>>>
>>>>> If you were to check 'MTP' required it may work around the problem,
>>>>> but I don't consider inserting MTP's to be a best practice.
>>>>>
>>>>> -nick
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <
>>>>> kennethwhayes at gmail.com> wrote:
>>>>>
>>>>>> Bind your media and source to your outbound interface on your voice
>>>>>> service voip.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Below is a show run from the router
>>>>>>
>>>>>>
>>>>>> [OK]
>>>>>> Cisco3825#sh run
>>>>>> Building configuration...
>>>>>>
>>>>>> Current configuration : 10183 bytes
>>>>>> !
>>>>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by dnewman
>>>>>> version 15.1
>>>>>> service timestamps debug datetime msec
>>>>>> service timestamps log datetime msec
>>>>>> no service password-encryption
>>>>>> !
>>>>>> hostname Cisco3825
>>>>>> !
>>>>>> boot-start-marker
>>>>>> boot-end-marker
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> aaa new-model
>>>>>> !
>>>>>> !
>>>>>> aaa authentication login default local
>>>>>> aaa authentication login vpnauth local
>>>>>> aaa authorization exec default local
>>>>>> aaa authorization network default local
>>>>>> aaa authorization network vpnauth local
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> aaa session-id common
>>>>>> !
>>>>>> no network-clock-participate wic 0
>>>>>> !
>>>>>> dot11 syslog
>>>>>> ip source-route
>>>>>> !
>>>>>> ip cef
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> ip domain name datasc.local
>>>>>> ip inspect udp idle-time 1800
>>>>>> no ipv6 cef
>>>>>> !
>>>>>> multilink bundle-name authenticated
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> voice-card 0
>>>>>> dsp services dspfarm
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> voice service voip
>>>>>> ip address trusted list
>>>>>> ipv4 64.154.41.150 255.255.255.255
>>>>>> allow-connections sip to sip
>>>>>> fax protocol pass-through g711ulaw
>>>>>> sip
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> voice translation-rule 1
>>>>>> rule 1 /6784604564/ /200/
>>>>>> rule 2 /6784563290/ /100/
>>>>>> rule 3 /6784563291/ /101/
>>>>>> rule 4 /6784563292/ /102/
>>>>>> rule 5 /6784563293/ /103/
>>>>>> rule 6 /6784563294/ /104/
>>>>>> rule 7 /6784563295/ /105/
>>>>>> rule 8 /6784563296/ /106/
>>>>>> rule 9 /6784563297/ /107/
>>>>>> rule 10 /6784563298/ /108/
>>>>>> rule 11 /6784563299/ /109/
>>>>>> rule 12 /6784604565/ /125/
>>>>>> !
>>>>>> !
>>>>>> voice translation-profile incomingdid
>>>>>> translate called 1
>>>>>> !
>>>>>> !
>>>>>> crypto pki token default removal timeout 0
>>>>>> !
>>>>>> crypto pki trustpoint selfsigned
>>>>>> enrollment selfsigned
>>>>>> subject-name CN=connect.datasc.com
>>>>>> revocation-check crl
>>>>>> !
>>>>>> !
>>>>>> crypto pki certificate chain selfsigned
>>>>>> certificate self-signed 02
>>>>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101
>>>>>> 05050030
>>>>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63
>>>>>> 6F6D3125
>>>>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174
>>>>>> 6173632E
>>>>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031
>>>>>> 30313030
>>>>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461
>>>>>> 74617363
>>>>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338
>>>>>> 32352E64
>>>>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105
>>>>>> 0003818D
>>>>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2
>>>>>> 7729B93E
>>>>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0
>>>>>> 9A190598
>>>>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4
>>>>>> FABF9CA9
>>>>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC
>>>>>> 4EDD1712
>>>>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04
>>>>>> 05300301
>>>>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5
>>>>>> 8A571236
>>>>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A
>>>>>> 571236A1
>>>>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8
>>>>>> 8B742D4F
>>>>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1
>>>>>> B22BBB20
>>>>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3
>>>>>> EF724BD9
>>>>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3
>>>>>> 12E45933
>>>>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>>>>> quit
>>>>>> !
>>>>>> !
>>>>>> license udi pid CISCO3825 sn FTX1237A1T0
>>>>>> username xxxxxxx privilege 15 secret xxxxxx
>>>>>> !
>>>>>> redundancy
>>>>>> !
>>>>>> !
>>>>>> controller T1 0/0/0
>>>>>> !
>>>>>> controller T1 0/0/1
>>>>>> !
>>>>>> ip ssh version 2
>>>>>> !
>>>>>> !
>>>>>> crypto isakmp policy 10
>>>>>> encr aes
>>>>>> authentication pre-share
>>>>>> group 2
>>>>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>>>>> crypto isakmp fragmentation
>>>>>> !
>>>>>> crypto isakmp client configuration group datasc
>>>>>> key Recoil90
>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>> domain datasc.local
>>>>>> pool vpnpool
>>>>>> save-password
>>>>>> !
>>>>>> crypto isakmp client configuration group datascsplit
>>>>>> key Recoil90
>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>> domain datasc.local
>>>>>> pool vpnpool
>>>>>> acl 101
>>>>>> save-password
>>>>>> crypto isakmp profile datasc
>>>>>> match identity group datasc
>>>>>> client authentication list vpnauth
>>>>>> isakmp authorization list vpnauth
>>>>>> client configuration address respond
>>>>>> virtual-template 1
>>>>>> crypto isakmp profile datascsplit
>>>>>> match identity group datascsplit
>>>>>> client authentication list vpnauth
>>>>>> isakmp authorization list vpnauth
>>>>>> client configuration address respond
>>>>>> virtual-template 2
>>>>>> !
>>>>>> !
>>>>>> crypto ipsec transform-set transformset esp-aes
>>>>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>>>>> !
>>>>>> crypto ipsec profile VTI
>>>>>> set transform-set ezvpntransform
>>>>>> set isakmp-profile datasc
>>>>>> !
>>>>>> crypto ipsec profile VTI2
>>>>>> set transform-set ezvpntransform
>>>>>> set isakmp-profile datascsplit
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> interface Loopback1
>>>>>> ip address 10.1.150.1 255.255.255.0
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly in
>>>>>> !
>>>>>> interface GigabitEthernet0/0
>>>>>> ip address dhcp
>>>>>> no ip redirects
>>>>>> no ip unreachables
>>>>>> no ip proxy-arp
>>>>>> ip nat outside
>>>>>> ip virtual-reassembly in
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> media-type rj45
>>>>>> hold-queue 240000 in
>>>>>> !
>>>>>> interface GigabitEthernet0/1
>>>>>> ip address 10.1.200.1 255.255.255.252
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly in
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> media-type rj45
>>>>>> !
>>>>>> interface Virtual-Template1 type tunnel
>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly in
>>>>>> tunnel source GigabitEthernet0/0
>>>>>> tunnel mode ipsec ipv4
>>>>>> tunnel protection ipsec profile VTI
>>>>>> !
>>>>>> interface Virtual-Template2 type tunnel
>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly in
>>>>>> tunnel source GigabitEthernet0/0
>>>>>> tunnel mode ipsec ipv4
>>>>>> tunnel protection ipsec profile VTI2
>>>>>> !
>>>>>> interface Virtual-Template3
>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>> ip nat outside
>>>>>> ip virtual-reassembly in
>>>>>> ip policy route-map anyconnecthop
>>>>>> !
>>>>>> !
>>>>>> router eigrp 1
>>>>>> maximum-paths 1
>>>>>> network 10.0.0.0
>>>>>> redistribute static
>>>>>> !
>>>>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>>>>> ip forward-protocol nd
>>>>>> ip http server
>>>>>> ip http secure-server
>>>>>> !
>>>>>> !
>>>>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>>>>> overload
>>>>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>>>>> GigabitEthernet0/0 80
>>>>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>>>>> GigabitEthernet0/0 5001
>>>>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>>>>> GigabitEthernet0/0 5001
>>>>>> !
>>>>>> ip access-list extended NATNETWORKS
>>>>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>> ip access-list extended anyconnecthop
>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>> !
>>>>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>>>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> route-map anyconnecthop permit 10
>>>>>> match ip address anyconnecthop
>>>>>> set ip next-hop 10.1.150.2
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> control-plane
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> mgcp profile default
>>>>>> !
>>>>>> !
>>>>>> dial-peer voice 100 voip
>>>>>> description Publisher
>>>>>> preference 1
>>>>>> destination-pattern 1..
>>>>>> session protocol sipv2
>>>>>> session target ipv4:10.1.80.10
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 101 voip
>>>>>> description Subscriber
>>>>>> preference 2
>>>>>> destination-pattern 1..
>>>>>> session target ipv4:10.1.80.11
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 200 voip
>>>>>> description Publisher
>>>>>> preference 1
>>>>>> destination-pattern 2..
>>>>>> progress_ind setup enable 3
>>>>>> progress_ind progress enable 8
>>>>>> session protocol sipv2
>>>>>> session target ipv4:10.1.80.10
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 300 voip
>>>>>> description incoming Calldid
>>>>>> translation-profile incoming incomingdid
>>>>>> preference 1
>>>>>> session protocol sipv2
>>>>>> session target sip-server
>>>>>> incoming called-number 678456329.
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 301 voip
>>>>>> description incoming Calldid
>>>>>> translation-profile incoming incomingdid
>>>>>> preference 1
>>>>>> session protocol sipv2
>>>>>> session target sip-server
>>>>>> incoming called-number 6784604565
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 302 voip
>>>>>> description incoming Calldid
>>>>>> translation-profile incoming incomingdid
>>>>>> preference 1
>>>>>> session protocol sipv2
>>>>>> session target sip-server
>>>>>> incoming called-number 6784604564
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 201 voip
>>>>>> description Publisher
>>>>>> preference 2
>>>>>> destination-pattern 2..
>>>>>> progress_ind setup enable 3
>>>>>> progress_ind progress enable 8
>>>>>> session protocol sipv2
>>>>>> session target ipv4:10.1.80.11
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> dial-peer voice 500 voip
>>>>>> description outgoing
>>>>>> preference 1
>>>>>> destination-pattern .T
>>>>>> session protocol sipv2
>>>>>> session target dns:sip.talkinip.net
>>>>>> dtmf-relay rtp-nte
>>>>>> codec g711ulaw
>>>>>> !
>>>>>> !
>>>>>> sip-ua
>>>>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>>>>> sipconnect.ipcomms.net
>>>>>> authentication username xxxxxx password 7 xxxxxxx
>>>>>> authentication username xxxxx password 7 xxxxxxx realm
>>>>>> sipconnect.ipcomms.net
>>>>>> set pstn-cause 3 sip-status 486
>>>>>> set pstn-cause 34 sip-status 486
>>>>>> set pstn-cause 47 sip-status 486
>>>>>> registrar dns:sipconnect.ipcomms.net expires 60
>>>>>> sip-server dns:sipconnect.ipcomms.net:5060
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> gatekeeper
>>>>>> shutdown
>>>>>> !
>>>>>> !
>>>>>> call-manager-fallback
>>>>>> max-conferences 8 gain -6
>>>>>> transfer-system full-consult
>>>>>> ip source-address 10.1.200.1 port 2000
>>>>>> max-ephones 20
>>>>>> max-dn 40
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> line con 0
>>>>>> line aux 0
>>>>>> line vty 0 4
>>>>>> privilege level 15
>>>>>> transport input ssh
>>>>>> line vty 5 15
>>>>>> privilege level 15
>>>>>> transport input ssh
>>>>>> !
>>>>>> scheduler allocate 20000 1000
>>>>>> !
>>>>>> webvpn gateway gateway_1
>>>>>> ip interface GigabitEthernet0/0 port 443
>>>>>> ssl trustpoint selfsigned
>>>>>> inservice
>>>>>> !
>>>>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>>>>> sequence 1
>>>>>> !
>>>>>> webvpn context datasc
>>>>>> title "DataSC VPN"
>>>>>> secondary-color white
>>>>>> title-color #CCCC66
>>>>>> text-color black
>>>>>> ssl authenticate verify all
>>>>>> !
>>>>>> url-list "Servers"
>>>>>> heading "Server"
>>>>>> !
>>>>>> !
>>>>>> policy group datasc
>>>>>> url-list "Servers"
>>>>>> functions svc-enabled
>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>> svc keep-client-installed
>>>>>> svc dns-server primary 4.2.2.2
>>>>>> svc dtls
>>>>>> virtual-template 3
>>>>>> default-group-policy datasc
>>>>>> aaa authentication list vpnauth
>>>>>> gateway gateway_1 domain datasc
>>>>>> inservice
>>>>>> !
>>>>>> !
>>>>>> webvpn context datascsplit
>>>>>> title "DataSC VPN Split"
>>>>>> secondary-color white
>>>>>> title-color #CCCC66
>>>>>> text-color black
>>>>>> ssl authenticate verify all
>>>>>> !
>>>>>> url-list "Servers"
>>>>>> heading "Server"
>>>>>> !
>>>>>> !
>>>>>> policy group datascsplit
>>>>>> url-list "Servers"
>>>>>> functions svc-enabled
>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>> svc split include acl 50
>>>>>> svc dns-server primary 4.2.2.2
>>>>>> svc dtls
>>>>>> default-group-policy datascsplit
>>>>>> aaa authentication list vpnauth
>>>>>> gateway gateway_1 domain datascsplit
>>>>>> inservice
>>>>>> !
>>>>>> end
>>>>>> Cisco3825#
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <
>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>
>>>>>>> What do your media resources look like?
>>>>>>>
>>>>>>>
>>>>>>> Also can you show me a copy of your voice service voip config?
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks Ryan
>>>>>>>
>>>>>>> I see I am always getting a 200 ok message after my invites from the
>>>>>>> debug
>>>>>>>
>>>>>>> *Putting a call on HOLD*
>>>>>>>
>>>>>>>
>>>>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>
>>>>>>> CSeq: 102 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>
>>>>>>> Supported: Geolocation
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>
>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 240
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>
>>>>>>> b=TIAS:64000
>>>>>>>
>>>>>>> b=AS:64
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-15
>>>>>>>
>>>>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>
>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Timestamp: 1358281168
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 289
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-15
>>>>>>>
>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 102 INVITE
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 239
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>>>>
>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 13014 RTP/AVP 0 101
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 102 INVITE
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>
>>>>>>> Supported: replaces
>>>>>>>
>>>>>>> Supported: sdp-anat
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Supported: timer
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 253
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19514 RTP/AVP 0 101
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 103 ACK
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 102 ACK
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>
>>>>>>> Supported: Geolocation
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>
>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>
>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Timestamp: 1358281168
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 333
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>>>>
>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>
>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>
>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>
>>>>>>> a=fmtp:18 annexb=no
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 103 INVITE
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>
>>>>>>> Supported: replaces
>>>>>>>
>>>>>>> Supported: sdp-anat
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Supported: timer
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 277
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 103 ACK
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 209
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>
>>>>>>> b=TIAS:64000
>>>>>>>
>>>>>>> b=AS:64
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 21476 RTP/AVP 0
>>>>>>>
>>>>>>> a=X-cisco-media:nomedia
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 104 ACK
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 251
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>
>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>>
>>>>>>> *Unholding the call the MOH continues on the previously held caller
>>>>>>> while the user hears nothing*
>>>>>>>
>>>>>>> **
>>>>>>>
>>>>>>>
>>>>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>
>>>>>>> Supported: Geolocation
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>
>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>
>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Timestamp: 1358281175
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 333
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>
>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>
>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>
>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>
>>>>>>> a=fmtp:18 annexb=no
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>
>>>>>>> Supported: replaces
>>>>>>>
>>>>>>> Supported: sdp-anat
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Supported: timer
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 277
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 104 ACK
>>>>>>>
>>>>>>> Allow-Events: presence, kpml
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 243
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>
>>>>>>> b=TIAS:64000
>>>>>>>
>>>>>>> b=AS:64
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-15
>>>>>>>
>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 105 ACK
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 265
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: presence
>>>>>>>
>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>
>>>>>>> Supported: Geolocation
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>
>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>
>>>>>>> Min-SE: 1800
>>>>>>>
>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>
>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> Timestamp: 1358281175
>>>>>>>
>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>
>>>>>>> Expires: 180
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 100 Trying
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Length: 0
>>>>>>>
>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> CSeq: 105 INVITE
>>>>>>>
>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>> INFO
>>>>>>>
>>>>>>> Supported: replaces, timer
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 333
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>
>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>
>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>
>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>
>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>
>>>>>>> a=fmtp:18 annexb=no
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> SIP/2.0 200 OK
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> CSeq: 104 INVITE
>>>>>>>
>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>
>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>
>>>>>>> Supported: replaces
>>>>>>>
>>>>>>> Supported: sdp-anat
>>>>>>>
>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>
>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>
>>>>>>> Require: timer
>>>>>>>
>>>>>>> Supported: timer
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 277
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>
>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Received:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>
>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>
>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 104 ACK
>>>>>>>
>>>>>>> Allow-Events: presence, kpml
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 243
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>
>>>>>>> b=TIAS:64000
>>>>>>>
>>>>>>> b=AS:64
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-15
>>>>>>>
>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>
>>>>>>> Sent:
>>>>>>>
>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>
>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>
>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>
>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>
>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>
>>>>>>> Max-Forwards: 70
>>>>>>>
>>>>>>> CSeq: 105 ACK
>>>>>>>
>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>
>>>>>>> Allow-Events: telephone-event
>>>>>>>
>>>>>>> Content-Type: application/sdp
>>>>>>>
>>>>>>> Content-Length: 265
>>>>>>>
>>>>>>> v=0
>>>>>>>
>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>
>>>>>>> s=SIP Call
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> t=0 0
>>>>>>>
>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>
>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>
>>>>>>> a=inactive
>>>>>>>
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>
>>>>>>> a=fmtp:101 0-16
>>>>>>>
>>>>>>> a=ptime:20
>>>>>>>
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>>>>>
>>>>>>>> ccsip message is what I'd go with just to see the signaling with no
>>>>>>>> other stuff. Depending on what that shows and what your gateway is doing
>>>>>>>> to the signals you may need to expand from there.
>>>>>>>>
>>>>>>>> -Ryan
>>>>>>>>
>>>>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Ryan
>>>>>>>>
>>>>>>>> What is the proper debug to use to caputre the useful information?
>>>>>>>>
>>>>>>>> Dane
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>
>>>>>>>>> Without sip messages I can't get any clues from that.
>>>>>>>>>
>>>>>>>>> -Ryan
>>>>>>>>>
>>>>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Thanks Ryan for the input
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *On the call when I hold the call the following debug pops out....
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Jan 15 17:56:05.246:
>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>> passthru hdrs to
>>>>>>>>> container
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535 instance
>>>>>>>>> 1 not found.
>>>>>>>>> *Jan 15 17:56:05.274:
>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>> passthru headers to
>>>>>>>>> container
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>>> 1 not found.
>>>>>>>>> *Jan 15 17:56:05.286:
>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>> passthru hdrs to
>>>>>>>>> container
>>>>>>>>> *Jan 15 17:56:05.302:
>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>> passthru headers to
>>>>>>>>> container
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>>> 1 not found.
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> *Jan 15 17:56:05.322:
>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>> params for midcall INVITE
>>>>>>>>>
>>>>>>>>> *After I try to unhold the call the following debug comes out....*
>>>>>>>>> **
>>>>>>>>>
>>>>>>>>> *Jan 15 17:56:18.874:
>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>> passthru hdrs to
>>>>>>>>> container
>>>>>>>>> *Jan 15 17:56:18.894:
>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>> passthru headers to
>>>>>>>>> container
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535 instance
>>>>>>>>> 1 not found.
>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>> *Jan 15 17:56:18.906:
>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>> params for midcall INVITE
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>>
>>>>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>>>>
>>>>>>>>>> Take a look at the SIP signaling for a call. I believe the most
>>>>>>>>>> common cause to this is the ITSP not handling our transition from
>>>>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>>>>
>>>>>>>>>> -Ryan
>>>>>>>>>>
>>>>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> *Hello Kenneth*
>>>>>>>>>> **
>>>>>>>>>> *I have restarted both CUCM servers so this should have
>>>>>>>>>> restarted the services when the utils system restart happened*
>>>>>>>>>> **
>>>>>>>>>>
>>>>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>>>>> **
>>>>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>>>>> **
>>>>>>>>>> *I connected a call calling from an external number to a DiD
>>>>>>>>>> inside of my system. Once the call was connected I put the call on hold
>>>>>>>>>> and the following debug came out..the music on hold played for the
external
>>>>>>>>>> caller*
>>>>>>>>>>
>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1046)
>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1046)
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=3996)
>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=3996)
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *I then after that took off the hold and the following debug
>>>>>>>>>> came out. The call on the PSDN side still played the hold music while
>>>>>>>>>> there was no voice on the deskphone side.*
>>>>>>>>>>
>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1046)
>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1046)
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=1516)
>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>> Min=40(ms),
>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=3996)
>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>> Start=3996)
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> My ITSP will only support 711ulaw for me currently I believe.
>>>>>>>>>>> They hard coded it with me when I was initially setting it up.
>>>>>>>>>>>
>>>>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>>>>> identifying if it is?
>>>>>>>>>>>
>>>>>>>>>>> Dane
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the Reply
>>>>>>>>>>>> Oddly enough we are.
>>>>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>>>>
>>>>>>>>>>>> Internally when I user puts another user on hold everything
>>>>>>>>>>>> works. No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>>>>> When I hit resume on the deskphone the MOH still played to the
external
>>>>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <
>>>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Do you get similar behavior if you just hold and resume the
>>>>>>>>>>>>> call outside SNR features?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Ryan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <
>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Password:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>>>>> (fc1)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>>>>
>>>>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>>>>
>>>>>>>>>>>>> System image file is
>>>>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This product contains cryptographic features and is subject to
>>>>>>>>>>>>> United
>>>>>>>>>>>>> States and local country laws governing import, export,
>>>>>>>>>>>>> transfer and
>>>>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>>>>
>>>>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>>>>> encryption.
>>>>>>>>>>>>> Importers, exporters, distributors and users are responsible
>>>>>>>>>>>>> for
>>>>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>>>>> product you
>>>>>>>>>>>>> agree to comply with applicable laws and regulations. If you
>>>>>>>>>>>>> are unable
>>>>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>>>>> immediately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products
>>>>>>>>>>>>> may be found at:
>>>>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you require further assistance please contact us by sending
>>>>>>>>>>>>> email to
>>>>>>>>>>>>> export at cisco.com.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of
>>>>>>>>>>>>> memory.
>>>>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>>>>
>>>>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> License Info:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> License UDI:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> Device# PID SN
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <
>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have an issue when users are connected to a call and hit
>>>>>>>>>>>>> the mobility soft key button on 9971 phones when a call is active,
the
>>>>>>>>>>>>> phone system rings on the mobile number configured in the system.
When
>>>>>>>>>>>>> they pick up the the mobile number it just plays what sounds like
hold
>>>>>>>>>>>>> music on both ends of the call (I believe this music is coming from
cucm
>>>>>>>>>>>>> but I haven't heard it before) instead of providing 2 way voice.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In another senario with what I believe is the same issue. If a
>>>>>>>>>>>>> user picks up on there cell phone first (using single number reach)
opposed
>>>>>>>>>>>>> to the deskphone the call is connected with 2 way voice and no issues
>>>>>>>>>>>>> exist. If the user then hangs up his cell phone with the intent to
take
>>>>>>>>>>>>> the call on his deskphone the calling party starts hearing the hold
music.
>>>>>>>>>>>>> Once the user picks up the call on his deskphone he hears nothing
but the
>>>>>>>>>>>>> calling party is still hearing the hold music. It is not working as
>>>>>>>>>>>>> intended where 2 way voice happens once the user hangs up his mobile
phone
>>>>>>>>>>>>> and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My topology is as follows..
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM
>>>>>>>>>>>>> -->DESKPHOHE
>>>>>>>>>>>>>
>>>>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> <moh.jpg>_______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d66b5e0c/attachment.html>

From dane.newman at gmail.com Wed Jan 16 13:56:10 2013


From: dane.newman at gmail.com (Dane Newman)
Date: Wed, 16 Jan 2013 13:56:10 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK3zTRk7JEpre_=fqtfnvwDxRuJq5Nns3P-eL2tSR29UzQ@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
<36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
<CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>
<DD3CCA65-34A2-4EEA-ADA4-380F5CE35DE8@cisco.com>
<CAL-DCK3zTRk7JEpre_=fqtfnvwDxRuJq5Nns3P-eL2tSR29UzQ@mail.gmail.com>
Message-ID: <CAL-DCK311DBY+OXP1EFgkaG6EC8Nxx=5=8qqV+pjCK4YqoHCJQ@mail.gmail.com>

All

The issue has been resolved I believe (I feel very dumb)....Thank you so
much all for your assistance!

Ryan and Nick was 100% correct my MTP was not working correctly. I found
that it was miss configured and in the default device pool instead of the
correct one. Once I put it in the correct device pools I could hold calls
and everything works correctly now.
On Wed, Jan 16, 2013 at 1:27 PM, Dane Newman <dane.newman at gmail.com> wrote:

> Ryan
>
> Thank you again for responding and sharing your wisdom.
>
> I am unsure if I am doing the test to verify your thoughts correctly but I
> debugged the SIP messages once again. I placed a call and picked up the
> call with and without the MTP checkbox checked on the SIP trunk in cucm.
>
> I then did a search for the IP address of my IP phone 10.1.10.18.
>
> In both debugs with and without it checked I found my IP phone's IP
> address in the debug. I believe this might verify your idea that the MTP
> is not working correctly?
>
> *With MTP unchecked on the SIP TRUNk*
> *Jan 16 18:33:28.384: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK4e47f806d
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=673~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145612
> To: <sip:17705439047 at 10.1.200.1>;tag=333141D8-1492
> Date: Wed, 16 Jan 2013 18:11:29 GMT
> Call-ID: 24e56400-f61ed51-12-a50010a at 10.1.80.10
> Max-Forwards: 70
> CSeq: 101 ACK
> Allow-Events: presence, kpml
> Content-Type: application/sdp
> Content-Length: 230
> v=0
> o=CiscoSystemsCCM-SIP 673 1 IN IP4 10.1.80.10
> s=SIP Call
> c=IN IP4 10.1.10.18
> b=TIAS:64000
> b=AS:64
> t=0 0
> m=audio 20116 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=ptime:20
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
> *With MTP checked on the SIP TRUNk*
>
> *Jan 16 18:39:09.732: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK60b810f25
> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
> >;tag=723~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145637
> To: <sip:17705439047 at 10.1.200.1>;tag=3336625C-1CBB
> Date: Wed, 16 Jan 2013 18:17:05 GMT
> Call-ID: ed2aec00-f61eea1-16-a50010a at 10.1.80.10
> Max-Forwards: 70
> CSeq: 101 ACK
> Allow-Events: presence, kpml
> Content-Type: application/sdp
> Content-Length: 230
> v=0
> o=CiscoSystemsCCM-SIP 723 2 IN IP4 10.1.80.10
> s=SIP Call
> c=IN IP4 10.1.10.18
> b=TIAS:64000
> b=AS:64
> t=0 0
> m=audio 16452 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=ptime:20
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
>
>
> On Wed, Jan 16, 2013 at 12:59 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> What they are doing is interpreting us sending them an Invite with
>> a=inactive in the SDP as the Cisco phone putting them on hold. That is a
>> valid assumption. What is incorrect (IMO) is them assuming that they need
>> to generate MOH. CUCM is the one initiating the hold, it will be the one
>> to play MOH or not, based upon the way you configure it. When they
>> respond to our inactive SDP with one of their own, CUCM sees that as them
>> putting us on hold. The end result you see is that in order to get the
>> call off of hold both sides need to resume it, which isn't happening.
>>
>> I still think you need to look at an active call (no hold) on your CUBE
>> to see where it's sending media to on the internal side. That IP address
>> is going to be an MTP (CUCM server, hardware resource) or an IP phone. If
>> it's directly to a phone you may as well remove "MTP Required" on the trunk
>> because you're not actually allocating an MTP.
>>
>> -Ryan
>>
>> On Jan 16, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>
>> All
>>
>> Thank you for the infromation you are providing me on this thread. It is
>> a great learning exp for me.
>>
>> I just got off the phone with the ITSP and they confirmed the MOH was
>> coming from them. They believe if I am typing this correctly they
>> (ITSP) claim when I press the hold button I am sending an invite message
>> and that is resulting in the MOH being played by them.
>>
>> I assumed when I pressed the hold key on an external call CUCM would
>> continue to send the uninterupted audio stream with the MOH mixed in?
>>
>> I have reset the trunk and rebooted cucm also...
>>
>> Thanks again for the assistance and advice it's much appericated
>>
>> Dane
>>
>>
>>
>> On Wed, Jan 16, 2013 at 12:18 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>
>>> Having the MOH servers registered is step 1 of about 10 that have to
>>> happen for MOH to be allocated for the call.
>>> In the SIP signaling you sent there was no possibility you heard MOH
>>> from CUCM because the media stream never went back to active after the
>>> hold. Can your Asterix play MOH?
>>>
>>> You need to look at ccm traces to debug this further. If you can't
>>> figure it out, then it's time to call TAC.
>>>
>>> You should also take a look at your active call before it's getting put
>>> on hold. You've got MTP Required set on the SIP trunk, but if an MTP was
>>> really getting allocated I don't believe we'd ever set the media inactive
>>> to the trunk, we'd be telling the MTP about media changes and the trunk
>>> would just see one media stream to the MTP for the entire call. At the
>>> same time if we tried to allocate an MTP but failed, that usually ends up
>>> disabling supplementary services for the call, which means you never would
>>> have been allowed to hold in the first place. It's certainly possible
>>> that has changed for SIP EO MTPs but for now what is in that signaling
>>> doesn't jive with what you've sent in your config and description of
>>> events.
>>>
>>> Have you tried resetting the SIP trunk in CUCM yet?
>>>
>>> -Ryan
>>>
>>> On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> Yes as per the screen shot the MOH servers are registered. How do In
>>> find the audio bit rate? its just the default moh file I didnt change any
>>> settings
>>>
>>> On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <kennethwhayes at gmail.com
>>> > wrote:
>>>
>>>> So have you looked in your media resources under music on hold server
>>>> configurations to make sure it's registered to the right UCM? Also what
>>>> audio bit rate is your MOH file?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com>
>>>> wrote:
>>>>
>>>> I'm not sure at this point, I'll let some of the CUCM experts comment.
>>>> It's possible during the hold conversation CUCM always sends delayed offer,
>>>> but I don't have some good traces in front of me to confirm.
>>>>
>>>> You can check the original invite CUCM sends to see if there's SDP in
>>>> that, and it would confirm the MTP is being allocated. If it's sending the
>>>> INVITE without SDP, your MRG/MRGL or resources are misconfigured or in use.
>>>>
>>>> -nick
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com>wrote:
>>>>
>>>>> Nick
>>>>>
>>>>> Thanks for the assistance.
>>>>>
>>>>> This is the first time I am setting up a direct sip connection from
>>>>> cucm to cube. I am used to making it an h323 connection. Attached are
>>>>> screen shots of my trunk setup. MTP is checked off I believe already.
>>>>> Is there a best way to go about troubleshooting cucm to figure out why its
>>>>> not setting the stream back to active?
>>>>>
>>>>> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>>>>
>>>>>> It looks like CUCM isn't setting the stream back to active after
>>>>>> putting it on hold. It sends the re-invite, and the 200 OK from the ITSP
>>>>>> has the SDP continued with a=inactive.
>>>>>>
>>>>>> I don't have some good traces in front of me, but somewhere it needs
>>>>>> to take that off. I don't think Asterisks is acting incorrectly by
>>>>>> responding to a delayed offer INVITE that was previously a=inactive with
>>>>>> a=inactive.
>>>>>>
>>>>>> What's also odd is that CUCM is sending the exact same INVITE after
>>>>>> the first one completes, for both the hold and the resume. The CSeq isn't
>>>>>> increasing, which I would expect it to.
>>>>>>
>>>>>> If you were to check 'MTP' required it may work around the problem,
>>>>>> but I don't consider inserting MTP's to be a best practice.
>>>>>>
>>>>>> -nick
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <
>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>
>>>>>>> Bind your media and source to your outbound interface on your voice
>>>>>>> service voip.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Below is a show run from the router
>>>>>>>
>>>>>>>
>>>>>>> [OK]
>>>>>>> Cisco3825#sh run
>>>>>>> Building configuration...
>>>>>>>
>>>>>>> Current configuration : 10183 bytes
>>>>>>> !
>>>>>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by
>>>>>>> dnewman
>>>>>>> version 15.1
>>>>>>> service timestamps debug datetime msec
>>>>>>> service timestamps log datetime msec
>>>>>>> no service password-encryption
>>>>>>> !
>>>>>>> hostname Cisco3825
>>>>>>> !
>>>>>>> boot-start-marker
>>>>>>> boot-end-marker
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> aaa new-model
>>>>>>> !
>>>>>>> !
>>>>>>> aaa authentication login default local
>>>>>>> aaa authentication login vpnauth local
>>>>>>> aaa authorization exec default local
>>>>>>> aaa authorization network default local
>>>>>>> aaa authorization network vpnauth local
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> aaa session-id common
>>>>>>> !
>>>>>>> no network-clock-participate wic 0
>>>>>>> !
>>>>>>> dot11 syslog
>>>>>>> ip source-route
>>>>>>> !
>>>>>>> ip cef
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> ip domain name datasc.local
>>>>>>> ip inspect udp idle-time 1800
>>>>>>> no ipv6 cef
>>>>>>> !
>>>>>>> multilink bundle-name authenticated
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> voice-card 0
>>>>>>> dsp services dspfarm
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> voice service voip
>>>>>>> ip address trusted list
>>>>>>> ipv4 64.154.41.150 255.255.255.255
>>>>>>> allow-connections sip to sip
>>>>>>> fax protocol pass-through g711ulaw
>>>>>>> sip
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> voice translation-rule 1
>>>>>>> rule 1 /6784604564/ /200/
>>>>>>> rule 2 /6784563290/ /100/
>>>>>>> rule 3 /6784563291/ /101/
>>>>>>> rule 4 /6784563292/ /102/
>>>>>>> rule 5 /6784563293/ /103/
>>>>>>> rule 6 /6784563294/ /104/
>>>>>>> rule 7 /6784563295/ /105/
>>>>>>> rule 8 /6784563296/ /106/
>>>>>>> rule 9 /6784563297/ /107/
>>>>>>> rule 10 /6784563298/ /108/
>>>>>>> rule 11 /6784563299/ /109/
>>>>>>> rule 12 /6784604565/ /125/
>>>>>>> !
>>>>>>> !
>>>>>>> voice translation-profile incomingdid
>>>>>>> translate called 1
>>>>>>> !
>>>>>>> !
>>>>>>> crypto pki token default removal timeout 0
>>>>>>> !
>>>>>>> crypto pki trustpoint selfsigned
>>>>>>> enrollment selfsigned
>>>>>>> subject-name CN=connect.datasc.com
>>>>>>> revocation-check crl
>>>>>>> !
>>>>>>> !
>>>>>>> crypto pki certificate chain selfsigned
>>>>>>> certificate self-signed 02
>>>>>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101
>>>>>>> 05050030
>>>>>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63
>>>>>>> 6F6D3125
>>>>>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174
>>>>>>> 6173632E
>>>>>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031
>>>>>>> 30313030
>>>>>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461
>>>>>>> 74617363
>>>>>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338
>>>>>>> 32352E64
>>>>>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105
>>>>>>> 0003818D
>>>>>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2
>>>>>>> 7729B93E
>>>>>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0
>>>>>>> 9A190598
>>>>>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4
>>>>>>> FABF9CA9
>>>>>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC
>>>>>>> 4EDD1712
>>>>>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04
>>>>>>> 05300301
>>>>>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5
>>>>>>> 8A571236
>>>>>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A
>>>>>>> 571236A1
>>>>>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8
>>>>>>> 8B742D4F
>>>>>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1
>>>>>>> B22BBB20
>>>>>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3
>>>>>>> EF724BD9
>>>>>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3
>>>>>>> 12E45933
>>>>>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>>>>>> quit
>>>>>>> !
>>>>>>> !
>>>>>>> license udi pid CISCO3825 sn FTX1237A1T0
>>>>>>> username xxxxxxx privilege 15 secret xxxxxx
>>>>>>> !
>>>>>>> redundancy
>>>>>>> !
>>>>>>> !
>>>>>>> controller T1 0/0/0
>>>>>>> !
>>>>>>> controller T1 0/0/1
>>>>>>> !
>>>>>>> ip ssh version 2
>>>>>>> !
>>>>>>> !
>>>>>>> crypto isakmp policy 10
>>>>>>> encr aes
>>>>>>> authentication pre-share
>>>>>>> group 2
>>>>>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>>>>>> crypto isakmp fragmentation
>>>>>>> !
>>>>>>> crypto isakmp client configuration group datasc
>>>>>>> key Recoil90
>>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>>> domain datasc.local
>>>>>>> pool vpnpool
>>>>>>> save-password
>>>>>>> !
>>>>>>> crypto isakmp client configuration group datascsplit
>>>>>>> key Recoil90
>>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>>> domain datasc.local
>>>>>>> pool vpnpool
>>>>>>> acl 101
>>>>>>> save-password
>>>>>>> crypto isakmp profile datasc
>>>>>>> match identity group datasc
>>>>>>> client authentication list vpnauth
>>>>>>> isakmp authorization list vpnauth
>>>>>>> client configuration address respond
>>>>>>> virtual-template 1
>>>>>>> crypto isakmp profile datascsplit
>>>>>>> match identity group datascsplit
>>>>>>> client authentication list vpnauth
>>>>>>> isakmp authorization list vpnauth
>>>>>>> client configuration address respond
>>>>>>> virtual-template 2
>>>>>>> !
>>>>>>> !
>>>>>>> crypto ipsec transform-set transformset esp-aes
>>>>>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>>>>>> !
>>>>>>> crypto ipsec profile VTI
>>>>>>> set transform-set ezvpntransform
>>>>>>> set isakmp-profile datasc
>>>>>>> !
>>>>>>> crypto ipsec profile VTI2
>>>>>>> set transform-set ezvpntransform
>>>>>>> set isakmp-profile datascsplit
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> interface Loopback1
>>>>>>> ip address 10.1.150.1 255.255.255.0
>>>>>>> ip nat inside
>>>>>>> ip virtual-reassembly in
>>>>>>> !
>>>>>>> interface GigabitEthernet0/0
>>>>>>> ip address dhcp
>>>>>>> no ip redirects
>>>>>>> no ip unreachables
>>>>>>> no ip proxy-arp
>>>>>>> ip nat outside
>>>>>>> ip virtual-reassembly in
>>>>>>> duplex auto
>>>>>>> speed auto
>>>>>>> media-type rj45
>>>>>>> hold-queue 240000 in
>>>>>>> !
>>>>>>> interface GigabitEthernet0/1
>>>>>>> ip address 10.1.200.1 255.255.255.252
>>>>>>> ip nat inside
>>>>>>> ip virtual-reassembly in
>>>>>>> duplex auto
>>>>>>> speed auto
>>>>>>> media-type rj45
>>>>>>> !
>>>>>>> interface Virtual-Template1 type tunnel
>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>> ip nat inside
>>>>>>> ip virtual-reassembly in
>>>>>>> tunnel source GigabitEthernet0/0
>>>>>>> tunnel mode ipsec ipv4
>>>>>>> tunnel protection ipsec profile VTI
>>>>>>> !
>>>>>>> interface Virtual-Template2 type tunnel
>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>> ip nat inside
>>>>>>> ip virtual-reassembly in
>>>>>>> tunnel source GigabitEthernet0/0
>>>>>>> tunnel mode ipsec ipv4
>>>>>>> tunnel protection ipsec profile VTI2
>>>>>>> !
>>>>>>> interface Virtual-Template3
>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>> ip nat outside
>>>>>>> ip virtual-reassembly in
>>>>>>> ip policy route-map anyconnecthop
>>>>>>> !
>>>>>>> !
>>>>>>> router eigrp 1
>>>>>>> maximum-paths 1
>>>>>>> network 10.0.0.0
>>>>>>> redistribute static
>>>>>>> !
>>>>>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>>>>>> ip forward-protocol nd
>>>>>>> ip http server
>>>>>>> ip http secure-server
>>>>>>> !
>>>>>>> !
>>>>>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>>>>>> overload
>>>>>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>>>>>> GigabitEthernet0/0 80
>>>>>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>>>>>> GigabitEthernet0/0 5001
>>>>>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>>>>>> GigabitEthernet0/0 5001
>>>>>>> !
>>>>>>> ip access-list extended NATNETWORKS
>>>>>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>>> ip access-list extended anyconnecthop
>>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>>> !
>>>>>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>>>>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> route-map anyconnecthop permit 10
>>>>>>> match ip address anyconnecthop
>>>>>>> set ip next-hop 10.1.150.2
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> control-plane
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> mgcp profile default
>>>>>>> !
>>>>>>> !
>>>>>>> dial-peer voice 100 voip
>>>>>>> description Publisher
>>>>>>> preference 1
>>>>>>> destination-pattern 1..
>>>>>>> session protocol sipv2
>>>>>>> session target ipv4:10.1.80.10
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 101 voip
>>>>>>> description Subscriber
>>>>>>> preference 2
>>>>>>> destination-pattern 1..
>>>>>>> session target ipv4:10.1.80.11
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 200 voip
>>>>>>> description Publisher
>>>>>>> preference 1
>>>>>>> destination-pattern 2..
>>>>>>> progress_ind setup enable 3
>>>>>>> progress_ind progress enable 8
>>>>>>> session protocol sipv2
>>>>>>> session target ipv4:10.1.80.10
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 300 voip
>>>>>>> description incoming Calldid
>>>>>>> translation-profile incoming incomingdid
>>>>>>> preference 1
>>>>>>> session protocol sipv2
>>>>>>> session target sip-server
>>>>>>> incoming called-number 678456329.
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 301 voip
>>>>>>> description incoming Calldid
>>>>>>> translation-profile incoming incomingdid
>>>>>>> preference 1
>>>>>>> session protocol sipv2
>>>>>>> session target sip-server
>>>>>>> incoming called-number 6784604565
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 302 voip
>>>>>>> description incoming Calldid
>>>>>>> translation-profile incoming incomingdid
>>>>>>> preference 1
>>>>>>> session protocol sipv2
>>>>>>> session target sip-server
>>>>>>> incoming called-number 6784604564
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 201 voip
>>>>>>> description Publisher
>>>>>>> preference 2
>>>>>>> destination-pattern 2..
>>>>>>> progress_ind setup enable 3
>>>>>>> progress_ind progress enable 8
>>>>>>> session protocol sipv2
>>>>>>> session target ipv4:10.1.80.11
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> dial-peer voice 500 voip
>>>>>>> description outgoing
>>>>>>> preference 1
>>>>>>> destination-pattern .T
>>>>>>> session protocol sipv2
>>>>>>> session target dns:sip.talkinip.net
>>>>>>> dtmf-relay rtp-nte
>>>>>>> codec g711ulaw
>>>>>>> !
>>>>>>> !
>>>>>>> sip-ua
>>>>>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>>>>>> sipconnect.ipcomms.net
>>>>>>> authentication username xxxxxx password 7 xxxxxxx
>>>>>>> authentication username xxxxx password 7 xxxxxxx realm
>>>>>>> sipconnect.ipcomms.net
>>>>>>> set pstn-cause 3 sip-status 486
>>>>>>> set pstn-cause 34 sip-status 486
>>>>>>> set pstn-cause 47 sip-status 486
>>>>>>> registrar dns:sipconnect.ipcomms.net expires 60
>>>>>>> sip-server dns:sipconnect.ipcomms.net:5060
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> gatekeeper
>>>>>>> shutdown
>>>>>>> !
>>>>>>> !
>>>>>>> call-manager-fallback
>>>>>>> max-conferences 8 gain -6
>>>>>>> transfer-system full-consult
>>>>>>> ip source-address 10.1.200.1 port 2000
>>>>>>> max-ephones 20
>>>>>>> max-dn 40
>>>>>>> !
>>>>>>> !
>>>>>>> !
>>>>>>> line con 0
>>>>>>> line aux 0
>>>>>>> line vty 0 4
>>>>>>> privilege level 15
>>>>>>> transport input ssh
>>>>>>> line vty 5 15
>>>>>>> privilege level 15
>>>>>>> transport input ssh
>>>>>>> !
>>>>>>> scheduler allocate 20000 1000
>>>>>>> !
>>>>>>> webvpn gateway gateway_1
>>>>>>> ip interface GigabitEthernet0/0 port 443
>>>>>>> ssl trustpoint selfsigned
>>>>>>> inservice
>>>>>>> !
>>>>>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>>>>>> sequence 1
>>>>>>> !
>>>>>>> webvpn context datasc
>>>>>>> title "DataSC VPN"
>>>>>>> secondary-color white
>>>>>>> title-color #CCCC66
>>>>>>> text-color black
>>>>>>> ssl authenticate verify all
>>>>>>> !
>>>>>>> url-list "Servers"
>>>>>>> heading "Server"
>>>>>>> !
>>>>>>> !
>>>>>>> policy group datasc
>>>>>>> url-list "Servers"
>>>>>>> functions svc-enabled
>>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>>> svc keep-client-installed
>>>>>>> svc dns-server primary 4.2.2.2
>>>>>>> svc dtls
>>>>>>> virtual-template 3
>>>>>>> default-group-policy datasc
>>>>>>> aaa authentication list vpnauth
>>>>>>> gateway gateway_1 domain datasc
>>>>>>> inservice
>>>>>>> !
>>>>>>> !
>>>>>>> webvpn context datascsplit
>>>>>>> title "DataSC VPN Split"
>>>>>>> secondary-color white
>>>>>>> title-color #CCCC66
>>>>>>> text-color black
>>>>>>> ssl authenticate verify all
>>>>>>> !
>>>>>>> url-list "Servers"
>>>>>>> heading "Server"
>>>>>>> !
>>>>>>> !
>>>>>>> policy group datascsplit
>>>>>>> url-list "Servers"
>>>>>>> functions svc-enabled
>>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>>> svc split include acl 50
>>>>>>> svc dns-server primary 4.2.2.2
>>>>>>> svc dtls
>>>>>>> default-group-policy datascsplit
>>>>>>> aaa authentication list vpnauth
>>>>>>> gateway gateway_1 domain datascsplit
>>>>>>> inservice
>>>>>>> !
>>>>>>> end
>>>>>>> Cisco3825#
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <
>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>
>>>>>>>> What do your media resources look like?
>>>>>>>>
>>>>>>>>
>>>>>>>> Also can you show me a copy of your voice service voip config?
>>>>>>>>
>>>>>>>> Sent from my iPad
>>>>>>>>
>>>>>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Thanks Ryan
>>>>>>>>
>>>>>>>> I see I am always getting a 200 ok message after my invites from
>>>>>>>> the debug
>>>>>>>>
>>>>>>>> *Putting a call on HOLD*
>>>>>>>>
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>
>>>>>>>> CSeq: 102 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>
>>>>>>>> Supported: Geolocation
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>
>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 240
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>
>>>>>>>> b=TIAS:64000
>>>>>>>>
>>>>>>>> b=AS:64
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-15
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>
>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Timestamp: 1358281168
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 289
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-15
>>>>>>>>
>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 102 INVITE
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 239
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 13014 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 102 INVITE
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>
>>>>>>>> Supported: replaces
>>>>>>>>
>>>>>>>> Supported: sdp-anat
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Supported: timer
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 253
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19514 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 103 ACK
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 102 ACK
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>
>>>>>>>> Supported: Geolocation
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>
>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>
>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Timestamp: 1358281168
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 333
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>
>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>
>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>
>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 103 INVITE
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>
>>>>>>>> Supported: replaces
>>>>>>>>
>>>>>>>> Supported: sdp-anat
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Supported: timer
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 277
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 103 ACK
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 209
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>
>>>>>>>> b=TIAS:64000
>>>>>>>>
>>>>>>>> b=AS:64
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 21476 RTP/AVP 0
>>>>>>>>
>>>>>>>> a=X-cisco-media:nomedia
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 104 ACK
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 251
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>>
>>>>>>>> *Unholding the call the MOH continues on the previously held
>>>>>>>> caller while the user hears nothing*
>>>>>>>>
>>>>>>>> **
>>>>>>>>
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>
>>>>>>>> Supported: Geolocation
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>
>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>
>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Timestamp: 1358281175
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 333
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>
>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>
>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>
>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>
>>>>>>>> Supported: replaces
>>>>>>>>
>>>>>>>> Supported: sdp-anat
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Supported: timer
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 277
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 104 ACK
>>>>>>>>
>>>>>>>> Allow-Events: presence, kpml
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 243
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>>
>>>>>>>> b=TIAS:64000
>>>>>>>>
>>>>>>>> b=AS:64
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-15
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 105 ACK
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 265
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>>
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: presence
>>>>>>>>
>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>
>>>>>>>> Supported: Geolocation
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>
>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>
>>>>>>>> Min-SE: 1800
>>>>>>>>
>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>
>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> Timestamp: 1358281175
>>>>>>>>
>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>
>>>>>>>> Expires: 180
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Length: 0
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> CSeq: 105 INVITE
>>>>>>>>
>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>>>>>> INFO
>>>>>>>>
>>>>>>>> Supported: replaces, timer
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 333
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>
>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>
>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>
>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>
>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> SIP/2.0 200 OK
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> CSeq: 104 INVITE
>>>>>>>>
>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>
>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>
>>>>>>>> Supported: replaces
>>>>>>>>
>>>>>>>> Supported: sdp-anat
>>>>>>>>
>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>
>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>
>>>>>>>> Require: timer
>>>>>>>>
>>>>>>>> Supported: timer
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 277
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Received:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>
>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 104 ACK
>>>>>>>>
>>>>>>>> Allow-Events: presence, kpml
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 243
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>>
>>>>>>>> b=TIAS:64000
>>>>>>>>
>>>>>>>> b=AS:64
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-15
>>>>>>>>
>>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>
>>>>>>>> Sent:
>>>>>>>>
>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>
>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>>
>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>
>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>
>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>
>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>
>>>>>>>> Max-Forwards: 70
>>>>>>>>
>>>>>>>> CSeq: 105 ACK
>>>>>>>>
>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>
>>>>>>>> Allow-Events: telephone-event
>>>>>>>>
>>>>>>>> Content-Type: application/sdp
>>>>>>>>
>>>>>>>> Content-Length: 265
>>>>>>>>
>>>>>>>> v=0
>>>>>>>>
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> s=SIP Call
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> t=0 0
>>>>>>>>
>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>
>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>
>>>>>>>> a=inactive
>>>>>>>>
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>
>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>
>>>>>>>> a=fmtp:101 0-16
>>>>>>>>
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>
>>>>>>>>> ccsip message is what I'd go with just to see the signaling with
>>>>>>>>> no other stuff. Depending on what that shows and what your gateway is
>>>>>>>>> doing to the signals you may need to expand from there.
>>>>>>>>>
>>>>>>>>> -Ryan
>>>>>>>>>
>>>>>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ryan
>>>>>>>>>
>>>>>>>>> What is the proper debug to use to caputre the useful information?
>>>>>>>>>
>>>>>>>>> Dane
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <rratliff at cisco.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Without sip messages I can't get any clues from that.
>>>>>>>>>>
>>>>>>>>>> -Ryan
>>>>>>>>>>
>>>>>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks Ryan for the input
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *On the call when I hold the call the following debug pops
>>>>>>>>>> out....*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Jan 15 17:56:05.246:
>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>> passthru hdrs to
>>>>>>>>>> container
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535
>>>>>>>>>> instance 1 not found.
>>>>>>>>>> *Jan 15 17:56:05.274:
>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>> passthru headers to
>>>>>>>>>> container
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>> instance 1 not found.
>>>>>>>>>> *Jan 15 17:56:05.286:
>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>> passthru hdrs to
>>>>>>>>>> container
>>>>>>>>>> *Jan 15 17:56:05.302:
>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>> passthru headers to
>>>>>>>>>> container
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>> instance 1 not found.
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> *Jan 15 17:56:05.322:
>>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>>> params for midcall INVITE
>>>>>>>>>>
>>>>>>>>>> *After I try to unhold the call the following debug comes out....
>>>>>>>>>> *
>>>>>>>>>> **
>>>>>>>>>>
>>>>>>>>>> *Jan 15 17:56:18.874:
>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>> passthru hdrs to
>>>>>>>>>> container
>>>>>>>>>> *Jan 15 17:56:18.894:
>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>> passthru headers to
>>>>>>>>>> container
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>> instance 1 not found.
>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>> *Jan 15 17:56:18.906:
>>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>>> params for midcall INVITE
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>> Cisco3825#
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <rratliff at cisco.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>>>>>
>>>>>>>>>>> Take a look at the SIP signaling for a call. I believe the
>>>>>>>>>>> most common cause to this is the ITSP not handling our transition from
>>>>>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>>>>>
>>>>>>>>>>> -Ryan
>>>>>>>>>>>
>>>>>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> *Hello Kenneth*
>>>>>>>>>>> **
>>>>>>>>>>> *I have restarted both CUCM servers so this should have
>>>>>>>>>>> restarted the services when the utils system restart happened*
>>>>>>>>>>> **
>>>>>>>>>>>
>>>>>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>>>>>> **
>>>>>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>>>>>> **
>>>>>>>>>>> *I connected a call calling from an external number to a DiD
>>>>>>>>>>> inside of my system. Once the call was connected I put the call on
hold
>>>>>>>>>>> and the following debug came out..the music on hold played for the
external
>>>>>>>>>>> caller*
>>>>>>>>>>>
>>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1046)
>>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1046)
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=3996)
>>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=3996)
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *I then after that took off the hold and the following debug
>>>>>>>>>>> came out. The call on the PSDN side still played the hold music while
>>>>>>>>>>> there was no voice on the deskphone side.*
>>>>>>>>>>>
>>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.783: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1046)
>>>>>>>>>>> *Jan 14 23:47:40.783: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1046)
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.811: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.811: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.843: //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.843: //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=1516)
>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.859: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>> *Jan 14 23:47:40.863: //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=3996)
>>>>>>>>>>> *Jan 14 23:47:40.863: //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>> Start=3996)
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> My ITSP will only support 711ulaw for me currently I believe.
>>>>>>>>>>>> They hard coded it with me when I was initially setting it up.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you think this could be a codec issue? How would I go about
>>>>>>>>>>>> identifying if it is?
>>>>>>>>>>>>
>>>>>>>>>>>> Dane
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <
>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the Reply
>>>>>>>>>>>>> Oddly enough we are.
>>>>>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Internally when I user puts another user on hold everything
>>>>>>>>>>>>> works. No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>>>>>> external caller on hold the MOH played but I was unable to resume the
call.
>>>>>>>>>>>>> When I hit resume on the deskphone the MOH still played to the
external
>>>>>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <
>>>>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you get similar behavior if you just hold and resume the
>>>>>>>>>>>>>> call outside SNR features?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Ryan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <
>>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Password:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE
>>>>>>>>>>>>>> (fc1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour, 38 minutes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> System returned to ROM by power-on
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> System image file is
>>>>>>>>>>>>>> "flash:c3825-adventerprisek9_ivs_li-mz.151-4.M5.bin"
>>>>>>>>>>>>>> Last reload type: Normal Reload
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This product contains cryptographic features and is subject
>>>>>>>>>>>>>> to United
>>>>>>>>>>>>>> States and local country laws governing import, export,
>>>>>>>>>>>>>> transfer and
>>>>>>>>>>>>>> use. Delivery of Cisco cryptographic products does not imply
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> third-party authority to import, export, distribute or use
>>>>>>>>>>>>>> encryption.
>>>>>>>>>>>>>> Importers, exporters, distributors and users are responsible
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> compliance with U.S. and local country laws. By using this
>>>>>>>>>>>>>> product you
>>>>>>>>>>>>>> agree to comply with applicable laws and regulations. If you
>>>>>>>>>>>>>> are unable
>>>>>>>>>>>>>> to comply with U.S. and local laws, return this product
>>>>>>>>>>>>>> immediately.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A summary of U.S. laws governing Cisco cryptographic products
>>>>>>>>>>>>>> may be found at:
>>>>>>>>>>>>>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you require further assistance please contact us by
>>>>>>>>>>>>>> sending email to
>>>>>>>>>>>>>> export at cisco.com.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cisco 3825 (revision 1.2) with 1011712K/36864K bytes of
>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>> Processor board ID FTX1237A1T0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2 Gigabit Ethernet interfaces
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2 Channelized T1/PRI ports
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1 Virtual Private Network (VPN) Module
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DRAM configuration is 64 bits wide with parity enabled.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 479K bytes of NVRAM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 500472K bytes of ATA System CompactFlash (Read/Write)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> License Info:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> License UDI:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Device# PID SN
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my mobile device
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <
>>>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What version of code are you running on the CUBE?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 14, 2013, at 3:43 PM, Dane Newman <
>>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have an issue when users are connected to a call and hit
>>>>>>>>>>>>>> the mobility soft key button on 9971 phones when a call is active,
the
>>>>>>>>>>>>>> phone system rings on the mobile number configured in the system.
When
>>>>>>>>>>>>>> they pick up the the mobile number it just plays what sounds like
hold
>>>>>>>>>>>>>> music on both ends of the call (I believe this music is coming from
cucm
>>>>>>>>>>>>>> but I haven't heard it before) instead of providing 2 way voice.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In another senario with what I believe is the same issue. If
>>>>>>>>>>>>>> a user picks up on there cell phone first (using single number
reach)
>>>>>>>>>>>>>> opposed to the deskphone the call is connected with 2 way voice and
no
>>>>>>>>>>>>>> issues exist. If the user then hangs up his cell phone with the
intent to
>>>>>>>>>>>>>> take the call on his deskphone the calling party starts hearing the
hold
>>>>>>>>>>>>>> music. Once the user picks up the call on his deskphone he hears
nothing
>>>>>>>>>>>>>> but the calling party is still hearing the hold music. It is not
working
>>>>>>>>>>>>>> as intended where 2 way voice happens once the user hangs up his
mobile
>>>>>>>>>>>>>> phone and picks up on his deskphone 2 way voice should happen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My topology is as follows..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PSDN --> SIP TRUNK FROM ITSP --> 3825 CUBE --->CUCM
>>>>>>>>>>>>>> -->DESKPHOHE
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Calls are sent back out the SIP trunk to the ITSP when using
>>>>>>>>>>>>>> mobile connect/snr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does anyone have any ideas how I can make 2 way voice happen
>>>>>>>>>>>>>> instead of the hold music when the calls are picked up?
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> <moh.jpg>_______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/3414ca16/attachment.html>

From abbaseo at gmail.com Wed Jan 16 14:28:17 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 19:28:17 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
<A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
<CAFdHCp7ZrCWqKT+Sa7dHWLdW_CF9S3_3i26oSjcuLB88nSpUPQ@mail.gmail.com>
<2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
Message-ID: <CAFdHCp7FeYn3q1L_v91fyfZy9NZ8j-YzWOuGzUFvKX2D93TEBQ@mail.gmail.com>

have captured packets from the phone

152.12 being my phone and 108.91 is the website.


seems to be the website is unable to reply to my TCP acks. there is not
HTTP between them two.

On 16 January 2013 18:30, Ryan Ratliff <rratliff at cisco.com> wrote:

> Either don't provide a Secure Service-URL or populate it, just use http://instead
of https://(and don't point to a secure port).
>
> -Ryan
>
> On Jan 16, 2013, at 1:02 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> how/where we can disable the HTTPS?
>
> On 16 January 2013 17:27, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> You've got HTTPS enabled so the phone is going to try that. Does your
>> CUCM have the certs for that site imported so TVS can authenticate the cert
>> the web server is going to pass down to the phone?
>>
>> -Ryan
>>
>> On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> sorry just confirmed, it does work from the web b.
>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
>> which means there is no issue with the firewall or DNS
>> *
>> On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:
>>
>>> not a firewall guy, but just wondering if i can access their main
>>> website http://www.andtek.com/communications-products-freexml.html
>>> and also i have checked nothing comes up when I go to the URL
>>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from
>>> web browers too (proxy disabled)*
>>>
>>>
>>> On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>>
>>>> Firewall isn't blocking anything is it?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>> I have added some XML services on the node but the phone goes into
>>>> Requesting when I hit the service in the phone.
>>>>
>>>>
>>>>
>>>> any ideas!!
>>>>
>>>> Thanks
>>>> --
>>>> @bbas..
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>>
>>> --
>>> @bbas..
>>>
>>
>>
>>
>> --
>> @bbas..
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/4810bda4/attachment.html>

From abbaseo at gmail.com Wed Jan 16 14:29:15 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 16 Jan 2013 19:29:15 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
<A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
<CAFdHCp7ZrCWqKT+Sa7dHWLdW_CF9S3_3i26oSjcuLB88nSpUPQ@mail.gmail.com>
<2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
Message-ID: <CAFdHCp5Lku2rfbKGY1ydn6c0jcJh2Er-DTcNT-7+Y_OibmA0DA@mail.gmail.com>

have captured packets from the phone

152.12 being my phone and 108.91 is the website.


seems to be the website is unable to reply to my TCP acks. there is not
HTTP between them two.

On 16 January 2013 18:30, Ryan Ratliff <rratliff at cisco.com> wrote:

> Either don't provide a Secure Service-URL or populate it, just use http://instead
of https://(and don't point to a secure port).
>
> -Ryan
>
> On Jan 16, 2013, at 1:02 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> how/where we can disable the HTTPS?
>
> On 16 January 2013 17:27, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> You've got HTTPS enabled so the phone is going to try that. Does your
>> CUCM have the certs for that site imported so TVS can authenticate the cert
>> the web server is going to pass down to the phone?
>>
>> -Ryan
>>
>> On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> sorry just confirmed, it does work from the web b.
>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
>> which means there is no issue with the firewall or DNS
>> *
>> On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:
>>
>>> not a firewall guy, but just wondering if i can access their main
>>> website http://www.andtek.com/communications-products-freexml.html
>>> and also i have checked nothing comes up when I go to the URL
>>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from
>>> web browers too (proxy disabled)*
>>>
>>>
>>> On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>>
>>>> Firewall isn't blocking anything is it?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>> I have added some XML services on the node but the phone goes into
>>>> Requesting when I hit the service in the phone.
>>>>
>>>>
>>>>
>>>> any ideas!!
>>>>
>>>> Thanks
>>>> --
>>>> @bbas..
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>>
>>> --
>>> @bbas..
>>>
>>
>>
>>
>> --
>> @bbas..
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/c6622f88/attachment.html>

From rratliff at cisco.com Wed Jan 16 16:00:43 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 16 Jan 2013 16:00:43 -0500
Subject: [cisco-voip] XML service not working
In-Reply-To: <CAFdHCp5Lku2rfbKGY1ydn6c0jcJh2Er-DTcNT-7+Y_OibmA0DA@mail.gmail.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
<A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
<CAFdHCp7ZrCWqKT+Sa7dHWLdW_CF9S3_3i26oSjcuLB88nSpUPQ@mail.gmail.com>
<2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
<CAFdHCp5Lku2rfbKGY1ydn6c0jcJh2Er-DTcNT-7+Y_OibmA0DA@mail.gmail.com>
Message-ID: <0C2BBE82-6AA7-4F5B-96CF-DA099AFF5075@cisco.com>

Do you see the TCP connection being established between the phone and web server?
Your highlighted packet is the phone resetting a question, not making a request or
even doing the tcp 3-way handshake.

-Ryan

On Jan 16, 2013, at 2:29 PM, abbas Wali <abbaseo at gmail.com> wrote:

have captured packets from the phone

152.12 being my phone and 108.91 is the website.


seems to be the website is unable to reply to my TCP acks. there is not HTTP
between them two.

On 16 January 2013 18:30, Ryan Ratliff <rratliff at cisco.com> wrote:


Either don't provide a Secure Service-URL or populate it, just use http:// instead
of https:// (and don't point to a secure port).

-Ryan

On Jan 16, 2013, at 1:02 PM, abbas Wali <abbaseo at gmail.com> wrote:
how/where we can disable the HTTPS?

On 16 January 2013 17:27, Ryan Ratliff <rratliff at cisco.com> wrote:


You've got HTTPS enabled so the phone is going to try that. Does your CUCM have
the certs for that site imported so TVS can authenticate the cert the web server is
going to pass down to the phone?

-Ryan

On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:

sorry just confirmed, it does work from the web b.


http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
which means there is no issue with the firewall or DNS

On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:


not a firewall guy, but just wondering if i can access their main website
http://www.andtek.com/communications-products-freexml.html
and also i have checked nothing comes up when I go to the URL
http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from web browers too
(proxy disabled)

On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com> wrote:


Firewall isn't blocking anything is it?

Sent from my iPad

On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:

> Folks,
>
> I have added some XML services on the node but the phone goes into Requesting
when I hit the service in the phone.
>
>
>
> any ideas!!
>
> Thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

--
@bbas..

--
@bbas..
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

--
@bbas..

--
@bbas..

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/6755d7ea/attachment.html>

From matthnick at gmail.com Wed Jan 16 16:20:14 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Wed, 16 Jan 2013 16:20:14 -0500
Subject: [cisco-voip] Mobility Issue
In-Reply-To: <CAL-DCK311DBY+OXP1EFgkaG6EC8Nxx=5=8qqV+pjCK4YqoHCJQ@mail.gmail.com>
References: <CAL-DCK0WQqJiKyFC0d81-4S8zjk5BU+mumsyK7Pk_qm1Vvzfcw@mail.gmail.com>
<-4286606911770185612@unknownmsgid>
<07980D5A-B85E-4C15-9970-3F1697C7BDB0@gmail.com>
<C63D5DCC-4316-4477-8A93-8775E089CEA0@cisco.com>
<CAL-DCK2pOUx1_-EvvABnLTrW-kAqQGgu_JNd0JbJJumCnDGk7w@mail.gmail.com>
<-5635080451137355987@unknownmsgid>
<CAL-DCK1vz8Wmk_3x+w-kVhHY=kM-Ad1GcaLUaPU3u1qBmeMmrw@mail.gmail.com>
<1680820783548761203@unknownmsgid>
<CAL-DCK0NHxrOgk4RM=CX_absw=Kc2+aqYLOzR-9Oc3_CGEvsEQ@mail.gmail.com>
<F51BAB8A-F89A-41A3-94DA-9B3D899D1C75@cisco.com>
<CAL-DCK1fBRyZqK+dZq08go_FaFXvGzuYwHU311vrWuLbe3XL-A@mail.gmail.com>
<AAA51FE5-3A02-44BA-844E-1BE005EA3ABD@cisco.com>
<CAL-DCK08ubjtxC2GDE6n+ORDBBP2P=j=D9P2L12=BBrgJrW7ww@mail.gmail.com>
<3F5FC5E5-D7C0-40D8-B0FE-FC15A24FC9F6@cisco.com>
<CAL-DCK0fuh79KenRe0P-SXGwC2xJj5+X4C-h_fM0Wx=+6m_mHg@mail.gmail.com>
<-510307317839395630@unknownmsgid>
<CAL-DCK1_Xf=vLu2S89WP3J7xRZ5-2qFB0pp6PgvycKHbQz-RTQ@mail.gmail.com>
<3988242485236118541@unknownmsgid>
<CAM-K-Nrh3mnOsMsKmHMTYS-Und-dGN6WFRhVu_mMFaW3U_BDkA@mail.gmail.com>
<8922406544240900299@unknownmsgid>
<CAL-DCK2imSoCU=ogmu+xOu8Ao4zRhqoR08KPLAbvuQPObCbO8A@mail.gmail.com>
<36E2F2EE-EE81-4D5C-BE8A-D3741F7CBD2A@cisco.com>
<CAL-DCK1L7JKvf_irpgf8W8su8v3T_VCHhrun4VhuGM7xz3TCag@mail.gmail.com>
<DD3CCA65-34A2-4EEA-ADA4-380F5CE35DE8@cisco.com>
<CAL-DCK3zTRk7JEpre_=fqtfnvwDxRuJq5Nns3P-eL2tSR29UzQ@mail.gmail.com>
<CAL-DCK311DBY+OXP1EFgkaG6EC8Nxx=5=8qqV+pjCK4YqoHCJQ@mail.gmail.com>
Message-ID: <CAM-K-NrYM9zL4Y+X40XuvAsrFU+KAKs6LEwi06E0qb+D0taLgA@mail.gmail.com>

Just for reference - you shouldn't need MTP for this call to work. However,
it's often a way to fix broken call flows. Most ITSP's also don't run on
Asterisks, which from my experience is used more often as a SMB IP PBX.
>From what I understand it's quite customizable, so their particular
settings for it may be interfering with MoH.

-nick
On Wed, Jan 16, 2013 at 1:56 PM, Dane Newman <dane.newman at gmail.com> wrote:

>
> All
>
> The issue has been resolved I believe (I feel very dumb)....Thank you so
> much all for your assistance!
>
> Ryan and Nick was 100% correct my MTP was not working correctly. I found
> that it was miss configured and in the default device pool instead of the
> correct one. Once I put it in the correct device pools I could hold calls
> and everything works correctly now.
> On Wed, Jan 16, 2013 at 1:27 PM, Dane Newman <dane.newman at gmail.com>wrote:
>
>> Ryan
>>
>> Thank you again for responding and sharing your wisdom.
>>
>> I am unsure if I am doing the test to verify your thoughts correctly but
>> I debugged the SIP messages once again. I placed a call and picked up the
>> call with and without the MTP checkbox checked on the SIP trunk in cucm.
>>
>> I then did a search for the IP address of my IP phone 10.1.10.18.
>>
>> In both debugs with and without it checked I found my IP phone's IP
>> address in the debug. I believe this might verify your idea that the MTP
>> is not working correctly?
>>
>> *With MTP unchecked on the SIP TRUNk*
>> *Jan 16 18:33:28.384: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> Received:
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK4e47f806d
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=673~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145612
>> To: <sip:17705439047 at 10.1.200.1>;tag=333141D8-1492
>> Date: Wed, 16 Jan 2013 18:11:29 GMT
>> Call-ID: 24e56400-f61ed51-12-a50010a at 10.1.80.10
>> Max-Forwards: 70
>> CSeq: 101 ACK
>> Allow-Events: presence, kpml
>> Content-Type: application/sdp
>> Content-Length: 230
>> v=0
>> o=CiscoSystemsCCM-SIP 673 1 IN IP4 10.1.80.10
>> s=SIP Call
>> c=IN IP4 10.1.10.18
>> b=TIAS:64000
>> b=AS:64
>> t=0 0
>> m=audio 20116 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=ptime:20
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>>
>> *With MTP checked on the SIP TRUNk*
>>
>> *Jan 16 18:39:09.732: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> Received:
>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK60b810f25
>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>> >;tag=723~d8eefedd-7473-4e00-a4a0-ce8f65d30766-31145637
>> To: <sip:17705439047 at 10.1.200.1>;tag=3336625C-1CBB
>> Date: Wed, 16 Jan 2013 18:17:05 GMT
>> Call-ID: ed2aec00-f61eea1-16-a50010a at 10.1.80.10
>> Max-Forwards: 70
>> CSeq: 101 ACK
>> Allow-Events: presence, kpml
>> Content-Type: application/sdp
>> Content-Length: 230
>> v=0
>> o=CiscoSystemsCCM-SIP 723 2 IN IP4 10.1.80.10
>> s=SIP Call
>> c=IN IP4 10.1.10.18
>> b=TIAS:64000
>> b=AS:64
>> t=0 0
>> m=audio 16452 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=ptime:20
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>>
>>
>>
>> On Wed, Jan 16, 2013 at 12:59 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>
>>> What they are doing is interpreting us sending them an Invite with
>>> a=inactive in the SDP as the Cisco phone putting them on hold. That is a
>>> valid assumption. What is incorrect (IMO) is them assuming that they need
>>> to generate MOH. CUCM is the one initiating the hold, it will be the one
>>> to play MOH or not, based upon the way you configure it. When they
>>> respond to our inactive SDP with one of their own, CUCM sees that as them
>>> putting us on hold. The end result you see is that in order to get the
>>> call off of hold both sides need to resume it, which isn't happening.
>>>
>>> I still think you need to look at an active call (no hold) on your CUBE
>>> to see where it's sending media to on the internal side. That IP address
>>> is going to be an MTP (CUCM server, hardware resource) or an IP phone. If
>>> it's directly to a phone you may as well remove "MTP Required" on the trunk
>>> because you're not actually allocating an MTP.
>>>
>>> -Ryan
>>>
>>> On Jan 16, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
>>>
>>> All
>>>
>>> Thank you for the infromation you are providing me on this thread. It
>>> is a great learning exp for me.
>>>
>>> I just got off the phone with the ITSP and they confirmed the MOH was
>>> coming from them. They believe if I am typing this correctly they
>>> (ITSP) claim when I press the hold button I am sending an invite message
>>> and that is resulting in the MOH being played by them.
>>>
>>> I assumed when I pressed the hold key on an external call CUCM would
>>> continue to send the uninterupted audio stream with the MOH mixed in?
>>>
>>> I have reset the trunk and rebooted cucm also...
>>>
>>> Thanks again for the assistance and advice it's much appericated
>>>
>>> Dane
>>>
>>>
>>>
>>> On Wed, Jan 16, 2013 at 12:18 PM, Ryan Ratliff <rratliff at cisco.com>wrote:
>>>
>>>> Having the MOH servers registered is step 1 of about 10 that have to
>>>> happen for MOH to be allocated for the call.
>>>> In the SIP signaling you sent there was no possibility you heard MOH
>>>> from CUCM because the media stream never went back to active after the
>>>> hold. Can your Asterix play MOH?
>>>>
>>>> You need to look at ccm traces to debug this further. If you can't
>>>> figure it out, then it's time to call TAC.
>>>>
>>>> You should also take a look at your active call before it's getting put
>>>> on hold. You've got MTP Required set on the SIP trunk, but if an MTP was
>>>> really getting allocated I don't believe we'd ever set the media inactive
>>>> to the trunk, we'd be telling the MTP about media changes and the trunk
>>>> would just see one media stream to the MTP for the entire call. At the
>>>> same time if we tried to allocate an MTP but failed, that usually ends up
>>>> disabling supplementary services for the call, which means you never would
>>>> have been allowed to hold in the first place. It's certainly possible
>>>> that has changed for SIP EO MTPs but for now what is in that signaling
>>>> doesn't jive with what you've sent in your config and description of
>>>> events.
>>>>
>>>> Have you tried resetting the SIP trunk in CUCM yet?
>>>>
>>>> -Ryan
>>>>
>>>> On Jan 16, 2013, at 11:26 AM, Dane Newman <dane.newman at gmail.com>
>>>> wrote:
>>>>
>>>> Yes as per the screen shot the MOH servers are registered. How do In
>>>> find the audio bit rate? its just the default moh file I didnt change any
>>>> settings
>>>>
>>>> On Wed, Jan 16, 2013 at 10:20 AM, Kenneth Hayes <
>>>> kennethwhayes at gmail.com> wrote:
>>>>
>>>>> So have you looked in your media resources under music on hold server
>>>>> configurations to make sure it's registered to the right UCM? Also what
>>>>> audio bit rate is your MOH file?
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Jan 16, 2013, at 10:14 AM, Nick Matthews <matthnick at gmail.com>
>>>>> wrote:
>>>>>
>>>>> I'm not sure at this point, I'll let some of the CUCM experts comment.
>>>>> It's possible during the hold conversation CUCM always sends delayed offer,
>>>>> but I don't have some good traces in front of me to confirm.
>>>>>
>>>>> You can check the original invite CUCM sends to see if there's SDP in
>>>>> that, and it would confirm the MTP is being allocated. If it's sending the
>>>>> INVITE without SDP, your MRG/MRGL or resources are misconfigured or in use.
>>>>>
>>>>> -nick
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 8:39 PM, Dane Newman <dane.newman at gmail.com>wrote:
>>>>>
>>>>>> Nick
>>>>>>
>>>>>> Thanks for the assistance.
>>>>>>
>>>>>> This is the first time I am setting up a direct sip connection from
>>>>>> cucm to cube. I am used to making it an h323 connection. Attached are
>>>>>> screen shots of my trunk setup. MTP is checked off I believe already.
>>>>>> Is there a best way to go about troubleshooting cucm to figure out why its
>>>>>> not setting the stream back to active?
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 7:56 PM, Nick Matthews <matthnick at
gmail.com>wrote:
>>>>>>
>>>>>>> It looks like CUCM isn't setting the stream back to active after
>>>>>>> putting it on hold. It sends the re-invite, and the 200 OK from the ITSP
>>>>>>> has the SDP continued with a=inactive.
>>>>>>>
>>>>>>> I don't have some good traces in front of me, but somewhere it needs
>>>>>>> to take that off. I don't think Asterisks is acting incorrectly by
>>>>>>> responding to a delayed offer INVITE that was previously a=inactive with
>>>>>>> a=inactive.
>>>>>>>
>>>>>>> What's also odd is that CUCM is sending the exact same INVITE after
>>>>>>> the first one completes, for both the hold and the resume. The CSeq isn't
>>>>>>> increasing, which I would expect it to.
>>>>>>>
>>>>>>> If you were to check 'MTP' required it may work around the problem,
>>>>>>> but I don't consider inserting MTP's to be a best practice.
>>>>>>>
>>>>>>> -nick
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 3:42 PM, Kenneth Hayes <
>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>
>>>>>>>> Bind your media and source to your outbound interface on your voice
>>>>>>>> service voip.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Below is a show run from the router
>>>>>>>>
>>>>>>>>
>>>>>>>> [OK]
>>>>>>>> Cisco3825#sh run
>>>>>>>> Building configuration...
>>>>>>>>
>>>>>>>> Current configuration : 10183 bytes
>>>>>>>> !
>>>>>>>> ! Last configuration change at 20:49:24 UTC Tue Jan 15 2013 by
>>>>>>>> dnewman
>>>>>>>> version 15.1
>>>>>>>> service timestamps debug datetime msec
>>>>>>>> service timestamps log datetime msec
>>>>>>>> no service password-encryption
>>>>>>>> !
>>>>>>>> hostname Cisco3825
>>>>>>>> !
>>>>>>>> boot-start-marker
>>>>>>>> boot-end-marker
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> aaa new-model
>>>>>>>> !
>>>>>>>> !
>>>>>>>> aaa authentication login default local
>>>>>>>> aaa authentication login vpnauth local
>>>>>>>> aaa authorization exec default local
>>>>>>>> aaa authorization network default local
>>>>>>>> aaa authorization network vpnauth local
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> aaa session-id common
>>>>>>>> !
>>>>>>>> no network-clock-participate wic 0
>>>>>>>> !
>>>>>>>> dot11 syslog
>>>>>>>> ip source-route
>>>>>>>> !
>>>>>>>> ip cef
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> ip domain name datasc.local
>>>>>>>> ip inspect udp idle-time 1800
>>>>>>>> no ipv6 cef
>>>>>>>> !
>>>>>>>> multilink bundle-name authenticated
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> voice-card 0
>>>>>>>> dsp services dspfarm
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> voice service voip
>>>>>>>> ip address trusted list
>>>>>>>> ipv4 64.154.41.150 255.255.255.255
>>>>>>>> allow-connections sip to sip
>>>>>>>> fax protocol pass-through g711ulaw
>>>>>>>> sip
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> voice translation-rule 1
>>>>>>>> rule 1 /6784604564/ /200/
>>>>>>>> rule 2 /6784563290/ /100/
>>>>>>>> rule 3 /6784563291/ /101/
>>>>>>>> rule 4 /6784563292/ /102/
>>>>>>>> rule 5 /6784563293/ /103/
>>>>>>>> rule 6 /6784563294/ /104/
>>>>>>>> rule 7 /6784563295/ /105/
>>>>>>>> rule 8 /6784563296/ /106/
>>>>>>>> rule 9 /6784563297/ /107/
>>>>>>>> rule 10 /6784563298/ /108/
>>>>>>>> rule 11 /6784563299/ /109/
>>>>>>>> rule 12 /6784604565/ /125/
>>>>>>>> !
>>>>>>>> !
>>>>>>>> voice translation-profile incomingdid
>>>>>>>> translate called 1
>>>>>>>> !
>>>>>>>> !
>>>>>>>> crypto pki token default removal timeout 0
>>>>>>>> !
>>>>>>>> crypto pki trustpoint selfsigned
>>>>>>>> enrollment selfsigned
>>>>>>>> subject-name CN=connect.datasc.com
>>>>>>>> revocation-check crl
>>>>>>>> !
>>>>>>>> !
>>>>>>>> crypto pki certificate chain selfsigned
>>>>>>>> certificate self-signed 02
>>>>>>>> 30820251 308201BA A0030201 02020102 300D0609 2A864886 F70D0101
>>>>>>>> 05050030
>>>>>>>> 44311B30 19060355 04031312 636F6E6E 6563742E 64617461 73632E63
>>>>>>>> 6F6D3125
>>>>>>>> 30230609 2A864886 F70D0109 02161643 6973636F 33383235 2E646174
>>>>>>>> 6173632E
>>>>>>>> 6C6F6361 6C301E17 0D313231 32323831 39313531 395A170D 32303031
>>>>>>>> 30313030
>>>>>>>> 30303030 5A304431 1B301906 03550403 1312636F 6E6E6563 742E6461
>>>>>>>> 74617363
>>>>>>>> 2E636F6D 31253023 06092A86 4886F70D 01090216 16436973 636F3338
>>>>>>>> 32352E64
>>>>>>>> 61746173 632E6C6F 63616C30 819F300D 06092A86 4886F70D 01010105
>>>>>>>> 0003818D
>>>>>>>> 00308189 02818100 D9A99B41 8B70C82F 28072967 376E13E8 8F7FC2C2
>>>>>>>> 7729B93E
>>>>>>>> DDAE31A0 F3613381 78B43E11 5144BE88 DC2FDE14 0035A104 0BBFAEA0
>>>>>>>> 9A190598
>>>>>>>> 19A124B1 2C4A8EA2 04253BA1 C829EF07 CD0E848D E7AA5269 459449C4
>>>>>>>> FABF9CA9
>>>>>>>> BC5AF8ED 84FCD99B 260C2B75 57887863 7BB310FB 2C8D1506 FE91FEAC
>>>>>>>> 4EDD1712
>>>>>>>> A7AFD2C1 BF21C59D 02030100 01A35330 51300F06 03551D13 0101FF04
>>>>>>>> 05300301
>>>>>>>> 01FF301F 0603551D 23041830 16801475 02C4FB04 4FB3F748 B4012EC5
>>>>>>>> 8A571236
>>>>>>>> A190CB30 1D060355 1D0E0416 04147502 C4FB044F B3F748B4 012EC58A
>>>>>>>> 571236A1
>>>>>>>> 90CB300D 06092A86 4886F70D 01010505 00038181 00C2B167 E583F6D8
>>>>>>>> 8B742D4F
>>>>>>>> 49D27AAD 7EF4E64F 0B5CA5A3 944E8CC7 499A706F AB22283B AE5913A1
>>>>>>>> B22BBB20
>>>>>>>> E7CF6F9F 41CDD870 1B474E58 9537C1FA 2D93BE4F 4276E9CE 61AE18D3
>>>>>>>> EF724BD9
>>>>>>>> 33878860 4B3627C0 448C652D 03D4C142 BA3291A3 DDE0C4DD C6ED06C3
>>>>>>>> 12E45933
>>>>>>>> F1EE5CC2 B5B6CC20 C65AB313 76966F14 AA25CC8D 2A
>>>>>>>> quit
>>>>>>>> !
>>>>>>>> !
>>>>>>>> license udi pid CISCO3825 sn FTX1237A1T0
>>>>>>>> username xxxxxxx privilege 15 secret xxxxxx
>>>>>>>> !
>>>>>>>> redundancy
>>>>>>>> !
>>>>>>>> !
>>>>>>>> controller T1 0/0/0
>>>>>>>> !
>>>>>>>> controller T1 0/0/1
>>>>>>>> !
>>>>>>>> ip ssh version 2
>>>>>>>> !
>>>>>>>> !
>>>>>>>> crypto isakmp policy 10
>>>>>>>> encr aes
>>>>>>>> authentication pre-share
>>>>>>>> group 2
>>>>>>>> crypto isakmp key Recoil90 address 0.0.0.0 0.0.0.0
>>>>>>>> crypto isakmp fragmentation
>>>>>>>> !
>>>>>>>> crypto isakmp client configuration group datasc
>>>>>>>> key Recoil90
>>>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>>>> domain datasc.local
>>>>>>>> pool vpnpool
>>>>>>>> save-password
>>>>>>>> !
>>>>>>>> crypto isakmp client configuration group datascsplit
>>>>>>>> key Recoil90
>>>>>>>> dns 4.2.2.2 4.2.2.1
>>>>>>>> domain datasc.local
>>>>>>>> pool vpnpool
>>>>>>>> acl 101
>>>>>>>> save-password
>>>>>>>> crypto isakmp profile datasc
>>>>>>>> match identity group datasc
>>>>>>>> client authentication list vpnauth
>>>>>>>> isakmp authorization list vpnauth
>>>>>>>> client configuration address respond
>>>>>>>> virtual-template 1
>>>>>>>> crypto isakmp profile datascsplit
>>>>>>>> match identity group datascsplit
>>>>>>>> client authentication list vpnauth
>>>>>>>> isakmp authorization list vpnauth
>>>>>>>> client configuration address respond
>>>>>>>> virtual-template 2
>>>>>>>> !
>>>>>>>> !
>>>>>>>> crypto ipsec transform-set transformset esp-aes
>>>>>>>> crypto ipsec transform-set ezvpntransform esp-aes esp-sha-hmac
>>>>>>>> !
>>>>>>>> crypto ipsec profile VTI
>>>>>>>> set transform-set ezvpntransform
>>>>>>>> set isakmp-profile datasc
>>>>>>>> !
>>>>>>>> crypto ipsec profile VTI2
>>>>>>>> set transform-set ezvpntransform
>>>>>>>> set isakmp-profile datascsplit
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> interface Loopback1
>>>>>>>> ip address 10.1.150.1 255.255.255.0
>>>>>>>> ip nat inside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> !
>>>>>>>> interface GigabitEthernet0/0
>>>>>>>> ip address dhcp
>>>>>>>> no ip redirects
>>>>>>>> no ip unreachables
>>>>>>>> no ip proxy-arp
>>>>>>>> ip nat outside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> duplex auto
>>>>>>>> speed auto
>>>>>>>> media-type rj45
>>>>>>>> hold-queue 240000 in
>>>>>>>> !
>>>>>>>> interface GigabitEthernet0/1
>>>>>>>> ip address 10.1.200.1 255.255.255.252
>>>>>>>> ip nat inside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> duplex auto
>>>>>>>> speed auto
>>>>>>>> media-type rj45
>>>>>>>> !
>>>>>>>> interface Virtual-Template1 type tunnel
>>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>>> ip nat inside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> tunnel source GigabitEthernet0/0
>>>>>>>> tunnel mode ipsec ipv4
>>>>>>>> tunnel protection ipsec profile VTI
>>>>>>>> !
>>>>>>>> interface Virtual-Template2 type tunnel
>>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>>> ip nat inside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> tunnel source GigabitEthernet0/0
>>>>>>>> tunnel mode ipsec ipv4
>>>>>>>> tunnel protection ipsec profile VTI2
>>>>>>>> !
>>>>>>>> interface Virtual-Template3
>>>>>>>> ip unnumbered GigabitEthernet0/0
>>>>>>>> ip nat outside
>>>>>>>> ip virtual-reassembly in
>>>>>>>> ip policy route-map anyconnecthop
>>>>>>>> !
>>>>>>>> !
>>>>>>>> router eigrp 1
>>>>>>>> maximum-paths 1
>>>>>>>> network 10.0.0.0
>>>>>>>> redistribute static
>>>>>>>> !
>>>>>>>> ip local pool vpnpool 10.1.100.10 10.1.100.200
>>>>>>>> ip forward-protocol nd
>>>>>>>> ip http server
>>>>>>>> ip http secure-server
>>>>>>>> !
>>>>>>>> !
>>>>>>>> ip nat inside source list NATNETWORKS interface GigabitEthernet0/0
>>>>>>>> overload
>>>>>>>> ip nat inside source static tcp 10.1.50.150 80 interface
>>>>>>>> GigabitEthernet0/0 80
>>>>>>>> ip nat inside source static tcp 10.1.80.100 5001 interface
>>>>>>>> GigabitEthernet0/0 5001
>>>>>>>> ip nat inside source static udp 10.1.80.100 5001 interface
>>>>>>>> GigabitEthernet0/0 5001
>>>>>>>> !
>>>>>>>> ip access-list extended NATNETWORKS
>>>>>>>> deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
>>>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>>>> ip access-list extended anyconnecthop
>>>>>>>> deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
>>>>>>>> permit ip 10.0.0.0 0.255.255.255 any
>>>>>>>> !
>>>>>>>> access-list 50 permit 10.0.0.0 0.255.255.255
>>>>>>>> access-list 101 permit ip 10.0.0.0 0.255.255.255 any
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> route-map anyconnecthop permit 10
>>>>>>>> match ip address anyconnecthop
>>>>>>>> set ip next-hop 10.1.150.2
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> control-plane
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> mgcp profile default
>>>>>>>> !
>>>>>>>> !
>>>>>>>> dial-peer voice 100 voip
>>>>>>>> description Publisher
>>>>>>>> preference 1
>>>>>>>> destination-pattern 1..
>>>>>>>> session protocol sipv2
>>>>>>>> session target ipv4:10.1.80.10
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 101 voip
>>>>>>>> description Subscriber
>>>>>>>> preference 2
>>>>>>>> destination-pattern 1..
>>>>>>>> session target ipv4:10.1.80.11
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 200 voip
>>>>>>>> description Publisher
>>>>>>>> preference 1
>>>>>>>> destination-pattern 2..
>>>>>>>> progress_ind setup enable 3
>>>>>>>> progress_ind progress enable 8
>>>>>>>> session protocol sipv2
>>>>>>>> session target ipv4:10.1.80.10
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 300 voip
>>>>>>>> description incoming Calldid
>>>>>>>> translation-profile incoming incomingdid
>>>>>>>> preference 1
>>>>>>>> session protocol sipv2
>>>>>>>> session target sip-server
>>>>>>>> incoming called-number 678456329.
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 301 voip
>>>>>>>> description incoming Calldid
>>>>>>>> translation-profile incoming incomingdid
>>>>>>>> preference 1
>>>>>>>> session protocol sipv2
>>>>>>>> session target sip-server
>>>>>>>> incoming called-number 6784604565
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 302 voip
>>>>>>>> description incoming Calldid
>>>>>>>> translation-profile incoming incomingdid
>>>>>>>> preference 1
>>>>>>>> session protocol sipv2
>>>>>>>> session target sip-server
>>>>>>>> incoming called-number 6784604564
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 201 voip
>>>>>>>> description Publisher
>>>>>>>> preference 2
>>>>>>>> destination-pattern 2..
>>>>>>>> progress_ind setup enable 3
>>>>>>>> progress_ind progress enable 8
>>>>>>>> session protocol sipv2
>>>>>>>> session target ipv4:10.1.80.11
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> dial-peer voice 500 voip
>>>>>>>> description outgoing
>>>>>>>> preference 1
>>>>>>>> destination-pattern .T
>>>>>>>> session protocol sipv2
>>>>>>>> session target dns:sip.talkinip.net
>>>>>>>> dtmf-relay rtp-nte
>>>>>>>> codec g711ulaw
>>>>>>>> !
>>>>>>>> !
>>>>>>>> sip-ua
>>>>>>>> credentials username xxxxxxxx password 7 xxxxxxx realm
>>>>>>>> sipconnect.ipcomms.net
>>>>>>>> authentication username xxxxxx password 7 xxxxxxx
>>>>>>>> authentication username xxxxx password 7 xxxxxxx realm
>>>>>>>> sipconnect.ipcomms.net
>>>>>>>> set pstn-cause 3 sip-status 486
>>>>>>>> set pstn-cause 34 sip-status 486
>>>>>>>> set pstn-cause 47 sip-status 486
>>>>>>>> registrar dns:sipconnect.ipcomms.net expires 60
>>>>>>>> sip-server dns:sipconnect.ipcomms.net:5060
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> gatekeeper
>>>>>>>> shutdown
>>>>>>>> !
>>>>>>>> !
>>>>>>>> call-manager-fallback
>>>>>>>> max-conferences 8 gain -6
>>>>>>>> transfer-system full-consult
>>>>>>>> ip source-address 10.1.200.1 port 2000
>>>>>>>> max-ephones 20
>>>>>>>> max-dn 40
>>>>>>>> !
>>>>>>>> !
>>>>>>>> !
>>>>>>>> line con 0
>>>>>>>> line aux 0
>>>>>>>> line vty 0 4
>>>>>>>> privilege level 15
>>>>>>>> transport input ssh
>>>>>>>> line vty 5 15
>>>>>>>> privilege level 15
>>>>>>>> transport input ssh
>>>>>>>> !
>>>>>>>> scheduler allocate 20000 1000
>>>>>>>> !
>>>>>>>> webvpn gateway gateway_1
>>>>>>>> ip interface GigabitEthernet0/0 port 443
>>>>>>>> ssl trustpoint selfsigned
>>>>>>>> inservice
>>>>>>>> !
>>>>>>>> webvpn install svc flash:/webvpn/anyconnect-win-3.1.02026-k9.pkg
>>>>>>>> sequence 1
>>>>>>>> !
>>>>>>>> webvpn context datasc
>>>>>>>> title "DataSC VPN"
>>>>>>>> secondary-color white
>>>>>>>> title-color #CCCC66
>>>>>>>> text-color black
>>>>>>>> ssl authenticate verify all
>>>>>>>> !
>>>>>>>> url-list "Servers"
>>>>>>>> heading "Server"
>>>>>>>> !
>>>>>>>> !
>>>>>>>> policy group datasc
>>>>>>>> url-list "Servers"
>>>>>>>> functions svc-enabled
>>>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>>>> svc keep-client-installed
>>>>>>>> svc dns-server primary 4.2.2.2
>>>>>>>> svc dtls
>>>>>>>> virtual-template 3
>>>>>>>> default-group-policy datasc
>>>>>>>> aaa authentication list vpnauth
>>>>>>>> gateway gateway_1 domain datasc
>>>>>>>> inservice
>>>>>>>> !
>>>>>>>> !
>>>>>>>> webvpn context datascsplit
>>>>>>>> title "DataSC VPN Split"
>>>>>>>> secondary-color white
>>>>>>>> title-color #CCCC66
>>>>>>>> text-color black
>>>>>>>> ssl authenticate verify all
>>>>>>>> !
>>>>>>>> url-list "Servers"
>>>>>>>> heading "Server"
>>>>>>>> !
>>>>>>>> !
>>>>>>>> policy group datascsplit
>>>>>>>> url-list "Servers"
>>>>>>>> functions svc-enabled
>>>>>>>> svc address-pool "vpnpool" netmask 255.255.255.0
>>>>>>>> svc split include acl 50
>>>>>>>> svc dns-server primary 4.2.2.2
>>>>>>>> svc dtls
>>>>>>>> default-group-policy datascsplit
>>>>>>>> aaa authentication list vpnauth
>>>>>>>> gateway gateway_1 domain datascsplit
>>>>>>>> inservice
>>>>>>>> !
>>>>>>>> end
>>>>>>>> Cisco3825#
>>>>>>>>
>>>>>>>> On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <
>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> What do your media resources look like?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also can you show me a copy of your voice service voip config?
>>>>>>>>>
>>>>>>>>> Sent from my iPad
>>>>>>>>>
>>>>>>>>> On Jan 15, 2013, at 3:12 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Thanks Ryan
>>>>>>>>>
>>>>>>>>> I see I am always getting a 200 ok message after my invites from
>>>>>>>>> the debug
>>>>>>>>>
>>>>>>>>> *Putting a call on HOLD*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>>
>>>>>>>>> CSeq: 102 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>>
>>>>>>>>> Supported: Geolocation
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 240
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsCCM-SIP 7322 3 IN IP4 10.1.80.10
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>>
>>>>>>>>> b=TIAS:64000
>>>>>>>>>
>>>>>>>>> b=AS:64
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-15
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.094: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK691F12E0
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Timestamp: 1358281168
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 289
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2739 IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19458 RTP/AVP 0 101 19
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-15
>>>>>>>>>
>>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.094: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 102 INVITE
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.110: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK691F12E0;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 239
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=root 1685873050 1685873052 IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 13014 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.118: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK2891b89f8fa
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 102 INVITE
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>>
>>>>>>>>> Supported: replaces
>>>>>>>>>
>>>>>>>>> Supported: sdp-anat
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Supported: timer
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 253
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5479 IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19514 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.118: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK6920266D
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 103 ACK
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28b4b1305a0
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 102 ACK
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.122: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>>
>>>>>>>>> Supported: Geolocation
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060;transport=tcp>;video
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.126: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69211AB3
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Timestamp: 1358281168
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.126: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.146: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69211AB3;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 333
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=root 1685873050 1685873053 IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.150: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28c43b47e7e
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 103 INVITE
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>>
>>>>>>>>> Supported: replaces
>>>>>>>>>
>>>>>>>>> Supported: sdp-anat
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Supported: timer
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 277
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5480 IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.162: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28d3eadaab3
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 103 ACK
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 209
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsCCM-SIP 7322 4 IN IP4 10.1.80.10
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>>
>>>>>>>>> b=TIAS:64000
>>>>>>>>>
>>>>>>>>> b=AS:64
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 21476 RTP/AVP 0
>>>>>>>>>
>>>>>>>>> a=X-cisco-media:nomedia
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:28.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK692226EA
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:28 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 104 ACK
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 251
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2740 IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> c=IN IP4 0.0.0.0
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Unholding the call the MOH continues on the previously held
>>>>>>>>> caller while the user hears nothing*
>>>>>>>>>
>>>>>>>>> **
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.166: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>>
>>>>>>>>> Supported: Geolocation
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Timestamp: 1358281175
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 333
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>>
>>>>>>>>> Supported: replaces
>>>>>>>>>
>>>>>>>>> Supported: sdp-anat
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Supported: timer
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 277
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 104 ACK
>>>>>>>>>
>>>>>>>>> Allow-Events: presence, kpml
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 243
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>>>
>>>>>>>>> b=TIAS:64000
>>>>>>>>>
>>>>>>>>> b=AS:64
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-15
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 105 ACK
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 265
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-CUCM8.6
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>>>>>>> REFER, SUBSCRIBE, NOTIFY
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: presence
>>>>>>>>>
>>>>>>>>> Supported: X-cisco-srtp-fallback
>>>>>>>>>
>>>>>>>>> Supported: Geolocation
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> P-Asserted-Identity: "Dane Newman" <sip:6784563290 at 10.1.80.10>
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;party=calling;screen=yes;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 10.1.80.10:5060
>>>>>>>>> ;transport=tcp>;video;audio;video
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.170: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> INVITE sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69232672
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Supported: timer,resource-priority,replaces,sdp-anat
>>>>>>>>>
>>>>>>>>> Min-SE: 1800
>>>>>>>>>
>>>>>>>>> Cisco-Guid: 3257897472-0000065536-0000000035-0173015306
>>>>>>>>>
>>>>>>>>> User-Agent: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> Timestamp: 1358281175
>>>>>>>>>
>>>>>>>>> Contact: <sip:6784563290 at 98.192.104.214:5060>
>>>>>>>>>
>>>>>>>>> Expires: 180
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.190: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 100 Trying
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Length: 0
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.194: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060
>>>>>>>>> ;branch=z9hG4bK69232672;received=98.192.104.214
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> CSeq: 105 INVITE
>>>>>>>>>
>>>>>>>>> Server: Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>>>>>>>> NOTIFY, INFO
>>>>>>>>>
>>>>>>>>> Supported: replaces, timer
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 64.154.41.150>
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 333
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=root 1685873050 1685873054 IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> s=Asterisk PBX 1.6.2.13
>>>>>>>>>
>>>>>>>>> c=IN IP4 64.154.41.150
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 13014 RTP/AVP 3 8 0 18 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:3 GSM/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:18 G729/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:18 annexb=no
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.198: //14122/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> SIP/2.0 200 OK
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28e6157f41c
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> CSeq: 104 INVITE
>>>>>>>>>
>>>>>>>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>>>>>>> SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Remote-Party-ID: <sip:17705439047 at 10.1.200.1
>>>>>>>>> >;party=called;screen=no;privacy=off
>>>>>>>>>
>>>>>>>>> Contact: <sip:17705439047 at 10.1.200.1:5060;transport=tcp>
>>>>>>>>>
>>>>>>>>> Supported: replaces
>>>>>>>>>
>>>>>>>>> Supported: sdp-anat
>>>>>>>>>
>>>>>>>>> Server: Cisco-SIPGateway/IOS-12.x
>>>>>>>>>
>>>>>>>>> Session-Expires: 1800;refresher=uas
>>>>>>>>>
>>>>>>>>> Require: timer
>>>>>>>>>
>>>>>>>>> Supported: timer
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 277
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 4444 5481 IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19514 RTP/AVP 0 101 19
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.200.1
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=rtpmap:19 CN/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.206: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Received:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 10.1.200.1:5060;transport=tcp SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/TCP 10.1.80.10:5060;branch=z9hG4bK28f6dca6616
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at 10.1.80.10
>>>>>>>>> >;tag=7322~d8eefedd-7473-4e00-a4a0-ce8f65d30766-30500957
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at 10.1.200.1>;tag=2E6BC6F0-1E22
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 19:57:42 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: c22f9200-f51b49d-c5-a50010a at 10.1.80.10
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 104 ACK
>>>>>>>>>
>>>>>>>>> Allow-Events: presence, kpml
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 243
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 10.1.10.18
>>>>>>>>>
>>>>>>>>> b=TIAS:64000
>>>>>>>>>
>>>>>>>>> b=AS:64
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 21476 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-15
>>>>>>>>>
>>>>>>>>> *Jan 15 20:19:35.210: //14124/C22F92000000/SIP/Msg/ccsipDisplayMsg:
>>>>>>>>>
>>>>>>>>> Sent:
>>>>>>>>>
>>>>>>>>> ACK sip:17705439047 at 64.154.41.150:5060 SIP/2.0
>>>>>>>>>
>>>>>>>>> Via: SIP/2.0/UDP 98.192.104.214:5060;branch=z9hG4bK69246AB
>>>>>>>>>
>>>>>>>>> From: "Dane Newman" <sip:6784563290 at sipconnect.ipcomms.net
>>>>>>>>> >;tag=2E6BC0B0-2268
>>>>>>>>>
>>>>>>>>> To: <sip:17705439047 at sip.talkinip.net>;tag=as7c5ff82e
>>>>>>>>>
>>>>>>>>> Date: Tue, 15 Jan 2013 20:19:35 GMT
>>>>>>>>>
>>>>>>>>> Call-ID: A750328E-5E8711E2-8DC8A5CA-19425D52 at 98.192.104.214
>>>>>>>>>
>>>>>>>>> Max-Forwards: 70
>>>>>>>>>
>>>>>>>>> CSeq: 105 ACK
>>>>>>>>>
>>>>>>>>> Authorization: Digest username="6784563290",realm="asterisk",uri="
>>>>>>>>> sip:17705439047 at 64.154.41.150:5060
>>>>>>>>>
",response="0f6bb4f824d35b7315056c24e36a8709",nonce="206b7665",algorithm=MD5
>>>>>>>>>
>>>>>>>>> Allow-Events: telephone-event
>>>>>>>>>
>>>>>>>>> Content-Type: application/sdp
>>>>>>>>>
>>>>>>>>> Content-Length: 265
>>>>>>>>>
>>>>>>>>> v=0
>>>>>>>>>
>>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 3168 2741 IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> s=SIP Call
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> t=0 0
>>>>>>>>>
>>>>>>>>> m=audio 19458 RTP/AVP 0 101
>>>>>>>>>
>>>>>>>>> c=IN IP4 98.192.104.214
>>>>>>>>>
>>>>>>>>> a=inactive
>>>>>>>>>
>>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>>>
>>>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>>>>
>>>>>>>>> a=fmtp:101 0-16
>>>>>>>>>
>>>>>>>>> a=ptime:20
>>>>>>>>>
>>>>>>>>> Cisco3825#
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 15, 2013 at 2:28 PM, Ryan Ratliff <rratliff at
cisco.com>wrote:
>>>>>>>>>
>>>>>>>>>> ccsip message is what I'd go with just to see the signaling with
>>>>>>>>>> no other stuff. Depending on what that shows and what your gateway is
>>>>>>>>>> doing to the signals you may need to expand from there.
>>>>>>>>>>
>>>>>>>>>> -Ryan
>>>>>>>>>>
>>>>>>>>>> On Jan 15, 2013, at 2:11 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Ryan
>>>>>>>>>>
>>>>>>>>>> What is the proper debug to use to caputre the useful information?
>>>>>>>>>>
>>>>>>>>>> Dane
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 15, 2013 at 12:42 PM, Ryan Ratliff <
>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Without sip messages I can't get any clues from that.
>>>>>>>>>>>
>>>>>>>>>>> -Ryan
>>>>>>>>>>>
>>>>>>>>>>> On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks Ryan for the input
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *On the call when I hold the call the following debug pops
>>>>>>>>>>> out....*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Jan 15 17:56:05.246:
>>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>>> passthru hdrs to
>>>>>>>>>>> container
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> SIP: (13938) Group (a= group line) attribute, level 65535
>>>>>>>>>>> instance 1 not found.
>>>>>>>>>>> *Jan 15 17:56:05.274:
>>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>>> passthru headers to
>>>>>>>>>>> container
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>>> instance 1 not found.
>>>>>>>>>>> *Jan 15 17:56:05.286:
>>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>>> passthru hdrs to
>>>>>>>>>>> container
>>>>>>>>>>> *Jan 15 17:56:05.302:
>>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>>> passthru headers to
>>>>>>>>>>> container
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>>> instance 1 not found.
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> *Jan 15 17:56:05.322:
>>>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>>>> params for midcall INVITE
>>>>>>>>>>>
>>>>>>>>>>> *After I try to unhold the call the following debug comes
>>>>>>>>>>> out....*
>>>>>>>>>>> **
>>>>>>>>>>>
>>>>>>>>>>> *Jan 15 17:56:18.874:
>>>>>>>>>>> //13939/922252E78D73/SIP/Error/ccsip_api_request_offer: Unable to add
>>>>>>>>>>> passthru hdrs to
>>>>>>>>>>> container
>>>>>>>>>>> *Jan 15 17:56:18.894:
>>>>>>>>>>> //13938/922252E78D73/SIP/Error/ccsip_api_response_answer: Unable to add
>>>>>>>>>>> passthru headers to
>>>>>>>>>>> container
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> SIP: (13939) Group (a= group line) attribute, level 65535
>>>>>>>>>>> instance 1 not found.
>>>>>>>>>>> SIP: Attribute mid, level 1 instance 1 not found.
>>>>>>>>>>> *Jan 15 17:56:18.906:
>>>>>>>>>>> //13939/922252E78D73/SIP/Error/sipSPIProcessAckMedia: Could not modify
QoS
>>>>>>>>>>> params for midcall INVITE
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 15, 2013 at 9:42 AM, Ryan Ratliff <
>>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Given you have an ITSP it's most likely the initial hold that's
>>>>>>>>>>>> failing, which is only manifesting when you try to resume it. If you
>>>>>>>>>>>> haven't noticed already this is also very likely causing transfers to
fail.
>>>>>>>>>>>>
>>>>>>>>>>>> Take a look at the SIP signaling for a call. I believe the
>>>>>>>>>>>> most common cause to this is the ITSP not handling our transition from
>>>>>>>>>>>> active->inactive->sendonly->active from hold to MOH to resume. The
>>>>>>>>>>>> "Duplex Streaming Enabled" parameter is there just for this type of
problem.
>>>>>>>>>>>>
>>>>>>>>>>>> -Ryan
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 14, 2013, at 6:40 PM, Dane Newman <dane.newman at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> *Hello Kenneth*
>>>>>>>>>>>> **
>>>>>>>>>>>> *I have restarted both CUCM servers so this should have
>>>>>>>>>>>> restarted the services when the utils system restart happened*
>>>>>>>>>>>> **
>>>>>>>>>>>>
>>>>>>>>>>>> *on my router I see I am using g711 from the debug *
>>>>>>>>>>>> **
>>>>>>>>>>>> *I ran a debug voip ccapi inout *
>>>>>>>>>>>> **
>>>>>>>>>>>> *I connected a call calling from an external number to a DiD
>>>>>>>>>>>> inside of my system. Once the call was connected I put the call on
hold
>>>>>>>>>>>> and the following debug came out..the music on hold played for the
external
>>>>>>>>>>>> caller*
>>>>>>>>>>>>
>>>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1046)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1046)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.859:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=3996)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=3996)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *I then after that took off the hold and the following debug
>>>>>>>>>>>> came out. The call on the PSDN side still played the hold music while
>>>>>>>>>>>> there was no voice on the deskphone side.*
>>>>>>>>>>>>
>>>>>>>>>>>> *Jan 14 23:47:40.779:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742, Xmit Function=0x64204BAC
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>>> *Jan 14 23:47:40.783: cc_api_get_xcode_stream : 4702
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1046)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1046)
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=170, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.783:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_feature:
>>>>>>>>>>>> Feature Type=50, Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=171, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.811:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.815:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/ccGenerateToneInfo:
>>>>>>>>>>>> Stop Tone On Digit=FALSE, Tone=Null,
>>>>>>>>>>>> Tone Direction=Sum Network, Params=0x0, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=96, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.819:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_remote_codec_dnld_done:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741, Xmit Function=0x64204BAC
>>>>>>>>>>>> *Jan 14 23:47:40.839:
>>>>>>>>>>>> //12742/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
>>>>>>>>>>>> *Jan 14 23:47:40.839: cc_api_get_xcode_stream : 4702
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=1516)
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=170, Call Id=12741
>>>>>>>>>>>> *Jan 14 23:47:40.843:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.859:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12741,
>>>>>>>>>>>> Source Call Id=12742,
>>>>>>>>>>>> Caps(Codec=0x1, Fax Rate=0x2, Vad=0x2,
>>>>>>>>>>>> Modem=0x0, Codec Bytes=20, Signal Type=2)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_caps_ind:
>>>>>>>>>>>> Caps(Playout Mode=1, Playout Initial=60(ms), Playout
>>>>>>>>>>>> Min=40(ms),
>>>>>>>>>>>> Playout Max=1000(ms), Fax Nom=300(ms))
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=3996)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12741/9906C1828C05/CCAPI/cc_api_caps_ack:
>>>>>>>>>>>> Destination Interface=0xC05A65AC, Destination Call Id=12742,
>>>>>>>>>>>> Source Call Id=12741,
>>>>>>>>>>>> Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_NONE(0x1),
>>>>>>>>>>>> Vad=ON(0x2),
>>>>>>>>>>>> Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num
>>>>>>>>>>>> Start=3996)
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event=171, Call Id=12742
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_event_indication:
>>>>>>>>>>>> Event Is Sent To Conferenced SPI(s) Directly
>>>>>>>>>>>> *Jan 14 23:47:40.863:
>>>>>>>>>>>> //12742/9906C1828C05/CCAPI/cc_api_call_facility:
>>>>>>>>>>>> Interface=0xC05A65AC, Call Id=12742
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <
>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Have you also restarted the Cisco IP Media Services?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 14, 2013, at 6:12 PM, Dane Newman <
>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> My ITSP will only support 711ulaw for me currently I believe.
>>>>>>>>>>>>> They hard coded it with me when I was initially setting it up.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you think this could be a codec issue? How would I go
>>>>>>>>>>>>> about identifying if it is?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dane
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jan 14, 2013 at 6:09 PM, Kenneth Hayes <
>>>>>>>>>>>>> kennethwhayes at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Have you tried different audio codecs?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 14, 2013, at 6:06 PM, Dane Newman <
>>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ryan (sorry I forgot to reply to all)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the Reply
>>>>>>>>>>>>>> Oddly enough we are.
>>>>>>>>>>>>>> This probably has something to do with MOH in general?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Internally when I user puts another user on hold everything
>>>>>>>>>>>>>> works. No MOH plays and they can hold and unhold the call just fine.
>>>>>>>>>>>>>> I tested calling from an external number. Once I put the
>>>>>>>>>>>>>> external caller on hold the MOH played but I was unable to resume
the call.
>>>>>>>>>>>>>> When I hit resume on the deskphone the MOH still played to the
external
>>>>>>>>>>>>>> caller and there was no sound on the deskphone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jan 14, 2013 at 5:25 PM, Ryan Ratliff <
>>>>>>>>>>>>>> rratliff at cisco.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you get similar behavior if you just hold and resume the
>>>>>>>>>>>>>>> call outside SNR features?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Ryan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jan 14, 2013, at 4:18 PM, Dane Newman <
>>>>>>>>>>>>>>> dane.newman at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using keyboard-interactive authentication.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Password:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cisco3825#
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cisco3825#sh ver
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cisco IOS Software, 3800 Software
>>>>>>>>>>>>>>> (C3825-ADVENTERPRISEK9_IVS_LI-M), Version 15.1
>>>>>>>>>>>>>>> (4)M5, RELEASE SOFTWARE (fc1)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Technical Support: http://www.cisco.com/techsupport
>>>>>>>>>>>>>>> Copyright (c) 1986-2012 by Cisco Systems, Inc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Compiled Tue 04-Sep-12 17:25 by prod_rel_team
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE
>>>>>>>>>>>>>>> SOFTWARE (fc1)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cisco3825 uptime is 1 week, 1 day, 1 hour,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>
> [Message clipped]
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/49391d36/attachment.html>

From matthnick at gmail.com Wed Jan 16 16:23:00 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Wed, 16 Jan 2013 16:23:00 -0500
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To: <396590408.1220246.1358354957310.JavaMail.root@squeaky.cs.uoguelph.ca>
References: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
<396590408.1220246.1358354957310.JavaMail.root@squeaky.cs.uoguelph.ca>
Message-ID: <CAM-K-Nru2vi+aoZp2mEm76_Gww1SZL5s3j7urpQDKwGDtw_AXA@mail.gmail.com>

If you went to Cisco Live you may also have access to


www.ciscolive365.comwhere you can view the videos and recordings. For
those that don't you can
also buy a virtual-only pass which is not as expensive.

-nick

On Wed, Jan 16, 2013 at 11:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

> if you could post to the list, that would be helpful. thanks!
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it.
> - LFJ (with apologies to Mr. Popeil)
>
>
> ------------------------------
> *From: *"Chris Ward (chrward)" <chrward at cisco.com>
> *To: *"Jonathan Madziarczyk" <jmad at cityofevanston.org>,
> cisco-voip at puck.nether.net
> *Sent: *Wednesday, January 16, 2013 11:05:02 AM
> *Subject: *Re: [cisco-voip] Upgrading from 6x to 9x?
>
>
> I just finished working on a document with a couple other TMEs that is
> in the final stages of being published to Cisco.com. Once it is, I will
> send you a link. The doc team is giving it the final once over.
>
>
>
> +Chris
>
> Unity Connection TME
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Madziarczyk, Jonathan
> *Sent:* Monday, January 14, 2013 12:35 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] Upgrading from 6x to 9x?
>
>
>
> So I know Cisco did a full presentation at Live last year on this
> (including moving from physical to virtual), but they didn?t think to
> record it, so all I have is the powerpoint, which is sadly lacking in
> information. Has anyone seen a webex or similar presentation that actually
> goes through the process and mentions all the caveats?
>
>
>
> JonM
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/afdae83b/attachment.html>

From jmad at cityofevanston.org Wed Jan 16 17:09:06 2013


From: jmad at cityofevanston.org (Madziarczyk, Jonathan)
Date: Wed, 16 Jan 2013 16:09:06 -0600
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To: <CAM-K-Nru2vi+aoZp2mEm76_Gww1SZL5s3j7urpQDKwGDtw_AXA@mail.gmail.com>
References: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
<396590408.1220246.1358354957310.JavaMail.root@squeaky.cs.uoguelph.ca>
<CAM-K-Nru2vi+aoZp2mEm76_Gww1SZL5s3j7urpQDKwGDtw_AXA@mail.gmail.com>
Message-ID:
<4604610D6AAC164AA12B9E03AB79028B0B7B9EA0@EXCHANGE3.local.cityofevanston.org>

Unfortunately while this session was so popular that it overflowed the


room they were in, they did not record it.

For those with a CiscoLive365 acct, the session is "BRKUCC-2011 - Best


Practices for Migrating Previous Versions of Cisco Unified
Communications Manager (CUCM) to CUCM 9.X" You can at least view the
powerpoint.

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Matthews
Sent: Wednesday, January 16, 2013 3:23 PM
To: Lelio Fulgenzi
Cc: cisco-voip at puck.nether.net Group
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

If you went to Cisco Live you may also have access to


www.ciscolive365.com where you can view the videos and recordings. For
those that don't you can also buy a virtual-only pass which is not as
expensive.

-nick

On Wed, Jan 16, 2013 at 11:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca>
wrote:

if you could post to the list, that would be helpful. thanks!

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)

________________________________

From: "Chris Ward (chrward)" <chrward at cisco.com>


To: "Jonathan Madziarczyk" <jmad at cityofevanston.org>,
cisco-voip at puck.nether.net
Sent: Wednesday, January 16, 2013 11:05:02 AM
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?
I just finished working on a document with a couple other TMEs that is
in the final stages of being published to Cisco.com. Once it is, I will
send you a link. The doc team is giving it the final once over.

+Chris

Unity Connection TME

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Madziarczyk,
Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this


(including moving from physical to virtual), but they didn't think to
record it, so all I have is the powerpoint, which is sadly lacking in
information. Has anyone seen a webex or similar presentation that
actually goes through the process and mentions all the caveats?

JonM

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/f69684f6/attachment.html>

From chrward at cisco.com Wed Jan 16 17:15:21 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Wed, 16 Jan 2013 22:15:21 +0000
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To:
<4604610D6AAC164AA12B9E03AB79028B0B7B9EA0@EXCHANGE3.local.cityofevanston.org>
References: <C3D1FCA271936B48839E081F898E17AA1F6F91@xmb-rcd-x13.cisco.com>
<396590408.1220246.1358354957310.JavaMail.root@squeaky.cs.uoguelph.ca>
<CAM-K-Nru2vi+aoZp2mEm76_Gww1SZL5s3j7urpQDKwGDtw_AXA@mail.gmail.com>
<4604610D6AAC164AA12B9E03AB79028B0B7B9EA0@EXCHANGE3.local.cityofevanston.org>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1F76AE@xmb-rcd-x13.cisco.com>

Man, I hope the document that is incoming is worth the wait... :)

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Madziarczyk, Jonathan
Sent: Wednesday, January 16, 2013 5:09 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

Unfortunately while this session was so popular that it overflowed the room they
were in, they did not record it.
For those with a CiscoLive365 acct, the session is "BRKUCC-2011 - Best Practices
for Migrating Previous Versions of Cisco Unified Communications Manager (CUCM) to
CUCM 9.X" You can at least view the powerpoint.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick
Matthews
Sent: Wednesday, January 16, 2013 3:23 PM
To: Lelio Fulgenzi
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> Group
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

If you went to Cisco Live you may also have access to


www.ciscolive365.com<http://www.ciscolive365.com> where you can view the videos and
recordings. For those that don't you can also buy a virtual-only pass which is not
as expensive.
-nick

On Wed, Jan 16, 2013 at 11:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio
at uoguelph.ca>> wrote:
if you could post to the list, that would be helpful. thanks!

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
________________________________
From: "Chris Ward (chrward)" <chrward at cisco.com<mailto:chrward at cisco.com>>
To: "Jonathan Madziarczyk" <jmad at cityofevanston.org<mailto:jmad at
cityofevanston.org>>, cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Sent: Wednesday, January 16, 2013 11:05:02 AM
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

I just finished working on a document with a couple other TMEs that is in the final
stages of being published to Cisco.com. Once it is, I will send you a link. The doc
team is giving it the final once over.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Madziarczyk, Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this (including moving
from physical to virtual), but they didn't think to record it, so all I have is the
powerpoint, which is sadly lacking in information. Has anyone seen a webex or
similar presentation that actually goes through the process and mentions all the
caveats?

JonM

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d9fc6d4b/attachment.html>

From lelio at uoguelph.ca Wed Jan 16 17:16:25 2013


From: lelio at uoguelph.ca (Lelio Fulgenzi)
Date: Wed, 16 Jan 2013 17:16:25 -0500 (EST)
Subject: [cisco-voip] Upgrading from 6x to 9x?
In-Reply-To:
<4604610D6AAC164AA12B9E03AB79028B0B7B9EA0@EXCHANGE3.local.cityofevanston.org>
Message-ID: <648452862.1276452.1358374585925.JavaMail.root@squeaky.cs.uoguelph.ca>

power points are great, but without the audio, it's not as good.

if a document is forthcoming, especially something supported that you can refer to,
it's much better.

just my two cents.

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Jonathan Madziarczyk" <jmad at cityofevanston.org>
To: cisco-voip at puck.nether.net
Sent: Wednesday, January 16, 2013 5:09:06 PM
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

Unfortunately while this session was so popular that it overflowed the room they
were in, they did not record it. For those with a CiscoLive365 acct, the session is
? BRKUCC-2011 - Best Practices for Migrating Previous Versions of Cisco Unified
Communications Manager (CUCM) to CUCM 9.X ? You can at least view the powerpoint.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Nick Matthews
Sent: Wednesday, January 16, 2013 3:23 PM
To: Lelio Fulgenzi
Cc: cisco-voip at puck.nether.net Group
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

If you went to Cisco Live you may also have access to www.ciscolive365.com where
you can view the videos and recordings. For those that don't you can also buy a
virtual-only pass which is not as expensive.

-nick

On Wed, Jan 16, 2013 at 11:49 AM, Lelio Fulgenzi < lelio at uoguelph.ca > wrote:

if you could post to the list, that would be helpful. thanks!

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
From: "Chris Ward (chrward)" < chrward at cisco.com >
To: "Jonathan Madziarczyk" < jmad at cityofevanston.org >, cisco-voip at
puck.nether.net
Sent: Wednesday, January 16, 2013 11:05:02 AM
Subject: Re: [cisco-voip] Upgrading from 6x to 9x?

I just finished working on a document with a couple other TMEs that is in the final
stages of being published to Cisco.com. Once it is, I will send you a link. The doc
team is giving it the final once over.

+Chris

Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto: cisco-voip-bounces at


puck.nether.net ] On Behalf Of Madziarczyk, Jonathan
Sent: Monday, January 14, 2013 12:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Upgrading from 6x to 9x?

So I know Cisco did a full presentation at Live last year on this (including moving
from physical to virtual), but they didn?t think to record it, so all I have is the
powerpoint, which is sadly lacking in information. Has anyone seen a webex or
similar presentation that actually goes through the process and mentions all the
caveats?

JonM

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/41dcc136/attachment.html>

From mikenorton at pwsd76.ab.ca Wed Jan 16 18:50:00 2013


From: mikenorton at pwsd76.ab.ca (Norton, Mike)
Date: Wed, 16 Jan 2013 23:50:00 +0000
Subject: [cisco-voip] dial-peer destination-pattern with **
Message-ID: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>

What am I doing wrong here?

(config)#dial-peer voice 701 pots


(config-dial-peer)#destination-pattern **47..

It gives me this error:

% nested *?+Incorrect format for ^((\*)?*47..)$

Huh? I am trying to match two stars followed by 47 followed by two wildcard digits.
(If I only do one star instead of two, it works fine.) This is on a 2901 with
15.1(3)T4.

--
Mike Norton
I.T. Specialist
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/5c8a309c/attachment.html>

From matthnick at gmail.com Wed Jan 16 21:29:25 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Wed, 16 Jan 2013 21:29:25 -0500
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
Message-ID: <CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>

Looks like it doesn't parse correctly. Even though I haven't seen * used as
0 or more in a destination-pattern, and I don't think it works as an
operator, it appears IOS's parser pretends it is.

This would be an alternative: [*][*]47..

Though since [*] isn't a literal it will send all 6 numbers, so use
forward-digits as necessary.

-nick
On Wed, Jan 16, 2013 at 6:50 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>wrote:

> What am I doing wrong here?****


>
> ** **
>
> (config)#dial-peer voice 701 pots****
>
> (config-dial-peer)#destination-pattern **47..****
>
> ** **
>
> It gives me this error:****
>
> ** **
>
> % nested *?+Incorrect format for ^((\*)?*47..)$****
>
> ** **
>
> Huh? I am trying to match two stars followed by 47 followed by two
> wildcard digits. (If I only do one star instead of two, it works fine.)
> This is on a 2901 with 15.1(3)T4.****
>
> ** **
>
> -- ****
>
> Mike Norton****
>
> I.T. Specialist****
>
> Peace Wapiti School Division No. 76****
>
> Helpdesk: 780-831-3080****
>
> Direct: 780-831-3076****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/f12a1d3d/attachment.html>

From avholloway+cisco-voip at gmail.com Wed Jan 16 21:46:39 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Wed, 16 Jan 2013 20:46:39 -0600
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
<CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
Message-ID: <CACRCJOiZX-EbLUz3o81s6e3gURWKo_ehagSfYBkaST3EiSeX1w@mail.gmail.com>
I just ran into this myself, and out of trial and error, I ended up with
the following:

num-exp \*\*47 916125551212

Since number expansion happens before outgoing DP call leg matching, the
call ends up using the normal 91[2-9]..[2-9]...... PSTN dial peer.

I would use these ** codes as global speed dials. I'm happy to know more
than one method to solve this problem though, so thank you for sharing your
[*][*] solution.

On Wed, Jan 16, 2013 at 8:29 PM, Nick Matthews <matthnick at gmail.com> wrote:

> Looks like it doesn't parse correctly. Even though I haven't seen * used
> as 0 or more in a destination-pattern, and I don't think it works as an
> operator, it appears IOS's parser pretends it is.
>
> This would be an alternative: [*][*]47..
>
> Though since [*] isn't a literal it will send all 6 numbers, so use
> forward-digits as necessary.
>
> -nick
>
>
> On Wed, Jan 16, 2013 at 6:50 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>wrote:
>
>> What am I doing wrong here?****
>>
>> ** **
>>
>> (config)#dial-peer voice 701 pots****
>>
>> (config-dial-peer)#destination-pattern **47..****
>>
>> ** **
>>
>> It gives me this error:****
>>
>> ** **
>>
>> % nested *?+Incorrect format for ^((\*)?*47..)$****
>>
>> ** **
>>
>> Huh? I am trying to match two stars followed by 47 followed by two
>> wildcard digits. (If I only do one star instead of two, it works fine.)
>> This is on a 2901 with 15.1(3)T4.****
>>
>> ** **
>>
>> -- ****
>>
>> Mike Norton****
>>
>> I.T. Specialist****
>>
>> Peace Wapiti School Division No. 76****
>>
>> Helpdesk: 780-831-3080****
>>
>> Direct: 780-831-3076****
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d7ee9e32/attachment.html>

From matthnick at gmail.com Wed Jan 16 22:54:08 2013


From: matthnick at gmail.com (Nick Matthews)
Date: Wed, 16 Jan 2013 22:54:08 -0500
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <CACRCJOiZX-EbLUz3o81s6e3gURWKo_ehagSfYBkaST3EiSeX1w@mail.gmail.com>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
<CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
<CACRCJOiZX-EbLUz3o81s6e3gURWKo_ehagSfYBkaST3EiSeX1w@mail.gmail.com>
Message-ID: <CAM-K-Nq1oM=nVWqw1XU7hye7m9gM5fhiqdMBJF1+p0DHzNSMLg@mail.gmail.com>

I tried escaping it in the destination-pattern, but since traditional regex


isn't allowed you can't actually escape it there.

AwesomeSauce(config-dial-peer)#destination-pattern \*\*47
Incorrect format for E.164 Number
regular expression must be of the form
^[][^0-9,A-F#*.?+%()-]*T?(\$)?$

-nick

On Wed, Jan 16, 2013 at 9:46 PM, Anthony Holloway <


avholloway+cisco-voip at gmail.com> wrote:

> I just ran into this myself, and out of trial and error, I ended up with
> the following:
>
> num-exp \*\*47 916125551212
>
>
> Since number expansion happens before outgoing DP call leg matching, the
> call ends up using the normal 91[2-9]..[2-9]...... PSTN dial peer.
>
> I would use these ** codes as global speed dials. I'm happy to know more
> than one method to solve this problem though, so thank you for sharing your
> [*][*] solution.
>
>
> On Wed, Jan 16, 2013 at 8:29 PM, Nick Matthews <matthnick at gmail.com>wrote:
>
>> Looks like it doesn't parse correctly. Even though I haven't seen * used
>> as 0 or more in a destination-pattern, and I don't think it works as an
>> operator, it appears IOS's parser pretends it is.
>>
>> This would be an alternative: [*][*]47..
>>
>> Though since [*] isn't a literal it will send all 6 numbers, so use
>> forward-digits as necessary.
>>
>> -nick
>>
>>
>> On Wed, Jan 16, 2013 at 6:50 PM, Norton, Mike <mikenorton at
pwsd76.ab.ca>wrote:
>>
>>> What am I doing wrong here?****
>>>
>>> ** **
>>>
>>> (config)#dial-peer voice 701 pots****
>>>
>>> (config-dial-peer)#destination-pattern **47..****
>>>
>>> ** **
>>>
>>> It gives me this error:****
>>>
>>> ** **
>>>
>>> % nested *?+Incorrect format for ^((\*)?*47..)$****
>>>
>>> ** **
>>>
>>> Huh? I am trying to match two stars followed by 47 followed by two
>>> wildcard digits. (If I only do one star instead of two, it works fine.)
>>> This is on a 2901 with 15.1(3)T4.****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> Mike Norton****
>>>
>>> I.T. Specialist****
>>>
>>> Peace Wapiti School Division No. 76****
>>>
>>> Helpdesk: 780-831-3080****
>>>
>>> Direct: 780-831-3076****
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/dffcc2ed/attachment.html>

From kris.edgar82 at gmail.com Thu Jan 17 09:22:56 2013


From: kris.edgar82 at gmail.com (Kris Edgar)
Date: Thu, 17 Jan 2013 14:22:56 +0000
Subject: [cisco-voip] Fwd: Bulk Import of Gateways - CUCM 8.6
In-Reply-To: <CAF5YbzV3gHHCyfQ3+CmG12iKgzAxXtWyeZ=H=m3EUwmSVpzbPA@mail.gmail.com>
References: <CAF5YbzV3gHHCyfQ3+CmG12iKgzAxXtWyeZ=H=m3EUwmSVpzbPA@mail.gmail.com>
Message-ID: <CAF5YbzVAW6sECtFB+19O4pFpe9eLVshO95rFwsUxJ8FCeua3bw@mail.gmail.com>

Hi Folks,

Great group going on here!! I'm hoping someone can give me advice on the
following:

We are using CUCM 8.6 and are looking to import a large number of H323
GW's, RG's, RL's etc.

I've used the Import/Export tool and selected GW's and used the "Check
dependency" to capture all the other associated fields.

I now have a tar file with all the CSV's needed. Happy so far!!

I'm not too sure if i need to keep the existing data in the CSV's, and add
to it? Or can I strip out the existing elements (keeping the headers) and
just have the new file with the elements that i need to import?

I have a horrible thought that if i re-import the file without the original
GW's etc, it might delete them from CM and leave me with my new GW's etc.

Paranoid.com!!!

Thanks for your help on this.

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/1c203349/attachment.html>

From kris.edgar82 at gmail.com Thu Jan 17 12:20:35 2013


From: kris.edgar82 at gmail.com (Kris Edgar)
Date: Thu, 17 Jan 2013 17:20:35 +0000
Subject: [cisco-voip] Bulk Import of Gateways - CUCM 8.6
Message-ID: <CAF5YbzW2YH=VMDxSJ_x6vD04v=zdFn=D7crnzTeK6dt25ONr-A@mail.gmail.com>

Hi Folks,

Great group going on here!! I'm hoping someone can give me advice on the
following:

We are using CUCM 8.6 and are looking to import a large number of H323
GW's, RG's, RL's etc.

I've used the Import/Export tool and selected GW's and used the "Check
dependency" to capture all the other associated fields.

I now have a tar file with all the CSV's needed. Happy so far!!

I'm not too sure if i need to keep the existing data in the CSV's, and add
to it? Or can I strip out the existing elements (keeping the headers) and
just have the new file with the elements that i need to import?

I have a horrible thought that if i re-import the file without the original
GW's etc, it might delete them from CM and leave me with my new GW's etc.

Paranoid.com!!!

Thanks for your help on this.

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/f3fcb927/attachment.html>

From HavaedjiMir at johndeere.com Thu Jan 17 12:23:38 2013


From: HavaedjiMir at johndeere.com (Havaedji Mir)
Date: Thu, 17 Jan 2013 11:23:38 -0600
Subject: [cisco-voip] Call Park Timeout - CUCM 8.6
Message-ID: <925BEE4256EAA44AA7E1070FC5AB443401F83EFA1D@edxmb30.jdnet.deere.com>

Hi All,

Is there a way to configure Call Park Timeout in Cisco Call Manager? I know this
feature is available in CC Express.

Thanks,
Mir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/f7254a7f/attachment.html>

From abbaseo at gmail.com Thu Jan 17 12:32:10 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Thu, 17 Jan 2013 17:32:10 +0000
Subject: [cisco-voip] XML service not working
In-Reply-To: <0C2BBE82-6AA7-4F5B-96CF-DA099AFF5075@cisco.com>
References: <CAFdHCp6b3qPRWcMUKHS=uKZ6zhd35yZrNUYHvEv_7sBJ6m5Q=w@mail.gmail.com>
<837179558143865822@unknownmsgid>
<CAFdHCp4UoEBTyvesb2RC2brr1XmhDxajTLc7kw9hwrwNMeOqHg@mail.gmail.com>
<CAFdHCp5-nGzcwzJ5SeXxtpA68eG-uqwjWj_5ovF0ZWvqOoKb=A@mail.gmail.com>
<A0A09F55-629F-4DB7-8D3C-73DAD7DA0D2E@cisco.com>
<CAFdHCp7ZrCWqKT+Sa7dHWLdW_CF9S3_3i26oSjcuLB88nSpUPQ@mail.gmail.com>
<2395363C-2584-47CD-803F-AE9B82B9CC64@cisco.com>
<CAFdHCp5Lku2rfbKGY1ydn6c0jcJh2Er-DTcNT-7+Y_OibmA0DA@mail.gmail.com>
<0C2BBE82-6AA7-4F5B-96CF-DA099AFF5075@cisco.com>
Message-ID: <CAFdHCp6VTYE_D+qTkXNCfCeX5stNKtm7fW1HSjE=CeNomtgTuw@mail.gmail.com>

Got to the bottom of it now,

the phone is trying to go directly to the internet and by passing the


Proxy that?s why its been blocked by proxy.

That?s looks to be the case as when my browser has got a proxy address I
can go to this link
http://85.214.108.91/xml/xml-currency.html?device=#DEVICENAME#

But when proxy is disabled then browser fails.

Need to add some rules in the proxy for the phone subnet!!! I believe.

On 16 January 2013 21:00, Ryan Ratliff <rratliff at cisco.com> wrote:

> Do you see the TCP connection being established between the phone and web
> server? Your highlighted packet is the phone resetting a question, not
> making a request or even doing the tcp 3-way handshake.
>
> -Ryan
>
> On Jan 16, 2013, at 2:29 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> have captured packets from the phone
>
> 152.12 being my phone and 108.91 is the website.
> seems to be the website is unable to reply to my TCP acks. there is not
> HTTP between them two.
>
>
> On 16 January 2013 18:30, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Either don't provide a Secure Service-URL or populate it, just use
http://instead of https://(and don't point to a secure port).
>>
>> -Ryan
>>
>> On Jan 16, 2013, at 1:02 PM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> how/where we can disable the HTTPS?
>>
>> On 16 January 2013 17:27, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> You've got HTTPS enabled so the phone is going to try that. Does your
>>> CUCM have the certs for that site imported so TVS can authenticate the cert
>>> the web server is going to pass down to the phone?
>>>
>>> -Ryan
>>>
>>> On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>>
>>> sorry just confirmed, it does work from the web b.
>>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME#
>>> which means there is no issue with the firewall or DNS
>>> *
>>> On 16 January 2013 16:30, abbas Wali <abbaseo at gmail.com> wrote:
>>>
>>>> not a firewall guy, but just wondering if i can access their main
>>>> website http://www.andtek.com/communications-products-freexml.html
>>>> and also i have checked nothing comes up when I go to the URL
>>>> *http://www.andtek.com/xml/xml-service.html?device=#DEVICENAME# from
>>>> web browers too (proxy disabled)*
>>>>
>>>>
>>>> On 16 January 2013 16:18, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>>>>
>>>>> Firewall isn't blocking anything is it?
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Jan 16, 2013, at 11:17 AM, abbas Wali <abbaseo at gmail.com> wrote:
>>>>>
>>>>> Folks,
>>>>>
>>>>> I have added some XML services on the node but the phone goes into
>>>>> Requesting when I hit the service in the phone.
>>>>>
>>>>>
>>>>>
>>>>> any ideas!!
>>>>>
>>>>> Thanks
>>>>> --
>>>>> @bbas..
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> @bbas..
>>>>
>>>
>>>
>>>
>>> --
>>> @bbas..
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> @bbas..
>>
>>
>
>
> --
> @bbas..
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/6bc14573/attachment.html>

From btalley at gmail.com Thu Jan 17 12:32:42 2013


From: btalley at gmail.com (Bill Talley)
Date: Thu, 17 Jan 2013 11:32:42 -0600
Subject: [cisco-voip] Call Park Timeout - CUCM 8.6
In-Reply-To: <925BEE4256EAA44AA7E1070FC5AB443401F83EFA1D@edxmb30.jdnet.deere.com>
References: <925BEE4256EAA44AA7E1070FC5AB443401F83EFA1D@edxmb30.jdnet.deere.com>
Message-ID: <CAM+6AtDT4h+o6KYoDsrsj1w95Anv-=pqHWZBN=sLs00a3MVmFw@mail.gmail.com>

Yes. It's the Park Reversion timer under Service Parameters (System menu)
in Communications Manager.

On Thu, Jan 17, 2013 at 11:23 AM, Havaedji Mir <HavaedjiMir at johndeere.com>wrote:

> Hi All,****
>
> ** **
>
> Is there a way to configure Call Park Timeout in Cisco Call Manager? I
> know this feature is available in CC Express.****
>
> ** **
>
> Thanks,****
>
> Mir****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/1c681094/attachment.html>

From avholloway+cisco-voip at gmail.com Thu Jan 17 12:56:11 2013


From: avholloway+cisco-voip at gmail.com (Anthony Holloway)
Date: Thu, 17 Jan 2013 11:56:11 -0600
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <CAM-K-Nq1oM=nVWqw1XU7hye7m9gM5fhiqdMBJF1+p0DHzNSMLg@mail.gmail.com>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
<CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
<CACRCJOiZX-EbLUz3o81s6e3gURWKo_ehagSfYBkaST3EiSeX1w@mail.gmail.com>
<CAM-K-Nq1oM=nVWqw1XU7hye7m9gM5fhiqdMBJF1+p0DHzNSMLg@mail.gmail.com>
Message-ID: <CACRCJOj_OmBe7Eve7y=Q0gO2OU8yYhz9j+jZRi9YCJm_Vb7vFg@mail.gmail.com>

Correct. I should have noted that I tried that as well, which then lead me
to the number expansion based solution, which does allow escape characters.

On Wed, Jan 16, 2013 at 9:54 PM, Nick Matthews <matthnick at gmail.com> wrote:

> I tried escaping it in the destination-pattern, but since traditional


> regex isn't allowed you can't actually escape it there.
>
> AwesomeSauce(config-dial-peer)#destination-pattern \*\*47
> Incorrect format for E.164 Number
> regular expression must be of the form
> ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$
>
> -nick
>
>
>
> On Wed, Jan 16, 2013 at 9:46 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> I just ran into this myself, and out of trial and error, I ended up with
>> the following:
>>
>> num-exp \*\*47 916125551212
>>
>>
>> Since number expansion happens before outgoing DP call leg matching, the
>> call ends up using the normal 91[2-9]..[2-9]...... PSTN dial peer.
>>
>> I would use these ** codes as global speed dials. I'm happy to know more
>> than one method to solve this problem though, so thank you for sharing your
>> [*][*] solution.
>>
>>
>> On Wed, Jan 16, 2013 at 8:29 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>
>>> Looks like it doesn't parse correctly. Even though I haven't seen * used
>>> as 0 or more in a destination-pattern, and I don't think it works as an
>>> operator, it appears IOS's parser pretends it is.
>>>
>>> This would be an alternative: [*][*]47..
>>>
>>> Though since [*] isn't a literal it will send all 6 numbers, so use
>>> forward-digits as necessary.
>>>
>>> -nick
>>>
>>>
>>> On Wed, Jan 16, 2013 at 6:50 PM, Norton, Mike <mikenorton at
pwsd76.ab.ca>wrote:
>>>
>>>> What am I doing wrong here?****
>>>>
>>>> ** **
>>>>
>>>> (config)#dial-peer voice 701 pots****
>>>>
>>>> (config-dial-peer)#destination-pattern **47..****
>>>>
>>>> ** **
>>>>
>>>> It gives me this error:****
>>>>
>>>> ** **
>>>>
>>>> % nested *?+Incorrect format for ^((\*)?*47..)$****
>>>>
>>>> ** **
>>>>
>>>> Huh? I am trying to match two stars followed by 47 followed by two
>>>> wildcard digits. (If I only do one star instead of two, it works fine.)
>>>> This is on a 2901 with 15.1(3)T4.****
>>>>
>>>> ** **
>>>>
>>>> -- ****
>>>>
>>>> Mike Norton****
>>>>
>>>> I.T. Specialist****
>>>>
>>>> Peace Wapiti School Division No. 76****
>>>>
>>>> Helpdesk: 780-831-3080****
>>>>
>>>> Direct: 780-831-3076****
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/90fc768b/attachment.html>

From mike.lydick at gmail.com Thu Jan 17 14:24:34 2013


From: mike.lydick at gmail.com (Mike Lydick)
Date: Thu, 17 Jan 2013 14:24:34 -0500
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
Message-ID: <003f01cdf4e8$4be792b0$e3b6b810$@gmail.com>

Another solution maybe create and apply translation to the incoming call leg
dial-peer that would strip the ** and replace with a unique prefix, then
have similar on the outgoing call dial-peer that would strip the pre-fix and
restore the **.

This is what I was thinking.

voice translation-rule 9998

rule 1 /\*\*\(74..\)$/ /#\1/

voice translation-rule 9999

rule 1 /#\(74..\)$/ /**\1/

voice translation-profile SD1

translate called 9998

voice translation-profile SD2

translate called 9999

dial-peer voice 2 voip

translation-profile outgoing SD1

incoming called-number .

dial-peer voice 7400 voip

translation-profile incoming SD2

destination-pattern #74..$

session target ipv4:x.x.x.x


dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Norton, Mike
Sent: Wednesday, January 16, 2013 6:50 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] dial-peer destination-pattern with **

What am I doing wrong here?

(config)#dial-peer voice 701 pots

(config-dial-peer)#destination-pattern **47..

It gives me this error:

% nested *?+Incorrect format for ^((\*)?*47..)$

Huh? I am trying to match two stars followed by 47 followed by two wildcard


digits. (If I only do one star instead of two, it works fine.) This is on a
2901 with 15.1(3)T4.

--

Mike Norton

I.T. Specialist

Peace Wapiti School Division No. 76

Helpdesk: 780-831-3080

Direct: 780-831-3076

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/42ecfdea/attachment.html>

From mikenorton at pwsd76.ab.ca Thu Jan 17 14:53:42 2013


From: mikenorton at pwsd76.ab.ca (Norton, Mike)
Date: Thu, 17 Jan 2013 19:53:42 +0000
Subject: [cisco-voip] dial-peer destination-pattern with **
In-Reply-To: <CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
References: <2C4107B204F8E74EB0A63EF59B0F97020C9D0433@PWSDEXCHANGE06.pwsb33.ab.ca>
<CAM-K-NoZB5DPm8Nxpc+RdEg6Zgv60E6ZXv5xQE7EohsurtTZLA@mail.gmail.com>
Message-ID: <2C4107B204F8E74EB0A63EF59B0F97020C9D0880@PWSDEXCHANGE06.pwsb33.ab.ca>

It seems [*][*]47.. will do the trick. But according to the documentation, it is


not actually allowed.

>From http://www.cisco.com/en/US/docs/ios-xml/ios/voice/vcr2/vcr-d1.html#GUID-
32D33F3E-AFFC-4A5B-A305-56353A898C17
"Brackets ([ ]), which indicate a range. A range is a sequence of characters
enclosed in the brackets; only numeric characters from 0 to 9 are allowed in the
range."

Hmm. I think somebody was smoking something when they wrote the code to parse
destination-patterns.

--
Mike Norton
I.T. Specialist
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076

From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick Matthews


Sent: January-16-13 7:29 PM
To: Norton, Mike
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] dial-peer destination-pattern with **

Looks like it doesn't parse correctly. Even though I haven't seen * used as 0 or
more in a destination-pattern, and I don't think it works as an operator, it
appears IOS's parser pretends it is.

This would be an alternative: [*][*]47..


Though since [*] isn't a literal it will send all 6 numbers, so use forward-digits
as necessary.
-nick

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/314e8312/attachment.html>

From Vinnie at tdnetwork.com Thu Jan 17 23:40:45 2013


From: Vinnie at tdnetwork.com (Vincent)
Date: Thu, 17 Jan 2013 20:40:45 -0800
Subject: [cisco-voip] Newbie on Cisco Phone
Message-ID: <71D9BE0308E241A2816B6E965305D49C@xw8200>

Hi All,

I am specialize on routing and switching only, and newbie on cisco phone.


trying to work on my phone system but little bit confusing. so your help is
very appreciated.

When service provider provides the voice/data line, they terminate our end
with a router(usually IAD router) is this correct? and if i run CME 2811,
after config it, route it to IAD as its gateway, register it with IAD via
SIP or CGMP...., is this correct. and i have about 20 users, will pvdm2-32
handle this voice service ok without hic-up. will it take all the bandwidth
of 1.5MB as T1 since i will use it as data as well. assume i am not
provided IAD router from ISP, can i just use the CME 2811 as router for data
and voice service at the same time? and lastly, will the AIM-CUE or NM-CUE
work for voice mail in this scenario?

I am so sorry if it's a lengthy, multiple questions. just trying to get the


picture in my head. again, thank you very much and appreciated your time.

.........People First..........

Best Regards,

Vincent Dao

From Robin.Clayton at rrfa.org.uk Fri Jan 18 03:42:48 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 18 Jan 2013 08:42:48 +0000
Subject: [cisco-voip] Limity Unity Greetings Administrators?
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3BC7889@SV-C-EXCHMB-
01.richardrose.internal>

On Unity Connection 7.

Can a Greeting Administrator be limited to managing specific Call Handler?

Cheers

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------
Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/afae6751/attachment.html>

From abbaseo at gmail.com Fri Jan 18 07:34:29 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Fri, 18 Jan 2013 12:34:29 +0000
Subject: [cisco-voip] unity extremly slow with IE
Message-ID: <CAFdHCp6buihyP6K_nG3xFr07ptNJ9QxFwz4ka15_C4b336sRjQ@mail.gmail.com>

guys,

unity 8 is painfully slow with IE 9.


it works fine with firefox but some features are missing.

is there anything there!!

thanks

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/661ccb17/attachment.html>

From salamka at gmail.com Fri Jan 18 08:04:27 2013


From: salamka at gmail.com (Abdul Salam)
Date: Fri, 18 Jan 2013 18:34:27 +0530
Subject: [cisco-voip] unity extremly slow with IE
In-Reply-To: <CAFdHCp6buihyP6K_nG3xFr07ptNJ9QxFwz4ka15_C4b336sRjQ@mail.gmail.com>
References: <CAFdHCp6buihyP6K_nG3xFr07ptNJ9QxFwz4ka15_C4b336sRjQ@mail.gmail.com>
Message-ID: <46DFE8E4-7B6A-43B5-B635-5051C138ECFB@gmail.com>

It would be a good idea to check software compatibility matrix document .

Sent from my iPhone

On 18-Jan-2013, at 6:04 PM, abbas Wali <abbaseo at gmail.com> wrote:

> guys,
>
> unity 8 is painfully slow with IE 9.
> it works fine with firefox but some features are missing.
>
>
> is there anything there!!
>
> thanks
>
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/b4ccb978/attachment.html>

From Robin.Clayton at rrfa.org.uk Fri Jan 18 09:06:19 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Fri, 18 Jan 2013 14:06:19 +0000
Subject: [cisco-voip] Unity 7.x MWI report?
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3BC7BAB@SV-C-EXCHMB-
01.richardrose.internal>

On the old version of Unity X I could Pull a report of MWI's

I can't find it in 7.x

Any ideas where it's gone to if it's still available?

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/bd24d11e/attachment.html>

From kalyan.iyer at dimensiondata.com Fri Jan 18 13:48:32 2013


From: kalyan.iyer at dimensiondata.com (Kalyan Iyer (AM))
Date: Fri, 18 Jan 2013 13:48:32 -0500
Subject: [cisco-voip] VG224 to RightFax communication error issue
Message-ID:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)

When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/9b050663/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Vg224-updt.txt
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/9b050663/attachment.txt>

From svoll.voip at gmail.com Fri Jan 18 16:15:19 2013


From: svoll.voip at gmail.com (Scott Voll)
Date: Fri, 18 Jan 2013 13:15:19 -0800
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
Message-ID: <CAHgd+38S=nD4yR4=AF7QYtq1aWwepAd4xSc7SO-EQwvL8u31aw@mail.gmail.com>

t38 support?

ecm?

On Fri, Jan 18, 2013 at 10:48 AM, Kalyan Iyer (AM) <
kalyan.iyer at dimensiondata.com> wrote:
> I have a customer that has the following setup****
>
> ** **
>
> Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual
> server)****
>
> Or****
>
> Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- >
> RightFax (virtual server)****
>
> ** **
>
> When they try to fax in to the RightFax server in both the scenarios, they
> hear the fax tone but get a communication error. I was told that when they
> were using SIP between CUCM and RightFax, it worked well. They are however
> able to fax out from the RightFax server to the fax machine.****
>
> ** **
>
> The VG224 configuration is attached. Any help will be appreciated.****
>
> ** **
>
> Thanks****
>
> ** **
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/f4c58658/attachment.html>

From mballard at otis.edu Fri Jan 18 16:22:41 2013


From: mballard at otis.edu (Matthew Ballard)
Date: Fri, 18 Jan 2013 21:22:41 +0000
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
Message-ID: <CD1EFC39.29967%mballard@otis.edu>

Assuming that RightFax is exclusively using T.38 Standards Based (which it probably
is), unless something has changed that I'm not remembering (and even then it would
depend on the version), SCCP doesn't support standards based T.38.

I configured my VG224 to use MGCP with T.38 for the fax/modem ports, and SCCP for
the voice ports.

The router on H.323 probably just needs to be configured to support T.38.


It would probably also work if you passed the call through the PSTN (ie used the
full number with whatever you use to indicate an outside call).

Matthew Ballard
Network Manager
Otis College of Art and Design

From: "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com<mailto:kalyan.iyer at


dimensiondata.com>>
Date: Friday, January 18, 2013 10:48 AM
To: "'cisco-voip at puck. net'" <cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>>
Subject: [cisco-voip] VG224 to RightFax communication error issue

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)

When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks

From carlo_calabrese2006 at yahoo.com Fri Jan 18 21:14:25 2013


From: carlo_calabrese2006 at yahoo.com (Carlo)
Date: Fri, 18 Jan 2013 18:14:25 -0800
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
Message-ID: <D53F3173-AB04-40A7-B64F-206BEBC26DC3@yahoo.com>

I have had problems with the 15 code and faxing. I move most of mine back to 12
code. one thing you can check is do a show voice call status and watch to make sure
it goes to g711uaw then to T38.

I have also set my fallback to cisco

Sent from my iPad

On Jan 18, 2013, at 10:48 AM, "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com>
wrote:

> I have a customer that has the following setup


>
> Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
> Or
> Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)
>
> When they try to fax in to the RightFax server in both the scenarios, they hear
the fax tone but get a communication error. I was told that when they were using
SIP between CUCM and RightFax, it worked well. They are however able to fax out
from the RightFax server to the fax machine.
>
> The VG224 configuration is attached. Any help will be appreciated.
>
> Thanks
>
>
> <Vg224-updt.txt>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/7bb8abee/attachment.html>

From jason.aarons at dimensiondata.com Sat Jan 19 07:42:13 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Sat, 19 Jan 2013 07:42:13 -0500
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To: <CD1EFC39.29967%mballard@otis.edu>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
<CD1EFC39.29967%mballard@otis.edu>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C850AAB@USISPCLEXDB01.na.didata.local>

Correct, SCCP doesn't support standards based T.38. The VG224 port would need to
be changed from SCCP.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Ballard
Sent: Friday, January 18, 2013 4:23 PM
To: Kalyan Iyer (AM); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] VG224 to RightFax communication error issue

Assuming that RightFax is exclusively using T.38 Standards Based (which it probably
is), unless something has changed that I'm not remembering (and even then it would
depend on the version), SCCP doesn't support standards based T.38.

I configured my VG224 to use MGCP with T.38 for the fax/modem ports, and SCCP for
the voice ports.

The router on H.323 probably just needs to be configured to support T.38.

It would probably also work if you passed the call through the PSTN (ie used the
full number with whatever you use to indicate an outside call).
Matthew Ballard
Network Manager
Otis College of Art and Design

From: "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com<mailto:kalyan.iyer at


dimensiondata.com<mailto:kalyan.iyer at dimensiondata.com%3cmailto:kalyan.iyer at
dimensiondata.com>>>
Date: Friday, January 18, 2013 10:48 AM
To: "'cisco-voip at puck. net'" <cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net%3cmailto:cisco-voip at
puck.nether.net>>>
Subject: [cisco-voip] VG224 to RightFax communication error issue

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)

When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
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/20130119/7ec881ec/attachment.html>

From kalyan.iyer at dimensiondata.com Sat Jan 19 11:27:44 2013


From: kalyan.iyer at dimensiondata.com (Kalyan Iyer (AM))
Date: Sat, 19 Jan 2013 11:27:44 -0500
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C850AAB@USISPCLEXDB01.na.didata.local>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
<CD1EFC39.29967%mballard@otis.edu>,
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C850AAB@USISPCLEXDB01.na.didata.local>
Message-ID:
<75778C6826D2F248A21C5F173081485422579A3748@USISPCLEXDB01.na.didata.local>

Folks,
I came across this tech article on Cisco's website

http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxsrelay.html#wp1
086440
which mentions t.38 support for IOS versions 12.4(6)XE and later on SCCP controlled
voice gateways. This customer is running 15.x. Shouldn't the t.38 fax relay be
supported?
what am I missing?

________________________________________
From: Jason Aarons (AM)
Sent: Saturday, January 19, 2013 7:42 AM
To: Matthew Ballard; Kalyan Iyer (AM); cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] VG224 to RightFax communication error issue

Correct, SCCP doesn?t support standards based T.38. The VG224 port would need to
be changed from SCCP.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Ballard
Sent: Friday, January 18, 2013 4:23 PM
To: Kalyan Iyer (AM); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] VG224 to RightFax communication error issue

Assuming that RightFax is exclusively using T.38 Standards Based (which it probably
is), unless something has changed that I'm not remembering (and even then it would
depend on the version), SCCP doesn't support standards based T.38.

I configured my VG224 to use MGCP with T.38 for the fax/modem ports, and SCCP for
the voice ports.

The router on H.323 probably just needs to be configured to support T.38.

It would probably also work if you passed the call through the PSTN (ie used the
full number with whatever you use to indicate an outside call).

Matthew Ballard
Network Manager
Otis College of Art and Design

From: "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com<mailto:kalyan.iyer at


dimensiondata.com<mailto:kalyan.iyer at dimensiondata.com%3cmailto:kalyan.iyer at
dimensiondata.com>>>
Date: Friday, January 18, 2013 10:48 AM
To: "'cisco-voip at puck. net'" <cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net%3cmailto:cisco-voip at
puck.nether.net>>>
Subject: [cisco-voip] VG224 to RightFax communication error issue

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)
When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

itevomcid

From jason.aarons at dimensiondata.com Sat Jan 19 13:25:35 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Sat, 19 Jan 2013 13:25:35 -0500
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<75778C6826D2F248A21C5F173081485422579A3748@USISPCLEXDB01.na.didata.local>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
<CD1EFC39.29967%mballard@otis.edu>,
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C850AAB@USISPCLEXDB01.na.didata.local>
<75778C6826D2F248A21C5F173081485422579A3748@USISPCLEXDB01.na.didata.local>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2C850AB9@USISPCLEXDB01.na.didata.local>

That is NSE based not standards based.

https://supportforums.cisco.com/docs/DOC-
14470#Q_Will_SCCP_protocol_ever_support_standardsbased_T38

-----Original Message-----
From: Kalyan Iyer (AM)
Sent: Saturday, January 19, 2013 11:28 AM
To: Jason Aarons (AM); Matthew Ballard; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] VG224 to RightFax communication error issue

Folks,

I came across this tech article on Cisco's website

http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxsrelay.html#wp1
086440
which mentions t.38 support for IOS versions 12.4(6)XE and later on SCCP controlled
voice gateways. This customer is running 15.x. Shouldn't the t.38 fax relay be
supported?
what am I missing?
________________________________________
From: Jason Aarons (AM)
Sent: Saturday, January 19, 2013 7:42 AM
To: Matthew Ballard; Kalyan Iyer (AM); cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] VG224 to RightFax communication error issue

Correct, SCCP doesn't support standards based T.38. The VG224 port would need to
be changed from SCCP.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Ballard
Sent: Friday, January 18, 2013 4:23 PM
To: Kalyan Iyer (AM); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] VG224 to RightFax communication error issue

Assuming that RightFax is exclusively using T.38 Standards Based (which it probably
is), unless something has changed that I'm not remembering (and even then it would
depend on the version), SCCP doesn't support standards based T.38.

I configured my VG224 to use MGCP with T.38 for the fax/modem ports, and SCCP for
the voice ports.

The router on H.323 probably just needs to be configured to support T.38.

It would probably also work if you passed the call through the PSTN (ie used the
full number with whatever you use to indicate an outside call).

Matthew Ballard
Network Manager
Otis College of Art and Design

From: "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com<mailto:kalyan.iyer at


dimensiondata.com<mailto:kalyan.iyer at dimensiondata.com%3cmailto:kalyan.iyer at
dimensiondata.com>>>
Date: Friday, January 18, 2013 10:48 AM
To: "'cisco-voip at puck. net'" <cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net<mailto:cisco-voip at puck.nether.net%3cmailto:cisco-voip at
puck.nether.net>>>
Subject: [cisco-voip] VG224 to RightFax communication error issue

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server) Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)

When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

itevomcid

From dwolgas1 at rochester.rr.com Mon Jan 21 10:12:31 2013


From: dwolgas1 at rochester.rr.com (Dave Wolgast)
Date: Mon, 21 Jan 2013 10:12:31 -0500
Subject: [cisco-voip] SRST: re-routing autoattendant
Message-ID: <CAHOZW-1__EhBZ6SuSqR8vhNozk4G+Nw3SCx3Kt+Agbxc2oR32A@mail.gmail.com>

I have set up a branch site using IOS Telephony Service for SRST (rather
then call-manager-fallback) on an H.323 gateway. The branch has an
automated attendant on Unity Connection at a central site which is reached
via a CUCM CTI RP with CFA to UCxn.

In the event of a SRST activation, I would like all automated attendant


calls to go to the receptionist's DN, but I can't figure out how to
redirect the main number to her phone. I see that call-manager-fallback has
the alias command. Is there something similar in telephony-service?

--
Dave Wolgast
Livonia, NY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/36a31a72/attachment.html>

From jbuchanan at presidio.com Mon Jan 21 10:30:54 2013


From: jbuchanan at presidio.com (Buchanan, James)
Date: Mon, 21 Jan 2013 15:30:54 +0000
Subject: [cisco-voip] VG224 to RightFax communication error issue
In-Reply-To:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
References:
<75778C6826D2F248A21C5F17308148542257BA02FA@USISPCLEXDB01.na.didata.local>
Message-ID: <12D6A6A157B44348974E5ED93738628C2536D547@HQEXCHMBX03.Presidio.Corp>

I had the same problems using MGCP recently and H323. I upgraded to 15.1(4)M4 (I
think) AND changed to T.38 version 3. This fixed my issues.

James Buchanan | Sr. Network Engineer


Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at
presidio.com<mailto:jbuchanan at presidio.com>
[Be Secure In The Knowledge]<http://www.presidio.com>

Follow us:

[Follow Presidio on Twitter]<http://www.twitter.com/presidio>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Kalyan Iyer (AM)
Sent: Friday, January 18, 2013 8:49 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] VG224 to RightFax communication error issue

I have a customer that has the following setup

Analog Fax -- > VG224 ---SCCP--- > CUCM ---H323--- > RightFax (virtual server)
Or
Analog Fax --- > EVM card on router --- H323 --- > CUCM ---H323--- > RightFax
(virtual server)

When they try to fax in to the RightFax server in both the scenarios, they hear the
fax tone but get a communication error. I was told that when they were using SIP
between CUCM and RightFax, it worked well. They are however able to fax out from
the RightFax server to the fax machine.

The VG224 configuration is attached. Any help will be appreciated.

Thanks

This message w/attachments (message) is intended solely for the use of the intended
recipient(s) and may contain information that is privileged, confidential or
proprietary. If you are not an intended recipient, please notify the sender, and
then please delete and destroy all copies and attachments. Please be advised that
any review or dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/b7639592/attachment.html>

From ealeatherman at gmail.com Mon Jan 21 11:13:33 2013


From: ealeatherman at gmail.com (Ed Leatherman)
Date: Mon, 21 Jan 2013 11:13:33 -0500
Subject: [cisco-voip] IPPA doesn't get custom layout data while ringing
after upgrade to ccx 8.5
Message-ID: <CAFC4dspZcscrgXbd4htk=Tb370a72ms-C4qc+zOcKcVri9y+9Q@mail.gmail.com>

Anyone run into a problem with IP Phone agent after upgrading to UCCX 8.5?

We just upgraded from 7.0 to 8.5.

We had one of our call centers configured to display the custom layout data
so the agent could see which CSQ the call came from. Worked fine in v7.

Now the data is still getting to the phone after the call begins but the
agent has to push cdata a softkey to see it. So I believe the layout is
configured correctly and in the script correctly, it just no longer pops
when the phone is ringing.
It seems like it could be a permissions issue where UCCX can't pop the data
to the phone anymore. I checked that telecaster was still associated to the
phones, and also looked in desktop admin to see if the telecaster user was
still specified. I explicitly set the password for that account to be sure
but haven't yet restarted the CAD services (will do that tonight after they
close).

Curious if anyone else had run into this problem before.

--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/2e0335c3/attachment.html>

From Edward.Countryman at presencehealth.org Mon Jan 21 11:14:00 2013


From: Edward.Countryman at presencehealth.org (Countryman, Edward)
Date: Mon, 21 Jan 2013 10:14:00 -0600
Subject: [cisco-voip] UCCX CSS ?
Message-ID: <3E508304295FC04988DFEEA1A2F177C3470B4B@AEXMV22.phnet.phroot.local>

Does anyone know if it?s possible to have a UCCX application use a different CSS
for redirecting a call then the one associated with the originating party? (We are
on version 7.0)

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/a092c3b9/attachment.html>

From PedersenE at bennettjones.com Mon Jan 21 13:59:47 2013


From: PedersenE at bennettjones.com (Eric Pedersen)
Date: Mon, 21 Jan 2013 18:59:47 +0000
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
Message-ID: <C77DDA7FB9437841BD08707193E4203314AFAD51@cv-exsvr2.Legal.bjlocal>

We call a different company's toll-free number that does the same thing. In our
case DTMF wasn't working at all, but that was with a SIP gateway. I did a bit of
digging, and the remote end played their IVR and expected input after an ISDN
PROGRESS, without ISDN CONNECT. From what I read ISDN PROGRESS is only for the
other party to play a recording, not receive any audio, so the GW didn't consider
the call set up and wouldn't send DTMF. I got the DTMF working by changing the
relay mechanism, but I just tried with Jabber and I experience the same problem as
you do.

Let me know if you get a bug ID and I'll open an SR on it so that it gets another
hit. IMO, it's the IVR that isn't configured properly but if it works calling from
a cell phone, it should work from a Cisco device also.

I was wondering why they would start their IVR that way... you're probably right
about it being toll avoidance.

Eric
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of c3voip
Sent: 16 January 2013 7:53 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Call not connecting, but it's connected

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call is
immediately answered by an auto-attendant, but the PRI channel does not show as
connected, so my phone does not show that the call is connected. This is obviously
some type of toll-charge avoidance. I have tried calling from my cellphone and the
behavior is the same...phone still displays "calling" even though the AA is
connected.

My problem is with trying to use Jabber either to control a hard phone or using it
as a soft phone, it cannot generate touch-tones to navigate the auto-attendant. In
the case of the soft phone, the keypad never becomes available in the GUI and
numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with these
calls?

Thanks,
-Chase

The contents of this message may contain confidential and/or privileged


subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/e441f130/attachment.html>

From abbaseo at gmail.com Mon Jan 21 14:15:13 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Mon, 21 Jan 2013 19:15:13 +0000
Subject: [cisco-voip] Tandberg E95 SIP reg
Message-ID: <CAFdHCp653+bAPY3TVdgpYaLLL-cX1iN4XsC155Lod7Cni329aw@mail.gmail.com>

Guys,

having issues registering Tandberg Edge 95 to CUCM 8.5 via SIP as per
attachements.
.75 is one of our Subs.
I have added it on the CM side as a basic 3rd Party SIP device with no
authentication.
not sure about the Display name and the SIP address in the photo 1.

Any Help.
We have though configured it as a H323 client and that works fine. just to
add it as SIP as well for more flex.

Thanks

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/0f645535/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: photo 1.JPG
Type: image/jpeg
Size: 391264 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/0f645535/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: photo 2.JPG
Type: image/jpeg
Size: 514486 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/0f645535/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: photo 3.JPG
Type: image/jpeg
Size: 427878 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/0f645535/attachment-0002.jpe>

From carlo_calabrese2006 at yahoo.com Mon Jan 21 16:50:29 2013


From: carlo_calabrese2006 at yahoo.com (Carlo)
Date: Mon, 21 Jan 2013 13:50:29 -0800
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <C77DDA7FB9437841BD08707193E4203314AFAD51@cv-exsvr2.Legal.bjlocal>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
<C77DDA7FB9437841BD08707193E4203314AFAD51@cv-exsvr2.Legal.bjlocal>
Message-ID: <F60BA18F-3F3A-46EC-9022-D13D600F674F@yahoo.com>

I don't think this is a bug. I ran into almost the same thing. Try this. on CUCM
int the sip profile, add the "Send PRACK for all 1xx messages". you may also need
to force early offer on the gateway.

Sent from my iPad

On Jan 21, 2013, at 10:59 AM, Eric Pedersen <PedersenE at bennettjones.com> wrote:

> We call a different company's toll-free number that does the same thing. In our
case DTMF wasn't working at all, but that was with a SIP gateway. I did a bit of
digging, and the remote end played their IVR and expected input after an ISDN
PROGRESS, without ISDN CONNECT. From what I read ISDN PROGRESS is only for the
other party to play a recording, not receive any audio, so the GW didn't consider
the call set up and wouldn't send DTMF. I got the DTMF working by changing the
relay mechanism, but I just tried with Jabber and I experience the same problem as
you do.
>
> Let me know if you get a bug ID and I'll open an SR on it so that it gets another
hit. IMO, it's the IVR that isn't configured properly but if it works calling from
a cell phone, it should work from a Cisco device also.
>
> I was wondering why they would start their IVR that way? you're probably right
about it being toll avoidance.
>
> Eric
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of c3voip
> Sent: 16 January 2013 7:53 AM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Call not connecting, but it's connected
>
> Hi,
>
> So when we try to call McAfee Gold Support line at 1-800-937-2237, our call is
immediately answered by an auto-attendant, but the PRI channel does not show as
connected, so my phone does not show that the call is connected. This is obviously
some type of toll-charge avoidance. I have tried calling from my cellphone and the
behavior is the same?phone still displays ?calling? even though the AA is
connected.
>
> My problem is with trying to use Jabber either to control a hard phone or using
it as a soft phone, it cannot generate touch-tones to navigate the auto-attendant.
In the case of the soft phone, the keypad never becomes available in the GUI and
numbers on the keyboard do nothing.
>
> Has anyone ever seen this and is there any way to get Jabber to work with these
calls?
>
> Thanks,
> -Chase
> The contents of this message may contain confidential and/or privileged
> subject matter. If this message has been received in error, please contact
> the sender and delete all copies. Like other forms of communication,
> e-mail communications may be vulnerable to interception by unauthorized
> parties. If you do not wish us to communicate with you by e-mail, please
> notify us at your earliest convenience. In the absence of such
> notification, your consent is assumed. Should you choose to allow us to
> communicate by e-mail, we will not take any additional security measures
> (such as encryption) unless specifically requested.
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/d49fb95c/attachment.html>

From mikeeo at msn.com Mon Jan 21 22:13:43 2013


From: mikeeo at msn.com (Mike )
Date: Mon, 21 Jan 2013 22:13:43 -0500
Subject: [cisco-voip] Unity Connection SMTP domain change
Message-ID: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>

Hi all. I have an issue where Unity connection 8.6 using single inbox sends
an email with username at unitycx.domain.com, but the users real email is
username at domain.com

Users want to be able to forward and reply to voicemails in there email


boxes to other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to
get Unity cx to send with username at domain.com? I've created SMTP proxy
addresses for everyone, but it still sends it with the unitycx.domain.com.

Thanks,

Mike

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/e71602f1/attachment.html>

From John.VanLaecke at ghd.com Mon Jan 21 23:07:26 2013


From: John.VanLaecke at ghd.com (John Van Laecke)
Date: Tue, 22 Jan 2013 04:07:26 +0000
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
Message-ID: <CF2E16827204E249BB155D2C1F5C1EAB1ABB5386@GLB-EXMBX-
001.ghdnet.internal>

Changing the smtp on 8.6 will make your license invalid so you will need to talk to
tac after changing.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Mike
Sent: Tuesday, 22 January 2013 1:14 PM
To: 'cisco voip'
Subject: [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends an
email with username at unitycx.domain.com<mailto:username at unitycx.domain.com>,
but the users real email is username at domain.com<mailto:username at domain.com>

Users want to be able to forward and reply to voicemails in there email boxes to
other users.
I read that changing the SMTP domain is a huge no no. Any ideas on how to get Unity
cx to send with username at domain.com<mailto:username at domain.com>? I've created
SMTP proxy addresses for everyone, but it still sends it with the
unitycx.domain.com.

Thanks,
Mike

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/fb98355e/attachment.html>

From pav.ccie at gmail.com Mon Jan 21 23:01:21 2013


From: pav.ccie at gmail.com (Pavan K)
Date: Mon, 21 Jan 2013 22:01:21 -0600
Subject: [cisco-voip] UCCX CSS ?
In-Reply-To: <3E508304295FC04988DFEEA1A2F177C3470B4B@AEXMV22.phnet.phroot.local>
References: <3E508304295FC04988DFEEA1A2F177C3470B4B@AEXMV22.phnet.phroot.local>
Message-ID: <CAJDPBuX0iLgd-zEBHz4s2svfwB-AcBfX9+2ksnt1p33hg1689Q@mail.gmail.com>

Edward,
Can you check if redirect CSS is a configurable setting under the ccx
triggers. It is there in 8.5, not sure about 7
On Jan 21, 2013 10:15 AM, "Countryman, Edward" <
Edward.Countryman at presencehealth.org> wrote:

> Does anyone know if it?s possible to have a UCCX application use a
> different CSS for redirecting a call then the one associated with the
> originating party? (We are on version 7.0)****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/ef2f10d0/attachment.html>

From jason.aarons at dimensiondata.com Mon Jan 21 23:31:16 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Mon, 21 Jan 2013 23:31:16 -0500
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>

If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.

Many small customer's will never go beyond a single CXN cluster.

Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Mike
Sent: Monday, January 21, 2013 10:14 PM
To: 'cisco voip'
Subject: [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends an
email with username at unitycx.domain.com<mailto:username at unitycx.domain.com>,
but the users real email is username at domain.com<mailto:username at domain.com>

Users want to be able to forward and reply to voicemails in there email boxes to
other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to get Unity
cx to send with username at domain.com<mailto:username at domain.com>? I've created
SMTP proxy addresses for everyone, but it still sends it with the
unitycx.domain.com.

Thanks,
Mike

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/a3510bde/attachment.html>

From Rynard.Coetzee at bytes.co.za Mon Jan 21 23:55:42 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Tue, 22 Jan 2013 04:55:42 +0000
Subject: [cisco-voip] Call drops after taking off hold
Message-ID: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a " Bearer capability not implemented" error. Any
ideas what the problem could be ?
Regards
Rynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/2892c3c5/attachment.html>

From John.VanLaecke at ghd.com Tue Jan 22 00:44:07 2013


From: John.VanLaecke at ghd.com (John Van Laecke)
Date: Tue, 22 Jan 2013 05:44:07 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
Message-ID: <CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-
001.ghdnet.internal>

Add bearer-cap speed to the voice port on the gateway

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Rynard Coetzee
Sent: Tuesday, 22 January 2013 2:56 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Call drops after taking off hold

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a " Bearer capability not implemented" error. Any
ideas what the problem could be ?
Regards
Rynard

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/35b145a9/attachment.html>

From Rynard.Coetzee at bytes.co.za Tue Jan 22 02:29:56 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Tue, 22 Jan 2013 07:29:56 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-
001.ghdnet.internal>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>,
<CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-001.ghdnet.internal>
Message-ID: <7FCB7A56-1ACA-45E0-BABC-BEFED30199A5@bytes.co.za>

I already have bearer-cap speech configured on voice-port

Sent from my iPhone

On 22 Jan 2013, at 7:46 AM, "John Van Laecke" <John.VanLaecke at


ghd.com<mailto:John.VanLaecke at ghd.com>> wrote:

Add bearer-cap speed to the voice port on the gateway


From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at
puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Rynard
Coetzee
Sent: Tuesday, 22 January 2013 2:56 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Call drops after taking off hold

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a ? Bearer capability not implemented? error. Any
ideas what the problem could be ?
Regards
Rynard

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/1ae28988/attachment.html>

From salamka at gmail.com Tue Jan 22 03:07:40 2013


From: salamka at gmail.com (Abdul Salam .)
Date: Tue, 22 Jan 2013 13:37:40 +0530
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <7FCB7A56-1ACA-45E0-BABC-BEFED30199A5@bytes.co.za>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-001.ghdnet.internal>
<7FCB7A56-1ACA-45E0-BABC-BEFED30199A5@bytes.co.za>
Message-ID: <CAKav0XQAwAF80_o7zBxxnSYSm9VhEYuzmudRpAMpTa0Hwn_g6w@mail.gmail.com>

Do u have some media inactivity related configuration ?

*---AS*

On Tue, Jan 22, 2013 at 12:59 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za
> wrote:

> I already have bearer-cap speech configured on voice-port


>
> Sent from my iPhone
>
> On 22 Jan 2013, at 7:46 AM, "John Van Laecke" <John.VanLaecke at ghd.com>
> wrote:
>
> Add bearer-cap speed to the voice port on the gateway****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Rynard Coetzee
> *Sent:* Tuesday, 22 January 2013 2:56 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] Call drops after taking off hold****
>
> ** **
>
> Hi****
>
> I have the following scenario at a client site ,call comes from PSTN via
> H323 GW ,I can answer the call and place the caller on hold ,when I try and
> resume the call ,the Telco drops the call with a ? Bearer capability not
> implemented? error. Any ideas what the problem could be ?****
>
> Regards****
>
> Rynard****
>
>
> _____________________
> This e-mail has been scanned for viruses by MessageLabs.****
>
> _____________________
> This email and all attachments are confidential. For further important
> information about emails sent to or from GHD or if you have received this
> email in error, please refer to http://www.ghd.com/emaildisclaimer.html .
> _____________________
> This e-mail has been scanned for viruses by MessageLabs.
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/01834a43/attachment.html>

From jason.aarons at dimensiondata.com Tue Jan 22 07:05:27 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Tue, 22 Jan 2013 07:05:27 -0500
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <CAKav0XQAwAF80_o7zBxxnSYSm9VhEYuzmudRpAMpTa0Hwn_g6w@mail.gmail.com>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-001.ghdnet.internal>
<7FCB7A56-1ACA-45E0-BABC-BEFED30199A5@bytes.co.za>
<CAKav0XQAwAF80_o7zBxxnSYSm9VhEYuzmudRpAMpTa0Hwn_g6w@mail.gmail.com>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BB7@USISPCLEXDB01.na.didata.local>

Under the gateway command I would look for inactivity commands.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Abdul Salam .
Sent: Tuesday, January 22, 2013 3:08 AM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold

Do u have some media inactivity related configuration ?

---AS

On Tue, Jan 22, 2013 at 12:59 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:
I already have bearer-cap speech configured on voice-port

Sent from my iPhone

On 22 Jan 2013, at 7:46 AM, "John Van Laecke" <John.VanLaecke at


ghd.com<mailto:John.VanLaecke at ghd.com>> wrote:
Add bearer-cap speed to the voice port on the gateway

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Rynard Coetzee
Sent: Tuesday, 22 January 2013 2:56 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Call drops after taking off hold

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a " Bearer capability not implemented" error. Any
ideas what the problem could be ?
Regards
Rynard

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
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/20130122/20aad8fe/attachment.html>

From chrward at cisco.com Tue Jan 22 09:57:34 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Tue, 22 Jan 2013 14:57:34 +0000
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>
Message-ID: <C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>

Leave your SMTP different. You need it for routing to work correctly.

The way to work around this is to setup an email address policy that associates the
connection email address with the corporate email address and sets the corp email
address as the default. Screenshots attached.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Monday, January 21, 2013 11:31 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.

Many small customer's will never go beyond a single CXN cluster.

Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 21, 2013 10:14 PM
To: 'cisco voip'
Subject: [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends an
email with username at unitycx.domain.com<mailto:username at unitycx.domain.com>,
but the users real email is username at domain.com<mailto:username at domain.com>
Users want to be able to forward and reply to voicemails in there email boxes to
other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to get Unity
cx to send with username at domain.com<mailto:username at domain.com>? I've created
SMTP proxy addresses for everyone, but it still sends it with the
unitycx.domain.com.

Thanks,
Mike

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/4c6d2918/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smtp3[6].png
Type: image/png
Size: 23834 bytes
Desc: smtp3[6].png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/4c6d2918/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smtp2_001[4].png
Type: image/png
Size: 9533 bytes
Desc: smtp2_001[4].png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/4c6d2918/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smtp1_001[2].png
Type: image/png
Size: 65206 bytes
Desc: smtp1_001[2].png
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/4c6d2918/attachment-0002.png>

From kenneth.rhodes at gmail.com Tue Jan 22 10:04:21 2013


From: kenneth.rhodes at gmail.com (Ken Rhodes)
Date: Tue, 22 Jan 2013 10:04:21 -0500
Subject: [cisco-voip] Cisco 8945 Phone Power issue
Message-ID: <E54808D1-5D58-42A1-9342-D742C94F72F4@gmail.com>

Wondering if anyone else has run into a situation where there the screen on an 8945
IP Phone goes black (and its not the energy savings feature) and only the MWI light
on the handset is lit as well as the speakerphone, mute, headset, and video buttons
all remain lit.

From ciscovoipuser at gmail.com Tue Jan 22 10:45:45 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Tue, 22 Jan 2013 15:45:45 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
Message-ID: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need
to configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any


recommendations from Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and
another for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with
best practice if I can.

Thanks,

Rab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/6515bd71/attachment.html>

From jason.aarons at dimensiondata.com Tue Jan 22 12:01:03 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Tue, 22 Jan 2013 12:01:03 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02D3C@USISPCLEXDB01.na.didata.local>

This gives some details on why ISO and VMs should be on separate I/O paths, along
with other hardware best practices.

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Reading/writing from a DVD iso image can be i/o intensive conflicting with i/o
needed for VMs. If you not really ever using the DVD ISOs but once for install you
may not need them separate.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Boon
Sent: Tuesday, January 22, 2013 10:46 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup

Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.
I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/ba3ff5b4/attachment.html>

From rratliff at cisco.com Tue Jan 22 12:04:26 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 22 Jan 2013 12:04:26 -0500
Subject: [cisco-voip] Call not connecting, but it's connected
In-Reply-To: <C77DDA7FB9437841BD08707193E4203314AFAD51@cv-exsvr2.Legal.bjlocal>
References: <000c01cdf3f9$2acc22c0$80646840$@nc.rr.com>
<C77DDA7FB9437841BD08707193E4203314AFAD51@cv-exsvr2.Legal.bjlocal>
Message-ID: <5EB6A6AD-1A7F-4737-A08C-5F87F0E405A4@cisco.com>

I reproduced this on our internal build of the Jabber Mac client and CSCue09571
ended up being filed. It appears CUCM cut through the audio with a 183 Progress
then sent a Subscribe to Jabber for kpml. It doesn't look like Jabber ever
responded to that Subscribe, my guess is because it didn't think the call was
connected.

I think a TAC SR is a good place to start, getting customer cases attached to a bug
(or even seeing if a separate bug is required for Jabber Windows) will help with
getting the fix prioritized.

-Ryan

On Jan 21, 2013, at 1:59 PM, Eric Pedersen <PedersenE at bennettjones.com> wrote:

We call a different company's toll-free number that does the same thing. In our
case DTMF wasn't working at all, but that was with a SIP gateway. I did a bit of
digging, and the remote end played their IVR and expected input after an ISDN
PROGRESS, without ISDN CONNECT. From what I read ISDN PROGRESS is only for the
other party to play a recording, not receive any audio, so the GW didn't consider
the call set up and wouldn't send DTMF. I got the DTMF working by changing the
relay mechanism, but I just tried with Jabber and I experience the same problem as
you do.

Let me know if you get a bug ID and I'll open an SR on it so that it gets another
hit. IMO, it's the IVR that isn't configured properly but if it works calling from
a cell phone, it should work from a Cisco device also.

I was wondering why they would start their IVR that way? you're probably right
about it being toll avoidance.
Eric

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of c3voip
Sent: 16 January 2013 7:53 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Call not connecting, but it's connected

Hi,

So when we try to call McAfee Gold Support line at 1-800-937-2237, our call is
immediately answered by an auto-attendant, but the PRI channel does not show as
connected, so my phone does not show that the call is connected. This is obviously
some type of toll-charge avoidance. I have tried calling from my cellphone and the
behavior is the same?phone still displays ?calling? even though the AA is
connected.

My problem is with trying to use Jabber either to control a hard phone or using it
as a soft phone, it cannot generate touch-tones to navigate the auto-attendant. In
the case of the soft phone, the keypad never becomes available in the GUI and
numbers on the keyboard do nothing.

Has anyone ever seen this and is there any way to get Jabber to work with these
calls?

Thanks,
-Chase
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/141f813b/attachment.html>

From rratliff at cisco.com Tue Jan 22 12:08:51 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 22 Jan 2013 12:08:51 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
Message-ID: <ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>

If you have a TRC then you can find instructions in here:


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html
If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:

Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/4663c453/attachment.html>

From SeniorJ at bennettjones.com Tue Jan 22 12:17:50 2013


From: SeniorJ at bennettjones.com (JP Senior)
Date: Tue, 22 Jan 2013 17:17:50 +0000
Subject: [cisco-voip] Jabber 9.1.1+ voicemails off by one hour due to
DST-type bug?
Message-ID: <3835CDF52CAD694FA34EF84033F445AA3CA808A4@cv-exsvr2.Legal.bjlocal>

Hello,
It seems as if Jabber 9.1.1 introduced a bug where voicemail would be off by an
hour. We were playing with local system clock settings and decided it was related
to DST, as non-DST time zones (eg Arizona) work fine. Jabber 9.1.0 was fine, 9.1.1
and 9.1.2 both have voicemail off by an hour.
We could not find anything in the Cisco bug tracker. Can anyone else confirm this
issue? Is anyone aware of a workaround?

Thanks!
-JP
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/491a03e5/attachment.html>

From ciscovoipuser at gmail.com Tue Jan 22 12:21:17 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Tue, 22 Jan 2013 17:21:17 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
Message-ID: <CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4


virtual drives with a dedicated one for VM onto which I have installed ESXi
hypervisor. Therefore I'm guessing that the two RAID arrays approach was
meant for earlier c-series models without flash cards right?

I've setup the HDD as a single RAID5 which is inline with the tested
reference guide on the UCS wiki. I just want to know if I can create a
single datastore or whether it's better practice to create two and keep the
ISO discs separate. I think the VM doc will give me the answer hopefully.
Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> If you have a TRC then you can find instructions in here:
>
>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html
>
> If you are specs-based, then it's expected you know how to structure your
> datastore(s) to meet your needs so there won't be specific instructions.
>
> All of our docs that I've run through have instructions for configuring
> two separate RAID arrays, one for ESXi and ISOs, and another for VMs. The
> ones I've done have been RAID 1 and RAID 5 (respectively) and these are
> usually done at the same time, before you install ESXi.
>
> -Ryan
>
> On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:
>
> Hi,
>
> I'm in the process of building my first C-Series UCS server from scratch.
>
> I've configured RAID, installed ESXi and have logged into vSphere. I need
> to configure a datastore which I'm ok with.
>
> I have a question regarding the datastore setup. Is there any
> recommendations from Cisco on how to configure these logically?
>
> I've seen a couple of installs that have two datastores, one for VMs and
> another for ISO images etc for quick rebuilds..
>
> I have a 1.9TB of disk space to use and I'd like to set it up in line with
> best practice if I can.
>
> Thanks,
>
> Rab
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/59c83b46/attachment.html>

From rratliff at cisco.com Tue Jan 22 17:37:53 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 22 Jan 2013 17:37:53 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
Message-ID: <16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>

Keep in mind that deviating from our install guides on a TRC drops you back to
specs-based support in terms of UC on UCS. Not that you will have any issues but
it is something you need to be aware of in the case that things really start to go
south.

I'm sure the 2 array configuration was done both data protection and for
performance. We haven't found any real benefit to using the flexible flash drives
for TRCs (since we aren't limited by disk space and the hypervisor mostly runs in
RAM anyway) which is why it isn't included in our guides.

-Ryan

On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4 virtual
drives with a dedicated one for VM onto which I have installed ESXi hypervisor.
Therefore I'm guessing that the two RAID arrays approach was meant for earlier c-
series models without flash cards right?

I've setup the HDD as a single RAID5 which is inline with the tested reference
guide on the UCS wiki. I just want to know if I can create a single datastore or
whether it's better practice to create two and keep the ISO discs separate. I think
the VM doc will give me the answer hopefully. Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
If you have a TRC then you can find instructions in here:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html

If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:

Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/8006cae6/attachment.html>

From btalley at gmail.com Tue Jan 22 19:27:32 2013


From: btalley at gmail.com (Bill Talley)
Date: Tue, 22 Jan 2013 18:27:32 -0600
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>
<C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>
Message-ID: <-7046328107004949020@unknownmsgid>

Since Single Inbox was released, this is the first definitive


recommendation I've seen on this. All other documents said if you were
using Viewmail, it was acceptable to change the smtp domain, but if not
using Viewmail, don't change it... Something along those lines, but the
documentation wasn't definitive as to whether it was ok to do or a no-no
(aka it was contradictory) </rambling>

This is a positive step along those lines.

Thanks Chris! I really appreciate your participation on this list (and


Ryan's, Wes', etc).

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

On Jan 22, 2013, at 9:04 AM, "Chris Ward (chrward)" <chrward at cisco.com>
wrote:

Leave your SMTP different. You need it for routing to work correctly.

The way to work around this is to setup an email address policy that
associates the connection email address with the corporate email address
and sets the corp email address as the default. Screenshots attached.

+Chris

Unity Connection TME

*From:* cisco-voip-bounces at puck.nether.net [


mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at
puck.nether.net>]
*On Behalf Of *Jason Aarons (AM)
*Sent:* Monday, January 21, 2013 11:31 PM
*To:* Mike ; 'cisco voip'
*Subject:* Re: [cisco-voip] Unity Connection SMTP domain change

If you are never going to have another CXN cluster and won?t need Unity
Networking then change the SMTP domain to match.
Many small customer?s will never go beyond a single CXN cluster.

Else it?s working as designed by Cisco and talk to your Cisco Account
Manager about a Product Enhancement Request (PERS) J

*From:* cisco-voip-bounces at puck.nether.net [


mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at
puck.nether.net>]
*On Behalf Of *Mike
*Sent:* Monday, January 21, 2013 10:14 PM
*To:* 'cisco voip'
*Subject:* [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends
an email with username at unitycx.domain.com, but the users real email is
username at domain.com

Users want to be able to forward and reply to voicemails in there email


boxes to other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to
get Unity cx to send with username at domain.com? I?ve created SMTP proxy
addresses for everyone, but it still sends it with the unitycx.domain.com.

Thanks,

Mike

itevomcid

<smtp3[6].png>

<smtp2_001[4].png>

<smtp1_001[2].png>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130122/0fb235d6/attachment.html>

From Rynard.Coetzee at bytes.co.za Tue Jan 22 23:46:14 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Wed, 23 Jan 2013 04:46:14 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BB7@USISPCLEXDB01.na.didata.local>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<CF2E16827204E249BB155D2C1F5C1EAB1ABB74B4@GLB-EXMBX-001.ghdnet.internal>
<7FCB7A56-1ACA-45E0-BABC-BEFED30199A5@bytes.co.za>
<CAKav0XQAwAF80_o7zBxxnSYSm9VhEYuzmudRpAMpTa0Hwn_g6w@mail.gmail.com>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BB7@USISPCLEXDB01.na.didata.local>
Message-ID: <97D19F256B859A48A6A93E8A9210E52A8432D128@BYTESEXCH2K10N1.bytes.local>

Hi
I do not have anything configured under gateway command ,also not sure if this is
just a coincidence but when I turn on MTP on the GW in CUCM ,it seems to resolve
the issue ?

From: Jason Aarons (AM) [mailto:jason.aarons at dimensiondata.com]


Sent: 22 January 2013 02:05 PM
To: Abdul Salam .; Rynard Coetzee
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Call drops after taking off hold

Under the gateway command I would look for inactivity commands.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Abdul Salam .
Sent: Tuesday, January 22, 2013 3:08 AM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Do u have some media inactivity related configuration ?

---AS

On Tue, Jan 22, 2013 at 12:59 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:
I already have bearer-cap speech configured on voice-port

Sent from my iPhone

On 22 Jan 2013, at 7:46 AM, "John Van Laecke" <John.VanLaecke at


ghd.com<mailto:John.VanLaecke at ghd.com>> wrote:
Add bearer-cap speed to the voice port on the gateway
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at
puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Rynard Coetzee
Sent: Tuesday, 22 January 2013 2:56 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Call drops after taking off hold

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a " Bearer capability not implemented" error. Any
ideas what the problem could be ?
Regards
Rynard

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
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/20130123/8948e3bc/attachment.html>

From ovi.popa at gmail.com Wed Jan 23 04:18:04 2013


From: ovi.popa at gmail.com (Ovidiu Popa)
Date: Wed, 23 Jan 2013 10:18:04 +0100
Subject: [cisco-voip] call hunting question
Message-ID: <CAHPHiz7SrP=oKvPuGcsH852VavHDSsGOmJcFENYzwKvh7CEi=g@mail.gmail.com>

Hello

Anyone know an sql command (or other method) to see the line state in the
line-groups ? I need to know if a user pressed the Hlog button.

Thank you,

Regards,
Ovidiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/9d17288c/attachment.html>
From willay at gmail.com Wed Jan 23 05:34:26 2013
From: willay at gmail.com (William)
Date: Wed, 23 Jan 2013 10:34:26 +0000
Subject: [cisco-voip] Cisco 7921/7925 call drop outs
Message-ID: <CACmo3cpyPv=pOJq+1Gc4UT_UecL7b6qhfvfUzoZSz5FzAUVLzw@mail.gmail.com>

Hi list,

I'm experiencing issues with our Cisco Call Manager system (6.1.4.2190-3) -
with our wireless handsets which are a 90/10 mix of 7921 and 7925 running
1.4(3).

The issue is during a call (internal or external) we experience gaps of


silence even when the callers are stationairy in the building (there is a
few roaming blackspots within the building but locations which were
preciously fine are now having issues).

I've not done much in terms of troubleshooting phone system issues, so any
advice would be appreciated? Just to clarify we have had no changes to our
wireless controller/network in the last month however a call manager
upgrade has been completed recently (almost 2 weeks ago) but the problems
with the wireless handsets have only been reported in the last 48 hours. We
have no issues with the fixed handsets.

Where should I start looking? Thank you for your time.

Kind Regards,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/4578d272/attachment.html>

From ciscovoipuser at gmail.com Wed Jan 23 06:25:53 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Wed, 23 Jan 2013 11:25:53 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
Message-ID: <CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>

Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3
provides steps indicating that that the HV should be installed on one of
the VD on the flash drive.

Are you saying that this should be ignored for UC on UCS installs and the
previous method of installing the HV on the HDD should be followed?

On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Keep in mind that deviating from our install guides on a TRC drops you
> back to specs-based support in terms of UC on UCS. Not that you will have
> any issues but it is something you need to be aware of in the case that
> things really start to go south.
>
> I'm sure the 2 array configuration was done both data protection and for
> performance. We haven't found any real benefit to using the flexible flash
> drives for TRCs (since we aren't limited by disk space and the hypervisor
> mostly runs in RAM anyway) which is why it isn't included in our guides.
>
> -Ryan
>
> On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:
>
> Thanks for the info Ryan and Jason.
>
> I'm deploying a C-220-M3 server with a Flexible Flash card which as 4
> virtual drives with a dedicated one for VM onto which I have installed ESXi
> hypervisor. Therefore I'm guessing that the two RAID arrays approach was
> meant for earlier c-series models without flash cards right?
>
> I've setup the HDD as a single RAID5 which is inline with the tested
> reference guide on the UCS wiki. I just want to know if I can create a
> single datastore or whether it's better practice to create two and keep the
> ISO discs separate. I think the VM doc will give me the answer hopefully.
> Thanks.
>
>
>
> On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> If you have a TRC then you can find instructions in here:
>>
>>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html
>>
>> If you are specs-based, then it's expected you know how to structure your
>> datastore(s) to meet your needs so there won't be specific instructions.
>>
>> All of our docs that I've run through have instructions for configuring
>> two separate RAID arrays, one for ESXi and ISOs, and another for VMs. The
>> ones I've done have been RAID 1 and RAID 5 (respectively) and these are
>> usually done at the same time, before you install ESXi.
>>
>> -Ryan
>>
>> On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:
>>
>> Hi,
>>
>> I'm in the process of building my first C-Series UCS server from scratch.
>>
>> I've configured RAID, installed ESXi and have logged into vSphere. I need
>> to configure a datastore which I'm ok with.
>>
>> I have a question regarding the datastore setup. Is there any
>> recommendations from Cisco on how to configure these logically?
>>
>> I've seen a couple of installs that have two datastores, one for VMs and
>> another for ISO images etc for quick rebuilds..
>>
>> I have a 1.9TB of disk space to use and I'd like to set it up in line
>> with best practice if I can.
>>
>> Thanks,
>>
>> Rab
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/a3b0c110/attachment.html>

From MLoraditch at heliontechnologies.com Wed Jan 23 06:37:19 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Wed, 23 Jan 2013 11:37:19 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
Message-ID: <C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>

FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server comes semi-
preconfigured and the HV is on a RAID 10 Virtual disk with a single datastore that
the ISOs and the VMs also go on.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Boon
Sent: Wednesday, January 23, 2013 6:26 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UC on UCS C-Series Datastore Setup
Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3 provides
steps indicating that that the HV should be installed on one of the VD on the flash
drive.

Are you saying that this should be ignored for UC on UCS installs and the previous
method of installing the HV on the HDD should be followed?

On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at


cisco.com<mailto:rratliff at cisco.com>> wrote:
Keep in mind that deviating from our install guides on a TRC drops you back to
specs-based support in terms of UC on UCS. Not that you will have any issues but
it is something you need to be aware of in the case that things really start to go
south.

I'm sure the 2 array configuration was done both data protection and for
performance. We haven't found any real benefit to using the flexible flash drives
for TRCs (since we aren't limited by disk space and the hypervisor mostly runs in
RAM anyway) which is why it isn't included in our guides.

-Ryan

On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com<mailto:ciscovoipuser


at gmail.com>> wrote:

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4 virtual
drives with a dedicated one for VM onto which I have installed ESXi hypervisor.
Therefore I'm guessing that the two RAID arrays approach was meant for earlier c-
series models without flash cards right?

I've setup the HDD as a single RAID5 which is inline with the tested reference
guide on the UCS wiki. I just want to know if I can create a single datastore or
whether it's better practice to create two and keep the ISO discs separate. I think
the VM doc will give me the answer hopefully. Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at


cisco.com<mailto:rratliff at cisco.com>> wrote:
If you have a TRC then you can find instructions in here:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html

If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com<mailto:ciscovoipuser


at gmail.com>> wrote:

Hi,

I'm in the process of building my first C-Series UCS server from scratch.
I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/3e2b5508/attachment.html>

From ciscovoipuser at gmail.com Wed Jan 23 07:07:02 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Wed, 23 Jan 2013 12:07:02 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
<C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
Message-ID: <CACue4GhuXkV3i8=+6ce17gZCwEbyuZAkYSMLwfnXq6noGd+jjQ@mail.gmail.com>

Ok thanks all. I found my answer here:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper
_c11-718938.html

*"After you enable the virtual drives, you will be able to access them from
the BIOS for bootup or, in the case of the HV partition, for installation
of a bootable image."*
*
*
It seems that I misread the docs and the flex flash drive HV partition
should be used for storing a bootable ESXi ISO and not for installation of
the OS.
On Wed, Jan 23, 2013 at 11:37 AM, Matthew Loraditch <
MLoraditch at heliontechnologies.com> wrote:

> FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server
> comes semi-preconfigured and the HV is on a RAID 10 Virtual disk with a
> single datastore that the ISOs and the VMs also go on.****
>
> ** **
>
> ** **
>
> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
> ****
>
> ** **
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Boon
> *Sent:* Wednesday, January 23, 2013 6:26 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] UC on UCS C-Series Datastore Setup****
>
> ** **
>
> Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3
> provides steps indicating that that the HV should be installed on one of
> the VD on the flash drive. ****
>
> ** **
>
> Are you saying that this should be ignored for UC on UCS installs and the
> previous method of installing the HV on the HDD should be followed?****
>
> ** **
>
> On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> ****
>
> Keep in mind that deviating from our install guides on a TRC drops you
> back to specs-based support in terms of UC on UCS. Not that you will have
> any issues but it is something you need to be aware of in the case that
> things really start to go south. ****
>
> ** **
>
> I'm sure the 2 array configuration was done both data protection and for
> performance. We haven't found any real benefit to using the flexible flash
> drives for TRCs (since we aren't limited by disk space and the hypervisor
> mostly runs in RAM anyway) which is why it isn't included in our guides.**
> **
>
> ** **
>
> -Ryan ****
>
> ** **
>
> On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:****
>
> ** **
>
> Thanks for the info Ryan and Jason. ****
>
> ** **
>
> I'm deploying a C-220-M3 server with a Flexible Flash card which as 4
> virtual drives with a dedicated one for VM onto which I have installed ESXi
> hypervisor. Therefore I'm guessing that the two RAID arrays approach was
> meant for earlier c-series models without flash cards right?****
>
> ** **
>
> I've setup the HDD as a single RAID5 which is inline with the tested
> reference guide on the UCS wiki. I just want to know if I can create a
> single datastore or whether it's better practice to create two and keep the
> ISO discs separate. I think the VM doc will give me the answer hopefully.
> Thanks.****
>
> ** **
>
> ** **
>
> On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:*
> ***
>
> If you have a TRC then you can find instructions in here:****
>
>
>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html
> ****
>
> ** **
>
> If you are specs-based, then it's expected you know how to structure your
> datastore(s) to meet your needs so there won't be specific instructions.**
> **
>
> ** **
>
> All of our docs that I've run through have instructions for configuring
> two separate RAID arrays, one for ESXi and ISOs, and another for VMs. The
> ones I've done have been RAID 1 and RAID 5 (respectively) and these are
> usually done at the same time, before you install ESXi. ****
>
> ** **
>
> -Ryan ****
>
> ** **
>
> On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:****
>
> ** **
>
> Hi, ****
>
> ** **
>
> I'm in the process of building my first C-Series UCS server from scratch.
> ****
>
> ** **
>
> I've configured RAID, installed ESXi and have logged into vSphere. I need
> to configure a datastore which I'm ok with. ****
>
> ** **
>
> I have a question regarding the datastore setup. Is there any
> recommendations from Cisco on how to configure these logically?****
>
> ** **
>
> I've seen a couple of installs that have two datastores, one for VMs and
> another for ISO images etc for quick rebuilds..****
>
> ** **
>
> I have a 1.9TB of disk space to use and I'd like to set it up in line with
> best practice if I can. ****
>
>
> Thanks, ****
>
>
> Rab****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/f65e11d3/attachment.html>

From Bernhard.Reindl at kapsch.net Wed Jan 23 07:25:21 2013


From: Bernhard.Reindl at kapsch.net (Reindl Bernhard)
Date: Wed, 23 Jan 2013 13:25:21 +0100
Subject: [cisco-voip] Display Picture from external camera on Cisco
9951/9971 Phone
Message-ID: <BA1882010711A440B1F8184D1A05B0DF50385E6DF3@S064B252.kapsch.co.at>

Hi all

Is someone aware of bringing a picture from an external source (Sony CH160) to the
display of a cisco 9951/9971 phone.

I have already tried with different resolutions 320x240 / 640x480 but I always get
a http error message, when I point from the phone (registered with CME 8.6) over
URL Button to the weblink.

When I select the link with IE from a pc, then I can see a "oneshotimage".

Also the camera would be ready for H264, as I know the phone too, but also this
negotiation is failing.

Regards
br

The information contained in this e-mail message is privileged and


confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents
thereof, and is kindly asked to notify the sender and delete the e-mail
immediately.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/2ccdd950/attachment.html>

From abbaseo at gmail.com Wed Jan 23 08:21:11 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Wed, 23 Jan 2013 13:21:11 +0000
Subject: [cisco-voip] Tandberg E95 SIP reg
In-Reply-To: <CAFTaN40wbdSLjeR2D80sS+TuNPgUN+r0qgBTnHheuVr0SCWdyQ@mail.gmail.com>
References: <CAFdHCp653+bAPY3TVdgpYaLLL-cX1iN4XsC155Lod7Cni329aw@mail.gmail.com>
<CAFTaN40wbdSLjeR2D80sS+TuNPgUN+r0qgBTnHheuVr0SCWdyQ@mail.gmail.com>
Message-ID: <CAFdHCp7e-Q76dCyG1iPgYQQrQOtKJHuafvBacCTjcnJm9SpApQ@mail.gmail.com>

I have used the below link to reg. my two VC units as SIP. but they can
only make voice based calls and the video which is set to the default is
not working.

any ideas!!

thanks all.

On 21 January 2013 19:37, Florian Kroessbacher <


florian.kroessbacher at gmail.com> wrote:

> Hy
>
> Maybe this helps
> https://supportforums.cisco.com/thread/2151443
>
> cheers Floh
>
> Florian Kroessbacher
>
> gmail: florian.kroessbacher at gmail.com
>
>
> On Mon, Jan 21, 2013 at 8:15 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
>> Guys,
>>
>> having issues registering Tandberg Edge 95 to CUCM 8.5 via SIP as per
>> attachements.
>> .75 is one of our Subs.
>> I have added it on the CM side as a basic 3rd Party SIP device with no
>> authentication.
>> not sure about the Display name and the SIP address in the photo 1.
>>
>> Any Help.
>>
>> We have though configured it as a H323 client and that works fine. just
>> to add it as SIP as well for more flex.
>>
>> Thanks
>>
>> --
>> @bbas..
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/82e5270a/attachment.html>
From rratliff at cisco.com Wed Jan 23 09:24:52 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 23 Jan 2013 09:24:52 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
<C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
Message-ID: <FA53EAD0-FF77-4130-8250-EA05DC68C98A@cisco.com>

This could depend on the server. The 220M3 TRC2 for BE6k should have two volumes,
according to
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html#CUCM_TK_SF3C701F_00.

-Ryan

On Jan 23, 2013, at 6:37 AM, Matthew Loraditch <MLoraditch at


heliontechnologies.com> wrote:

FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server comes semi-
preconfigured and the HV is on a RAID 10 Virtual disk with a single datastore that
the ISOs and the VMs also go on.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Boon
Sent: Wednesday, January 23, 2013 6:26 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UC on UCS C-Series Datastore Setup

Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3 provides
steps indicating that that the HV should be installed on one of the VD on the flash
drive.

Are you saying that this should be ignored for UC on UCS installs and the previous
method of installing the HV on the HDD should be followed?

On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Keep in mind that deviating from our install guides on a TRC drops you back to
specs-based support in terms of UC on UCS. Not that you will have any issues but
it is something you need to be aware of in the case that things really start to go
south.
I'm sure the 2 array configuration was done both data protection and for
performance. We haven't found any real benefit to using the flexible flash drives
for TRCs (since we aren't limited by disk space and the hypervisor mostly runs in
RAM anyway) which is why it isn't included in our guides.

-Ryan

On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4 virtual
drives with a dedicated one for VM onto which I have installed ESXi hypervisor.
Therefore I'm guessing that the two RAID arrays approach was meant for earlier c-
series models without flash cards right?

I've setup the HDD as a single RAID5 which is inline with the tested reference
guide on the UCS wiki. I just want to know if I can create a single datastore or
whether it's better practice to create two and keep the ISO discs separate. I think
the VM doc will give me the answer hopefully. Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
If you have a TRC then you can find instructions in here:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html

If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:

Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,
Rab
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/2ae45e7b/attachment.html>

From rratliff at cisco.com Wed Jan 23 09:35:15 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 23 Jan 2013 09:35:15 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4GhuXkV3i8=+6ce17gZCwEbyuZAkYSMLwfnXq6noGd+jjQ@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
<C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
<CACue4GhuXkV3i8=+6ce17gZCwEbyuZAkYSMLwfnXq6noGd+jjQ@mail.gmail.com>
Message-ID: <7443E763-4777-4676-A5D9-B1E727AAFDC8@cisco.com>

How the server is configured is entirely dependent on what you purchased. If you
bought a TRC (with a voice sku) then in order to be supported as a TRC it needs to
be configured as such. If you did a custom build or a datacenter sku for the UCS
then you'll be specs-based support (for UC apps) and can configure it to meet your
needs.

-Ryan

On Jan 23, 2013, at 7:07 AM, Boon <ciscovoipuser at gmail.com> wrote:

Ok thanks all. I found my answer here:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper
_c11-718938.html

"After you enable the virtual drives, you will be able to access them from the BIOS
for bootup or, in the case of the HV partition, for installation of a bootable
image."

It seems that I misread the docs and the flex flash drive HV partition should be
used for storing a bootable ESXi ISO and not for installation of the OS.
On Wed, Jan 23, 2013 at 11:37 AM, Matthew Loraditch <MLoraditch at
heliontechnologies.com> wrote:
FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server comes semi-
preconfigured and the HV is on a RAID 10 Virtual disk with a single datastore that
the ISOs and the VMs also go on.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Boon
Sent: Wednesday, January 23, 2013 6:26 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UC on UCS C-Series Datastore Setup

Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3 provides
steps indicating that that the HV should be installed on one of the VD on the flash
drive.

Are you saying that this should be ignored for UC on UCS installs and the previous
method of installing the HV on the HDD should be followed?

On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

Keep in mind that deviating from our install guides on a TRC drops you back to
specs-based support in terms of UC on UCS. Not that you will have any issues but
it is something you need to be aware of in the case that things really start to go
south.

I'm sure the 2 array configuration was done both data protection and for
performance. We haven't found any real benefit to using the flexible flash drives
for TRCs (since we aren't limited by disk space and the hypervisor mostly runs in
RAM anyway) which is why it isn't included in our guides.
-Ryan

On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4 virtual
drives with a dedicated one for VM onto which I have installed ESXi hypervisor.
Therefore I'm guessing that the two RAID arrays approach was meant for earlier c-
series models without flash cards right?

I've setup the HDD as a single RAID5 which is inline with the tested reference
guide on the UCS wiki. I just want to know if I can create a single datastore or
whether it's better practice to create two and keep the ISO discs separate. I think
the VM doc will give me the answer hopefully. Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

If you have a TRC then you can find instructions in here:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html

If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:

Hi,
I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..

I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/817ebb80/attachment.html>
From rratliff at cisco.com Wed Jan 23 10:04:31 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 23 Jan 2013 10:04:31 -0500
Subject: [cisco-voip] call hunting question
In-Reply-To: <CAHPHiz7SrP=oKvPuGcsH852VavHDSsGOmJcFENYzwKvh7CEi=g@mail.gmail.com>
References: <CAHPHiz7SrP=oKvPuGcsH852VavHDSsGOmJcFENYzwKvh7CEi=g@mail.gmail.com>
Message-ID: <45B73F53-A569-47DC-9BC4-93ED9DCBC5FE@cisco.com>

The table you want to query is devicehlogdynamic where it's hlog column is a
boolean and fkdevice points to the pkid of an entry in the device table.

-Ryan

On Jan 23, 2013, at 4:18 AM, Ovidiu Popa <ovi.popa at gmail.com> wrote:

Hello

Anyone know an sql command (or other method) to see the line state in the line-
groups ? I need to know if a user pressed the Hlog button.

Thank you,

Regards,
Ovidiu
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/05eac4ad/attachment.html>

From ciscovoipuser at gmail.com Wed Jan 23 10:35:52 2013


From: ciscovoipuser at gmail.com (Boon)
Date: Wed, 23 Jan 2013 15:35:52 +0000
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <7443E763-4777-4676-A5D9-B1E727AAFDC8@cisco.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
<C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
<CACue4GhuXkV3i8=+6ce17gZCwEbyuZAkYSMLwfnXq6noGd+jjQ@mail.gmail.com>
<7443E763-4777-4676-A5D9-B1E727AAFDC8@cisco.com>
Message-ID: <CACue4GimT62MZaFdwyFZpmbYkesmw5qYRAXHWsy68hGULpoYDQ@mail.gmail.com>

The server was ordered in line with 'C220 M3S (SFF) TRC#1' so I'm assuming
I'm all set to follow the guide?

On Wed, Jan 23, 2013 at 2:35 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> How the server is configured is entirely dependent on what you purchased.
> If you bought a TRC (with a voice sku) then in order to be supported as a
> TRC it needs to be configured as such. If you did a custom build or a
> datacenter sku for the UCS then you'll be specs-based support (for UC apps)
> and can configure it to meet your needs.
>
> -Ryan
>
> On Jan 23, 2013, at 7:07 AM, Boon <ciscovoipuser at gmail.com> wrote:
>
> Ok thanks all. I found my answer here:
>
>
>
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper
_c11-718938.html
>
> *"After you enable the virtual drives, you will be able to access them
> from the BIOS for bootup or, in the case of the HV partition, for
> installation of a bootable image."*
> *
> *
> It seems that I misread the docs and the flex flash drive HV partition
> should be used for storing a bootable ESXi ISO and not for installation of
> the OS.
>
>
> On Wed, Jan 23, 2013 at 11:37 AM, Matthew Loraditch <
> MLoraditch at heliontechnologies.com> wrote:
>
>> FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server
>> comes semi-preconfigured and the HV is on a RAID 10 Virtual disk with a
>> single datastore that the ISOs and the VMs also go on.****
>>
>> ** **
>>
>> ** **
>>
>> 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<support at
heliontechnologies.com?subject=Technical%20Support%20Request>
>> ****
>>
>> ** **
>>
>> ** **
>>
>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Boon
>> *Sent:* Wednesday, January 23, 2013 6:26 PM
>> *To:* cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] UC on UCS C-Series Datastore Setup****
>>
>> ** **
>>
>> Thanks Ryan. It's confusing as the setup guide that comes with the
>> C220-M3 provides steps indicating that that the HV should be installed on
>> one of the VD on the flash drive. ****
>>
>> ** **
>>
>> Are you saying that this should be ignored for UC on UCS installs and the
>> previous method of installing the HV on the HDD should be followed?****
>>
>> ** **
>>
>> On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com>
>> wrote:****
>>
>> Keep in mind that deviating from our install guides on a TRC drops you
>> back to specs-based support in terms of UC on UCS. Not that you will have
>> any issues but it is something you need to be aware of in the case that
>> things really start to go south. ****
>>
>> ** **
>>
>> I'm sure the 2 array configuration was done both data protection and for
>> performance. We haven't found any real benefit to using the flexible flash
>> drives for TRCs (since we aren't limited by disk space and the hypervisor
>> mostly runs in RAM anyway) which is why it isn't included in our guides.*
>> ***
>>
>> ** **
>>
>> -Ryan ****
>>
>> ** **
>>
>> On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:****
>>
>> ** **
>>
>> Thanks for the info Ryan and Jason. ****
>>
>> ** **
>>
>> I'm deploying a C-220-M3 server with a Flexible Flash card which as 4
>> virtual drives with a dedicated one for VM onto which I have installed ESXi
>> hypervisor. Therefore I'm guessing that the two RAID arrays approach was
>> meant for earlier c-series models without flash cards right?****
>>
>> ** **
>>
>> I've setup the HDD as a single RAID5 which is inline with the tested
>> reference guide on the UCS wiki. I just want to know if I can create a
>> single datastore or whether it's better practice to create two and keep the
>> ISO discs separate. I think the VM doc will give me the answer hopefully.
>> Thanks.****
>>
>> ** **
>>
>> ** **
>>
>> On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>> ****
>>
>> If you have a TRC then you can find instructions in here:****
>>
>>
>>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html
>> ****
>>
>> ** **
>>
>> If you are specs-based, then it's expected you know how to structure your
>> datastore(s) to meet your needs so there won't be specific instructions.*
>> ***
>>
>> ** **
>>
>> All of our docs that I've run through have instructions for configuring
>> two separate RAID arrays, one for ESXi and ISOs, and another for VMs. The
>> ones I've done have been RAID 1 and RAID 5 (respectively) and these are
>> usually done at the same time, before you install ESXi. ****
>>
>> ** **
>>
>> -Ryan ****
>>
>> ** **
>>
>> On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:****
>>
>> ** **
>>
>> Hi, ****
>>
>> ** **
>>
>> I'm in the process of building my first C-Series UCS server from scratch.
>> ****
>>
>> ** **
>>
>> I've configured RAID, installed ESXi and have logged into vSphere. I need
>> to configure a datastore which I'm ok with. ****
>>
>> ** **
>>
>> I have a question regarding the datastore setup. Is there any
>> recommendations from Cisco on how to configure these logically?****
>>
>> ** **
>>
>> I've seen a couple of installs that have two datastores, one for VMs and
>> another for ISO images etc for quick rebuilds..****
>>
>> ** **
>>
>> I have a 1.9TB of disk space to use and I'd like to set it up in line
>> with best practice if I can. ****
>>
>>
>> Thanks, ****
>>
>>
>> Rab****
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip****
>>
>> ** **
>>
>> ** **
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip****
>>
>> ** **
>>
>> ** **
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/d7cbe9e7/attachment.html>

From rratliff at cisco.com Wed Jan 23 11:12:01 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 23 Jan 2013 11:12:01 -0500
Subject: [cisco-voip] UC on UCS C-Series Datastore Setup
In-Reply-To: <CACue4GimT62MZaFdwyFZpmbYkesmw5qYRAXHWsy68hGULpoYDQ@mail.gmail.com>
References: <CACue4Gg=f5wqhuHyBUvczmPHFb765hm6DdaJAro=n=CCHfzVBg@mail.gmail.com>
<ADE75999-ABCB-4B14-92F4-E6E7C3C10164@cisco.com>
<CACue4GjEZZCS+frLoWZe0FU_tF79AZxcEM9mAuyvjNhYeTrrJQ@mail.gmail.com>
<16723BBF-3261-4FCF-A415-9F6CAF97C2CF@cisco.com>
<CACue4Gi4zYUCAF4fxhLFm6zmg5DanoMNshLhgYLWypEhLAPLyg@mail.gmail.com>
<C75AF2AD9308C246AFBDDB994E3E2983110CCF9F@PHANES.helion.local>
<CACue4GhuXkV3i8=+6ce17gZCwEbyuZAkYSMLwfnXq6noGd+jjQ@mail.gmail.com>
<7443E763-4777-4676-A5D9-B1E727AAFDC8@cisco.com>
<CACue4GimT62MZaFdwyFZpmbYkesmw5qYRAXHWsy68hGULpoYDQ@mail.gmail.com>
Message-ID: <C9F9BF08-5BA6-4EB5-8949-A555E3015DCF@cisco.com>
This is the doc you would follow for that TRC.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html#CUCM_TP_C1BA71A6_00

-Ryan

On Jan 23, 2013, at 10:35 AM, Boon <ciscovoipuser at gmail.com> wrote:

The server was ordered in line with 'C220 M3S (SFF) TRC#1' so I'm assuming I'm all
set to follow the guide?

On Wed, Jan 23, 2013 at 2:35 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
How the server is configured is entirely dependent on what you purchased. If you
bought a TRC (with a voice sku) then in order to be supported as a TRC it needs to
be configured as such. If you did a custom build or a datacenter sku for the UCS
then you'll be specs-based support (for UC apps) and can configure it to meet your
needs.

-Ryan

On Jan 23, 2013, at 7:07 AM, Boon <ciscovoipuser at gmail.com> wrote:

Ok thanks all. I found my answer here:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper
_c11-718938.html

"After you enable the virtual drives, you will be able to access them from the BIOS
for bootup or, in the case of the HV partition, for installation of a bootable
image."

It seems that I misread the docs and the flex flash drive HV partition should be
used for storing a bootable ESXi ISO and not for installation of the OS.

On Wed, Jan 23, 2013 at 11:37 AM, Matthew Loraditch <MLoraditch at


heliontechnologies.com> wrote:
FWIW as an additional datapoint, For CMBE6K 9.0 new orders, the server comes semi-
preconfigured and the HV is on a RAID 10 Virtual disk with a single datastore that
the ISOs and the VMs also go on.

Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA

1965 Greenspring Drive


Timonium, MD 21093

voice. 410.252.8830
fax. 410.252.9284

Twitter | Facebook | Website | Email Support


From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Boon
Sent: Wednesday, January 23, 2013 6:26 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UC on UCS C-Series Datastore Setup

Thanks Ryan. It's confusing as the setup guide that comes with the C220-M3 provides
steps indicating that that the HV should be installed on one of the VD on the flash
drive.

Are you saying that this should be ignored for UC on UCS installs and the previous
method of installing the HV on the HDD should be followed?

On Tue, Jan 22, 2013 at 10:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

Keep in mind that deviating from our install guides on a TRC drops you back to
specs-based support in terms of UC on UCS. Not that you will have any issues but
it is something you need to be aware of in the case that things really start to go
south.

I'm sure the 2 array configuration was done both data protection and for
performance. We haven't found any real benefit to using the flexible flash drives
for TRCs (since we aren't limited by disk space and the hypervisor mostly runs in
RAM anyway) which is why it isn't included in our guides.

-Ryan

On Jan 22, 2013, at 12:21 PM, Boon <ciscovoipuser at gmail.com> wrote:

Thanks for the info Ryan and Jason.

I'm deploying a C-220-M3 server with a Flexible Flash card which as 4 virtual
drives with a dedicated one for VM onto which I have installed ESXi hypervisor.
Therefore I'm guessing that the two RAID arrays approach was meant for earlier c-
series models without flash cards right?
I've setup the HDD as a single RAID5 which is inline with the tested reference
guide on the UCS wiki. I just want to know if I can create a single datastore or
whether it's better practice to create two and keep the ISO discs separate. I think
the VM doc will give me the answer hopefully. Thanks.

On Tue, Jan 22, 2013 at 5:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

If you have a TRC then you can find instructions in here:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm
-on-virtualized-servers_chapter_00.html

If you are specs-based, then it's expected you know how to structure your
datastore(s) to meet your needs so there won't be specific instructions.

All of our docs that I've run through have instructions for configuring two
separate RAID arrays, one for ESXi and ISOs, and another for VMs. The ones I've
done have been RAID 1 and RAID 5 (respectively) and these are usually done at the
same time, before you install ESXi.

-Ryan

On Jan 22, 2013, at 10:45 AM, Boon <ciscovoipuser at gmail.com> wrote:

Hi,

I'm in the process of building my first C-Series UCS server from scratch.

I've configured RAID, installed ESXi and have logged into vSphere. I need to
configure a datastore which I'm ok with.

I have a question regarding the datastore setup. Is there any recommendations from
Cisco on how to configure these logically?

I've seen a couple of installs that have two datastores, one for VMs and another
for ISO images etc for quick rebuilds..
I have a 1.9TB of disk space to use and I'd like to set it up in line with best
practice if I can.

Thanks,

Rab

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/40e14a45/attachment.html>

From tednugent73 at gmail.com Wed Jan 23 12:36:46 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Wed, 23 Jan 2013 12:36:46 -0500
Subject: [cisco-voip] Making a message appear anonymous/unknown via single
inbox
Message-ID: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>

CM 8.6, Unity Connection 8.6 and Exchange 2010


Customer has an anonymous tip line that is using single inbox and would
like the messages to showup as anonymous or unknown as opposed to showing
the callers name and/or phone number.
I've attempted to strip off the calling party info by washing it through a
translation pattern and setting the calling party name/line presention to
restricted and that doesn't work, I also attempted to setup a Hunt Pilot
and setting the calling party presention to restricted as well and in both
scenarios the email arrives displaying the callers info. Does anyone have
any ideas to accomplish this? Either via CM, Unity Connection or Exchange?
TIA Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/2c8e1cca/attachment.html>

From florian.kroessbacher at gmail.com Wed Jan 23 13:42:43 2013


From: florian.kroessbacher at gmail.com (Florian Kroessbacher)
Date: Wed, 23 Jan 2013 19:42:43 +0100
Subject: [cisco-voip] Tandberg E95 SIP reg
In-Reply-To: <CAFdHCp7e-Q76dCyG1iPgYQQrQOtKJHuafvBacCTjcnJm9SpApQ@mail.gmail.com>
References: <CAFdHCp653+bAPY3TVdgpYaLLL-cX1iN4XsC155Lod7Cni329aw@mail.gmail.com>
<CAFTaN40wbdSLjeR2D80sS+TuNPgUN+r0qgBTnHheuVr0SCWdyQ@mail.gmail.com>
<CAFdHCp7e-Q76dCyG1iPgYQQrQOtKJHuafvBacCTjcnJm9SpApQ@mail.gmail.com>
Message-ID: <FD04C6C9-0BBD-40C4-A0BC-B56A043ACEA7@gmail.com>

hy,

are the vc standard based sip devices likeu mentioned below. i think it has to be
enhanced one to do video

--
Florian Kroessbacher
gmail: florian.kroessbacher at gmail.com

Am 23.01.2013 um 14:21 schrieb abbas Wali <abbaseo at gmail.com>:

> I have used the below link to reg. my two VC units as SIP. but they can only make
voice based calls and the video which is set to the default is not working.
>
> any ideas!!
>
> thanks all.
>
> On 21 January 2013 19:37, Florian Kroessbacher <florian.kroessbacher at
gmail.com> wrote:
>> Hy
>>
>> Maybe this helps
>> https://supportforums.cisco.com/thread/2151443
>>
>> cheers Floh
>>
>> Florian Kroessbacher
>>
>> gmail: florian.kroessbacher at gmail.com
>>
>>
>> On Mon, Jan 21, 2013 at 8:15 PM, abbas Wali <abbaseo at gmail.com> wrote:
>>> Guys,
>>>
>>> having issues registering Tandberg Edge 95 to CUCM 8.5 via SIP as per
attachements.
>>> .75 is one of our Subs.
>>> I have added it on the CM side as a basic 3rd Party SIP device with no
authentication.
>>> not sure about the Display name and the SIP address in the photo 1.
>>>
>>> Any Help.
>>>
>>> We have though configured it as a H323 client and that works fine. just to add
it as SIP as well for more flex.
>>>
>>> Thanks
>>>
>>> --
>>> @bbas..
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> --
> @bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/2f478da3/attachment.html>

From chrward at cisco.com Wed Jan 23 13:55:20 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Wed, 23 Jan 2013 18:55:20 +0000
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
Message-ID: <C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>

Ted,

Removing the calling party information from the call before it gets to CUC is
definitely the way to do this. So, I think you are on the right track.

Now, as to why it's not working, there are a few things you could try. As a test, I
would setup a translation pattern to strip the calling information and then forward
it to your desk phone (making sure you don't receive calling party information) so
you can make sure that the translation pattern is doing what you think it is.

Also, how are you routing this specific call to CUC? Are you using a dummy CTI RP
and just setting it to CFA to CUC? And is the integration SCCP or SIP to CUC?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ted Nugent
Sent: Wednesday, January 23, 2013 12:37 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] Making a message appear anonymous/unknown via single inbox

CM 8.6, Unity Connection 8.6 and Exchange 2010


Customer has an anonymous tip line that is using single inbox and would like the
messages to showup as anonymous or unknown as opposed to showing the callers name
and/or phone number.
I've attempted to strip off the calling party info by washing it through a
translation pattern and setting the calling party name/line presention to
restricted and that doesn't work, I also attempted to setup a Hunt Pilot and
setting the calling party presention to restricted as well and in both scenarios
the email arrives displaying the callers info. Does anyone have any ideas to
accomplish this? Either via CM, Unity Connection or Exchange?
TIA Ted

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/5d0ada1d/attachment.html>

From tednugent73 at gmail.com Wed Jan 23 17:08:43 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Wed, 23 Jan 2013 17:08:43 -0500
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
Message-ID: <CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>

Chris thanks for the reply, Yes it is stripping the info washing it through
a TP, the phone I'm calling shows "Private". While using the TP method I'm
basically using the Direct to voicemail (*XXXX) VM profile which is
CFWDAll to VM on a CTI-RP.
For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM

However using the Huntpilot way, I have a HP going directly to HL/LG


containing the VM Ports and a Directed routing rule going to the subscriber
greeting. The HP is configured calling party name/line presention to
restricted, same as i did with the TP

As mention both have the same affect?

This is an SCCP integration with CUC and we get the same results via
external calls from an MGCP controlled PRI and SIP/SCCP phones

Any thoughts?
Thanks
Ted

On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at cisco.com>wrote:

> Ted,****
>
> ** **
>
> Removing the calling party information from the call before it gets to CUC
> is definitely the way to do this. So, I think you are on the right track.*
> ***
>
> ** **
>
> Now, as to why it?s not working, there are a few things you could try. As
> a test, I would setup a translation pattern to strip the calling
> information and then forward it to your desk phone (making sure you don?t
> receive calling party information) so you can make sure that the
> translation pattern is doing what you think it is.****
>
> ** **
>
> Also, how are you routing this specific call to CUC? Are you using a dummy
> CTI RP and just setting it to CFA to CUC? And is the integration SCCP or
> SIP to CUC?****
>
> ** **
>
> +Chris****
>
> Unity Connection TME****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
> *Sent:* Wednesday, January 23, 2013 12:37 PM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ** **
>
> CM 8.6, Unity Connection 8.6 and Exchange 2010****
>
> Customer has an anonymous tip line that is using single inbox and would
> like the messages to showup as anonymous or unknown as opposed to showing
> the callers name and/or phone number.****
>
> I've attempted to strip off the calling party info by washing it through a
> translation pattern and setting the calling party name/line presention to
> restricted and that doesn't work, I also attempted to setup a Hunt Pilot
> and setting the calling party presention to restricted as well and in both
> scenarios the email arrives displaying the callers info. Does anyone have
> any ideas to accomplish this? Either via CM, Unity Connection or Exchange?
> ****
>
> TIA Ted****
>
> ****
>
> ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/5d9cff33/attachment.html>

From chrward at cisco.com Wed Jan 23 17:57:12 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Wed, 23 Jan 2013 22:57:12 +0000
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
<CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
Message-ID: <C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>

Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning
if you don't hear from me. :)

+Chris
Unity Connection TME

From: Ted Nugent [mailto:tednugent73 at gmail.com]


Sent: Wednesday, January 23, 2013 5:09 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single
inbox

Chris thanks for the reply, Yes it is stripping the info washing it through a TP,
the phone I'm calling shows "Private". While using the TP method I'm basically
using the Direct to voicemail (*XXXX) VM profile which is CFWDAll to VM on a CTI-
RP.
For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM

However using the Huntpilot way, I have a HP going directly to HL/LG containing the
VM Ports and a Directed routing rule going to the subscriber greeting. The HP is
configured calling party name/line presention to restricted, same as i did with the
TP

As mention both have the same affect?

This is an SCCP integration with CUC and we get the same results via external calls
from an MGCP controlled PRI and SIP/SCCP phones

Any thoughts?
Thanks
Ted
On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at
cisco.com<mailto:chrward at cisco.com>> wrote:
Ted,

Removing the calling party information from the call before it gets to CUC is
definitely the way to do this. So, I think you are on the right track.

Now, as to why it's not working, there are a few things you could try. As a test, I
would setup a translation pattern to strip the calling information and then forward
it to your desk phone (making sure you don't receive calling party information) so
you can make sure that the translation pattern is doing what you think it is.

Also, how are you routing this specific call to CUC? Are you using a dummy CTI RP
and just setting it to CFA to CUC? And is the integration SCCP or SIP to CUC?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Ted Nugent
Sent: Wednesday, January 23, 2013 12:37 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] Making a message appear anonymous/unknown via single inbox

CM 8.6, Unity Connection 8.6 and Exchange 2010


Customer has an anonymous tip line that is using single inbox and would like the
messages to showup as anonymous or unknown as opposed to showing the callers name
and/or phone number.
I've attempted to strip off the calling party info by washing it through a
translation pattern and setting the calling party name/line presention to
restricted and that doesn't work, I also attempted to setup a Hunt Pilot and
setting the calling party presention to restricted as well and in both scenarios
the email arrives displaying the callers info. Does anyone have any ideas to
accomplish this? Either via CM, Unity Connection or Exchange?
TIA Ted

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/17892868/attachment.html>

From tednugent73 at gmail.com Wed Jan 23 18:46:59 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Wed, 23 Jan 2013 18:46:59 -0500
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
<CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>
Message-ID: <CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>

Will do thanks!
On Jan 23, 2013 5:57 PM, "Chris Ward (chrward)" <chrward at cisco.com> wrote:

> Let me try it out in my lab tomorrow and get back to you. Remind me
> Friday morning if you don?t hear from me. J****
>
> ** **
>
> +Chris****
>
> Unity Connection TME****
>
> ** **
>
> *From:* Ted Nugent [mailto:tednugent73 at gmail.com]
> *Sent:* Wednesday, January 23, 2013 5:09 PM
> *To:* Chris Ward (chrward)
> *Cc:* Cisco VoIPoE List
> *Subject:* Re: [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ** **
>
> Chris thanks for the reply, Yes it is stripping the info washing it
> through a TP, the phone I'm calling shows "Private". While using the TP
> method I'm basically using the Direct to voicemail (*XXXX) VM profile
> which is CFWDAll to VM on a CTI-RP. ****
>
> For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM****
>
> ****
>
> However using the Huntpilot way, I have a HP going directly to HL/LG
> containing the VM Ports and a Directed routing rule going to the subscriber
> greeting. The HP is configured calling party name/line presention to
> restricted, same as i did with the TP****
>
> ****
>
> As mention both have the same affect?****
>
> ****
>
> This is an SCCP integration with CUC and we get the same results via
> external calls from an MGCP controlled PRI and SIP/SCCP phones****
>
> ****
>
> Any thoughts?****
>
> Thanks****
>
> Ted****
>
> On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at cisco.com>
> wrote:****
>
> Ted,****
>
> ****
>
> Removing the calling party information from the call before it gets to CUC
> is definitely the way to do this. So, I think you are on the right track.*
> ***
>
> ****
>
> Now, as to why it?s not working, there are a few things you could try. As
> a test, I would setup a translation pattern to strip the calling
> information and then forward it to your desk phone (making sure you don?t
> receive calling party information) so you can make sure that the
> translation pattern is doing what you think it is.****
>
> ****
>
> Also, how are you routing this specific call to CUC? Are you using a dummy
> CTI RP and just setting it to CFA to CUC? And is the integration SCCP or
> SIP to CUC?****
>
> ****
>
> +Chris****
>
> Unity Connection TME****
>
> ****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
> *Sent:* Wednesday, January 23, 2013 12:37 PM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ****
>
> CM 8.6, Unity Connection 8.6 and Exchange 2010****
>
> Customer has an anonymous tip line that is using single inbox and would
> like the messages to showup as anonymous or unknown as opposed to showing
> the callers name and/or phone number.****
>
> I've attempted to strip off the calling party info by washing it through a
> translation pattern and setting the calling party name/line presention to
> restricted and that doesn't work, I also attempted to setup a Hunt Pilot
> and setting the calling party presention to restricted as well and in both
> scenarios the email arrives displaying the callers info. Does anyone have
> any ideas to accomplish this? Either via CM, Unity Connection or Exchange?
> ****
>
> TIA Ted****
>
> ****
>
> ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/ff838691/attachment.html>

From mikeeo at msn.com Wed Jan 23 19:54:51 2013


From: mikeeo at msn.com (Mike )
Date: Wed, 23 Jan 2013 19:54:51 -0500
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>
<C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>
Message-ID: <BLU0-SMTP1361A0110799E0EC7CEB538C5140@phx.gbl>

Thanks Chris I presented this to the customer and let them make the call.

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Chris Ward
(chrward)
Sent: Tuesday, January 22, 2013 9:58 AM
To: Jason Aarons (AM); Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

Leave your SMTP different. You need it for routing to work correctly.

The way to work around this is to setup an email address policy that
associates the connection email address with the corporate email address and
sets the corp email address as the default. Screenshots attached.

+Chris

Unity Connection TME

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Monday, January 21, 2013 11:31 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

If you are never going to have another CXN cluster and won't need Unity
Networking then change the SMTP domain to match.

Many small customer's will never go beyond a single CXN cluster.

Else it's working as designed by Cisco and talk to your Cisco Account
Manager about a Product Enhancement Request (PERS) J

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 21, 2013 10:14 PM
To: 'cisco voip'
Subject: [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends
an email with username at unitycx.domain.com, but the users real email is
username at domain.com

Users want to be able to forward and reply to voicemails in there email


boxes to other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to
get Unity cx to send with username at domain.com? I've created SMTP proxy
addresses for everyone, but it still sends it with the unitycx.domain.com.

Thanks,

Mike

itevomcid

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/a6424d7d/attachment.html>

From Dennis.Heim at wwt.com Wed Jan 23 20:07:56 2013


From: Dennis.Heim at wwt.com (Heim, Dennis)
Date: Wed, 23 Jan 2013 19:07:56 -0600
Subject: [cisco-voip] Unity Connection SMTP domain change
In-Reply-To: <BLU0-SMTP1361A0110799E0EC7CEB538C5140@phx.gbl>
References: <BLU0-SMTP18064F5EF7C38C3F4FB99B7C5160@phx.gbl>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DA02BAE@USISPCLEXDB01.na.didata.local>
<C3D1FCA271936B48839E081F898E17AA1FE735@xmb-rcd-x13.cisco.com>
<BLU0-SMTP1361A0110799E0EC7CEB538C5140@phx.gbl>
Message-ID: <0CC57FCAB07CEB4595526952471493D316F2584A7D@PRODCMS1.wwt.local>

The other caveat of changing it is if you ever want to use speechview.

Dennis Heim | Sr. Unified Collaboration Team Lead


World Wide Technology | 314.212.1814 | dennis.heim at wwt.com<mailto:dennis.heim at
wwt.com>
"Creating Impact, Ignition & Scalability"

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Mike
Sent: Wednesday, January 23, 2013 7:55 PM
To: 'Chris Ward (chrward)'; 'Jason Aarons (AM)'; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

Thanks Chris I presented this to the customer and let them make the call.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Chris Ward (chrward)
Sent: Tuesday, January 22, 2013 9:58 AM
To: Jason Aarons (AM); Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

Leave your SMTP different. You need it for routing to work correctly.

The way to work around this is to setup an email address policy that associates the
connection email address with the corporate email address and sets the corp email
address as the default. Screenshots attached.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason
Aarons (AM)
Sent: Monday, January 21, 2013 11:31 PM
To: Mike ; 'cisco voip'
Subject: Re: [cisco-voip] Unity Connection SMTP domain change

If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.

Many small customer's will never go beyond a single CXN cluster.

Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Sent: Monday, January 21, 2013 10:14 PM
To: 'cisco voip'
Subject: [cisco-voip] Unity Connection SMTP domain change

Hi all. I have an issue where Unity connection 8.6 using single inbox sends an
email with username at unitycx.domain.com<mailto:username at unitycx.domain.com>,
but the users real email is username at domain.com<mailto:username at domain.com>

Users want to be able to forward and reply to voicemails in there email boxes to
other users.

I read that changing the SMTP domain is a huge no no. Any ideas on how to get Unity
cx to send with username at domain.com<mailto:username at domain.com>? I've created
SMTP proxy addresses for everyone, but it still sends it with the
unitycx.domain.com.

Thanks,
Mike

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/e3fb3ebf/attachment.html>

From VanMarenNP at ldschurch.org Thu Jan 24 09:13:37 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Thu, 24 Jan 2013 14:13:37 +0000
Subject: [cisco-voip] Making a message appear anonymous/unknown
via single inbox
In-Reply-To: <CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
<CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>
<CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>
Message-ID: <2F143E71016CA34C924BF4C33AEF211056E8E39D@W12112.ldschurch.org>

Remember that Private just sets a bit that says don't display it, It doesn't
actually remove the information.

You might want to look at setting it to a value, maybe 0000000000 would work.

-Nate

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ted Nugent
Sent: Wednesday, January 23, 2013 4:47 PM
To: Chris Ward, (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single
inbox

Will do thanks!
On Jan 23, 2013 5:57 PM, "Chris Ward (chrward)" <chrward at
cisco.com<mailto:chrward at cisco.com>> wrote:
Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning
if you don't hear from me. :)

+Chris
Unity Connection TME

From: Ted Nugent [mailto:tednugent73 at gmail.com<mailto:tednugent73 at gmail.com>]


Sent: Wednesday, January 23, 2013 5:09 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single
inbox

Chris thanks for the reply, Yes it is stripping the info washing it through a TP,
the phone I'm calling shows "Private". While using the TP method I'm basically
using the Direct to voicemail (*XXXX) VM profile which is CFWDAll to VM on a CTI-
RP.
For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM

However using the Huntpilot way, I have a HP going directly to HL/LG containing the
VM Ports and a Directed routing rule going to the subscriber greeting. The HP is
configured calling party name/line presention to restricted, same as i did with the
TP

As mention both have the same affect?

This is an SCCP integration with CUC and we get the same results via external calls
from an MGCP controlled PRI and SIP/SCCP phones

Any thoughts?
Thanks
Ted
On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at
cisco.com<mailto:chrward at cisco.com>> wrote:
Ted,
Removing the calling party information from the call before it gets to CUC is
definitely the way to do this. So, I think you are on the right track.

Now, as to why it's not working, there are a few things you could try. As a test, I
would setup a translation pattern to strip the calling information and then forward
it to your desk phone (making sure you don't receive calling party information) so
you can make sure that the translation pattern is doing what you think it is.

Also, how are you routing this specific call to CUC? Are you using a dummy CTI RP
and just setting it to CFA to CUC? And is the integration SCCP or SIP to CUC?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Ted Nugent
Sent: Wednesday, January 23, 2013 12:37 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] Making a message appear anonymous/unknown via single inbox

CM 8.6, Unity Connection 8.6 and Exchange 2010


Customer has an anonymous tip line that is using single inbox and would like the
messages to showup as anonymous or unknown as opposed to showing the callers name
and/or phone number.
I've attempted to strip off the calling party info by washing it through a
translation pattern and setting the calling party name/line presention to
restricted and that doesn't work, I also attempted to setup a Hunt Pilot and
setting the calling party presention to restricted as well and in both scenarios
the email arrives displaying the callers info. Does anyone have any ideas to
accomplish this? Either via CM, Unity Connection or Exchange?
TIA Ted

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/512a3e56/attachment.html>

From ahmed_elnagar at hotmail.com Thu Jan 24 11:55:23 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Thu, 24 Jan 2013 18:55:23 +0200
Subject: [cisco-voip] Database Replication fails
Message-ID: <BAY002-W2925E4179A3ACE57068C2487140@phx.gbl>

I am having the below issue with


one subscriber ?my setup is one publisher and two subscribers?
From the Publisher I have the
below:

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

Cluster Replication State: BROADCAST SYNC Completed on 1


servers at: 2013-01-24-19-11

Last Sync Result: SYNC


COMPLETED 541 tables sync'ed out of 541

Sync Errors: 1 Errors or failures


were found

Use this command to see the output


- file view activelog
/cm/trace/dbl/2013_01_24_19_10_13_dbl_repl_cdr_Broadcast.log

DB Version: ccm8_6_2_22900_9

Number of replicated tables: 541

Cluster Detailed View from PUB (3 Servers):

PING
REPLICATION REPL. DBver&
REPL. REPLICATION SETUP

SERVER-NAME IP
ADDRESS (msec) RPC?
STATUS QUEUE
TABLES LOOP? (RTMT) & details

-----------
------------ ------ ----
----------- ----- ------- -----
-----------------

PUB 10.x.x.x
0.033 Yes
Connected
0 match
Yes (2) PUB Setup Completed

SUB01 10.x.x.y
0.115 Yes
Connected
0 match
Yes (2) Setup Completed

SUB02 10.x.x.z
0.107 Yes
Off-Line N/A
0 N/A (0) Not
Setup

admin:

and on the publisher I see this


for the 2nd subscriber I am having an issue with

admin:file view activelog cm/log/informix/ccm.log

19:16:17 Password Validation for user [dblpm] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0:


errstr = dblpm at SUB02: User (dblpm at SUB02)'s password is not correct for the
database server.

19:16:17 Password Validation for user [dbmon] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0:


errstr = dbmon at SUB02: User (dbmon at SUB02)'s password is not correct for the
database server.

19:16:17 Password Validation for user [dbris] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0:


errstr = dbris at SUB02: User (dbris at SUB02)'s password is not correct for the
database server.

19:16:19 Password Validation for user [dbauditlog]


failed!

19:16:19 Check for password aging/account lock-out.


19:16:19 listener-thread: err = -952: oserr = 0:
errstr = dbauditlog at SUB02: User (dbauditlog at SUB02)'s password is not correct
for the database server.

19:16:20 Password Validation for user [dbmon] failed!

19:16:20 Check for password aging/account lock-out.

19:16:20 listener-thread: err = -952: oserr = 0:


errstr = dbmon at SUB02: User (dbmon at SUB02)'s password is not correct for the
database server.

options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 -


20 of 5708) :

admin:

I am sure that security password


is the same everywhere, what do you think the problem is?

Thanks,
Ahmed Elnagar

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/d093bf1b/attachment.html>

From ahmed_elnagar at hotmail.com Thu Jan 24 12:36:26 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Thu, 24 Jan 2013 19:36:26 +0200
Subject: [cisco-voip] Database Replication fails
In-Reply-To:
<75778C6826D2F248A21C5F17308148542259099ADC@USISPCLEXDB01.na.didata.local>
References: <BAY002-W2925E4179A3ACE57068C2487140@phx.gbl>,
<75778C6826D2F248A21C5F17308148542259099ADC@USISPCLEXDB01.na.didata.local>
Message-ID: <BAY002-W226C62D821397259130882287140@phx.gbl>

What happened is

I installed Pub and Sub, but configured 3 server "system>server" then when tried to
install the 3rd one RAID failure "RMA bla bla" new hardware come after two months
"during which I changed the security password.

Now I install normally and having the below issue after installtion "even now
reverted back to the old password on all servers :("

I opened a TAC for this now.

Thanks,
Ahmed Elnagar
From: kalyan.iyer at dimensiondata.com
To: ahmed_elnagar at hotmail.com
Date: Thu, 24 Jan 2013 12:28:53 -0500
Subject: RE: [cisco-voip] Database Replication fails

Ahmed, Was the security password changed recently? I ran into the same bug on CUCM
8.5 once, when I tried to add a Sub to an existing cluster and the security
password was misplaced and I had to change it using the pwrecovery option and
reboot it. I was able to add the Sub during the installation but the replication
failed. The symptoms seem to be the same. It?s something to do with the way the
password gets hashed after changing it. This is a known bug on CUCM 8.5 and only
TAC can fix this by running a script. Thanks,Kalyan From: cisco-voip-bounces at
puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed
Elnagar
Sent: Thursday, January 24, 2013 11:55 AM
To: VOIP Group; rratliff at cisco.com
Subject: [cisco-voip] Database Replication fails I am having the below issue with
one subscriber ?my setup is one publisher and two subscribers? From the Publisher I
have the below: admin:utils dbreplication runtimestate DB and Replication
Services: ALL RUNNINGCluster Replication State: BROADCAST SYNC Completed on 1
servers at: 2013-01-24-19-11 Last Sync Result: SYNC COMPLETED 541 tables
sync'ed out of 541 Sync Errors: 1 Errors or failures were found Use this
command to see the output - file view activelog
/cm/trace/dbl/2013_01_24_19_10_13_dbl_repl_cdr_Broadcast.logDB Version:
ccm8_6_2_22900_9Number of replicated tables: 541 Cluster Detailed View from PUB (3
Servers): PING REPLICATION REPL.
DBver& REPL. REPLICATION SETUPSERVER-NAME IP ADDRESS (msec) RPC?
STATUS QUEUE TABLES LOOP? (RTMT) & details -----------
------------ ------ ---- ----------- ----- ------- -----
-----------------PUB 10.x.x.x 0.033 Yes Connected 0 match
Yes (2) PUB Setup CompletedSUB01 10.x.x.y 0.115 Yes Connected
0 match Yes (2) Setup CompletedSUB02 10.x.x.z 0.107 Yes
Off-Line N/A 0 N/A (0) Not Setup admin: and on the publisher
I see this for the 2nd subscriber I am having an issue with admin:file view
activelog cm/log/informix/ccm.log 19:16:17 Password Validation for user [dblpm]
failed!19:16:17 Check for password aging/account lock-out.19:16:17 listener-
thread: err = -952: oserr = 0: errstr = dblpm at SUB02: User (dblpm at SUB02)'s
password is not correct for the database server. 19:16:17 Password Validation for
user [dbmon] failed!19:16:17 Check for password aging/account lock-out.19:16:17
listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User (dbmon at
SUB02)'s password is not correct for the database server. 19:16:17 Password
Validation for user [dbris] failed!19:16:17 Check for password aging/account lock-
out.19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbris at SUB02: User
(dbris at SUB02)'s password is not correct for the database server. 19:16:19
Password Validation for user [dbauditlog] failed!19:16:19 Check for password
aging/account lock-out.19:16:19 listener-thread: err = -952: oserr = 0: errstr =
dbauditlog at SUB02: User (dbauditlog at SUB02)'s password is not correct for the
database server. 19:16:20 Password Validation for user [dbmon] failed!19:16:20
Check for password aging/account lock-out.19:16:20 listener-thread: err = -952:
oserr = 0: errstr = dbmon at SUB02: User (dbmon at SUB02)'s password is not correct
for the database server. options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 -
20 of 5708) : admin: I am sure that security password is the same everywhere, what
do you think the problem is? Thanks,
Ahmed Elnagar

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/e6dcf86d/attachment.html>

From david.Cooke at td.com Thu Jan 24 13:07:37 2013


From: david.Cooke at td.com (Cooke, Dave)
Date: Thu, 24 Jan 2013 13:07:37 -0500
Subject: [cisco-voip] List Users in CUC 8.6
Message-ID: <B2EFD7619F56A14783B1F0170ABF3B0E011C2C4380@EX7T2-CV10.TDBFG.COM>

Trying to list users with by assigned roles is this possible? Thanks

Thank you,

David Cooke
Senior Engineer, Team Lead
Technology Solutions, Contact Center Infrastructure
TD Bank, Americas Most Convenient Bank
17000 Horizon Way
Mount Laurel, NJ 08054
AIM # NJ5-005-173
(o) 856.470.3400
(f) 856.533.2852
(e) david.cooke at td.com<mailto:david.cooke at td.com> - New Email Address as of
8/31/2011

This message and any attachments may contain confidential or privileged information
and are intended only for the use of the intended recipients of this message. If
you are not the intended recipient of this message, please notify the sender by
return email, and delete this and all copies of this message and any attachments
from your system. Any unauthorized disclosure, use, distribution, or reproduction
of this message or any attachments is prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/b33b15e1/attachment.html>

From chrward at cisco.com Thu Jan 24 15:16:46 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Thu, 24 Jan 2013 20:16:46 +0000
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
<CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>
<CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>
Message-ID: <C3D1FCA271936B48839E081F898E17AA201665@xmb-rcd-x13.cisco.com>

Hi Ted,

Seems like you are hitting some known limitations. The settings in CUCM for
restricting Calling Party Information don't really eliminate it, it seems to just
mark it as "Restricted" so the information remains and CUC seems hell-bent on
finding calling party information.

I did find 2 solutions for you, both of which use SIP:

1) Setup an additional integration between CUCM and CUC that is meant only for
this anonymous line. In the SIP trunk config, you have to uncheck the "Remote-
Party-Id" under the "Call Routing Information" section and make sure "Calling Line
ID Presentation" is set to Restricted under the "Outbound Calls" section. This will
result in an "Unknown CallerID" message in Outlook.

2) Setup a Loopback SIP trunk for calls to this specific Anonymous DID. You
only need one SIP trunk to point to CUCMs own IP address, it acts as the outbound
and inbound SIP trunk in this scenario. Under the "Outbound Calls" section, you
would need define a Calling Party Transformation CSS that would have access to a
transformation pattern that matches all Calling parties (remembering that only
calls to this anonymous DID are affected) and mask the calling party with some
obscure mask like 0000 or you can put a . at the end of the pattern you match and
then drop all pre-dot if you want it blank. On the route pattern that points to
this loopback SIP trunk, you would modify the called party so that once the call
re-enters CUCM, it will be destined for the *7999 number (pulled from you example
before) and continues through the normal process to be forwarded to voicemail.

Neither solution is super-attractive, but both will work. I personally like #2


since it means you won't have split up your CUC ports for a separate SIP
integration. Let me know if you have any questions. It is probably a little more
involved than the description I provided.

+Chris
Unity Connection TME

From: Ted Nugent [mailto:tednugent73 at gmail.com]


Sent: Wednesday, January 23, 2013 6:47 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: RE: [cisco-voip] Making a message appear anonymous/unknown via single
inbox

Will do thanks!
On Jan 23, 2013 5:57 PM, "Chris Ward (chrward)" <chrward at
cisco.com<mailto:chrward at cisco.com>> wrote:
Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning
if you don't hear from me. :)

+Chris
Unity Connection TME

From: Ted Nugent [mailto:tednugent73 at gmail.com<mailto:tednugent73 at gmail.com>]


Sent: Wednesday, January 23, 2013 5:09 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single
inbox

Chris thanks for the reply, Yes it is stripping the info washing it through a TP,
the phone I'm calling shows "Private". While using the TP method I'm basically
using the Direct to voicemail (*XXXX) VM profile which is CFWDAll to VM on a CTI-
RP.
For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM

However using the Huntpilot way, I have a HP going directly to HL/LG containing the
VM Ports and a Directed routing rule going to the subscriber greeting. The HP is
configured calling party name/line presention to restricted, same as i did with the
TP

As mention both have the same affect?

This is an SCCP integration with CUC and we get the same results via external calls
from an MGCP controlled PRI and SIP/SCCP phones

Any thoughts?
Thanks
Ted
On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at
cisco.com<mailto:chrward at cisco.com>> wrote:
Ted,

Removing the calling party information from the call before it gets to CUC is
definitely the way to do this. So, I think you are on the right track.

Now, as to why it's not working, there are a few things you could try. As a test, I
would setup a translation pattern to strip the calling information and then forward
it to your desk phone (making sure you don't receive calling party information) so
you can make sure that the translation pattern is doing what you think it is.

Also, how are you routing this specific call to CUC? Are you using a dummy CTI RP
and just setting it to CFA to CUC? And is the integration SCCP or SIP to CUC?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-
bounces at puck.nether.net>] On Behalf Of Ted Nugent
Sent: Wednesday, January 23, 2013 12:37 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] Making a message appear anonymous/unknown via single inbox

CM 8.6, Unity Connection 8.6 and Exchange 2010


Customer has an anonymous tip line that is using single inbox and would like the
messages to showup as anonymous or unknown as opposed to showing the callers name
and/or phone number.
I've attempted to strip off the calling party info by washing it through a
translation pattern and setting the calling party name/line presention to
restricted and that doesn't work, I also attempted to setup a Hunt Pilot and
setting the calling party presention to restricted as well and in both scenarios
the email arrives displaying the callers info. Does anyone have any ideas to
accomplish this? Either via CM, Unity Connection or Exchange?
TIA Ted

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/9bb8c924/attachment.html>
From chrward at cisco.com Thu Jan 24 15:19:29 2013
From: chrward at cisco.com (Chris Ward (chrward))
Date: Thu, 24 Jan 2013 20:19:29 +0000
Subject: [cisco-voip] License migration: 8.6 -> 9.0
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056E71580@W12112.ldschurch.org>
References: <CAMX+=-X2NE+DguYETCZ4TOJoC=Hbj27=TxCDwnh7tfBb=FDnRA@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E71580@W12112.ldschurch.org>
Message-ID: <C3D1FCA271936B48839E081F898E17AA20168B@xmb-rcd-x13.cisco.com>

For all those who are interested. Here is the Migration Guide I spoke of last week.
Here is also a link to a web version:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/elmuserguide/9_1_1/license_migra
tion/CUCM_BK_CBF8B56A_00_cucm-license-upgrade-guide_chapter_00.html

Pay special attention to the Server table to find out your best migration path and
feel free to hit me up with any questions/comments.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Nate VanMaren
Sent: Monday, January 14, 2013 11:45 AM
To: Jos? Paulo de Oliveira Petry; Cisco VoIPoE List
Subject: Re: [cisco-voip] License migration: 8.6 -> 9.0

Run from 9.0 and do 9.1. You'll have to redo all of the licenses when you go to
9.1 anyways.

All of the 9.0 upgrades that I did the ELM work flawlessly once the ESXi host that
it was on had a proper NIC teaming configuration.

-Nate

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jos?
Paulo de Oliveira Petry
Sent: Monday, January 14, 2013 9:43 AM
To: Cisco VoIPoE List
Subject: [cisco-voip] License migration: 8.6 -> 9.0

Hello,

I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.

To migrate licenses (DLU to CUWL) im using this doc:


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/migratn.html#wp1067112

After i add the CUCM instance, im trying to use the Migration Utility, but im
receiving this error:

"There are no Unified CM product instances with pre-9.0 licenses available for
upgrade"

Any suggestion?

Regards,
Jos? Paulo de Oliveira Petry
petrybr at gmail.com<mailto:petrybr at gmail.com>

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/ac7442e0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Operational Guide for Cisco Unified Communications Manager.pdf
Type: application/pdf
Size: 779813 bytes
Desc: Operational Guide for Cisco Unified Communications Manager.pdf
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/ac7442e0/attachment.pdf>

From tman701 at gmail.com Thu Jan 24 15:54:12 2013


From: tman701 at gmail.com (Joel Perez)
Date: Thu, 24 Jan 2013 15:54:12 -0500
Subject: [cisco-voip] License migration: 8.6 -> 9.0
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA20168B@xmb-rcd-x13.cisco.com>
References: <CAMX+=-X2NE+DguYETCZ4TOJoC=Hbj27=TxCDwnh7tfBb=FDnRA@mail.gmail.com>
<2F143E71016CA34C924BF4C33AEF211056E71580@W12112.ldschurch.org>
<C3D1FCA271936B48839E081F898E17AA20168B@xmb-rcd-x13.cisco.com>
Message-ID: <CABdWoUGmOtmV2OQ_vj5d4RD3R1u1ETKH=0MVyBP_YSn+tP0n0g@mail.gmail.com>

Nice doc Chris, appreciate it.

Joel P.

On Thu, Jan 24, 2013 at 3:19 PM, Chris Ward (chrward) <chrward at cisco.com>wrote:

> For all those who are interested. Here is the Migration Guide I spoke of
> last week. Here is also a link to a web version:****
>
> ** **
>
>
>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/elmuserguide/9_1_1/license_migra
tion/CUCM_BK_CBF8B56A_00_cucm-license-upgrade-guide_chapter_00.html
> ****
>
> ** **
>
> Pay special attention to the Server table to find out your best migration
> path and feel free to hit me up with any questions/comments.****
>
> ** **
>
> +Chris****
>
> Unity Connection TME****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Nate VanMaren
> *Sent:* Monday, January 14, 2013 11:45 AM
> *To:* Jos? Paulo de Oliveira Petry; Cisco VoIPoE List
> *Subject:* Re: [cisco-voip] License migration: 8.6 -> 9.0****
>
> ** **
>
> Run from 9.0 and do 9.1. You?ll have to redo all of the licenses when you
> go to 9.1 anyways.****
>
> ****
>
> All of the 9.0 upgrades that I did the ELM work flawlessly once the ESXi
> host that it was on had a proper NIC teaming configuration.****
>
> ****
>
> -Nate****
>
> ****
>
> *From:* cisco-voip-bounces at puck.nether.net [
> mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at
puck.nether.net>]
> *On Behalf Of *Jos? Paulo de Oliveira Petry
> *Sent:* Monday, January 14, 2013 9:43 AM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] License migration: 8.6 -> 9.0****
>
> ****
>
> Hello,****
>
> ****
>
> I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.****
>
> ****
>
> To migrate licenses (DLU to CUWL) im using this doc:****
>
>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/migratn.html#wp1067112
> ****
>
> ****
>
> After i add the CUCM instance, im trying to use the Migration Utility, but
> im receiving this error:****
>
> ****
>
> "There are no Unified CM product instances with pre-9.0 licenses available
> for upgrade"****
>
> ****
>
> Any suggestion?****
>
> ****
>
> Regards,****
>
> ****
>
> Jos? Paulo de Oliveira Petry
> petrybr at gmail.com****
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/6b739a97/attachment.html>

From tednugent73 at gmail.com Thu Jan 24 16:28:51 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Thu, 24 Jan 2013 16:28:51 -0500
Subject: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA201665@xmb-rcd-x13.cisco.com>
References: <CAHs2VYsDvLmpvauCTJW_McPwHhcCqP4ieoBJfDsSzD_s+9NjSQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2001C6@xmb-rcd-x13.cisco.com>
<CAHs2VYuw0x_ve4eDe10opuqBFLG9u4LSDKVTnT=kXg3Lp+CNew@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA2005B4@xmb-rcd-x13.cisco.com>
<CAHs2VYu8SEwBUJyNqXe7iRp5iiqWdYkPGg7e05mwm06B_vdZKQ@mail.gmail.com>
<C3D1FCA271936B48839E081F898E17AA201665@xmb-rcd-x13.cisco.com>
Message-ID: <CAHs2VYuU7RgWD0aD4dE6d0Zru=TFyLG7fEmuhhUbmNfeh5GKsA@mail.gmail.com>

Thanks Chris
I like option 2 as well since they only have 24 ports as it stands. I'll
give it a shot and let you know how it turns out. Thanks again!

On Thu, Jan 24, 2013 at 3:16 PM, Chris Ward (chrward) <chrward at cisco.com>wrote:

> Hi Ted,****
>
> ** **
>
> Seems like you are hitting some known limitations. The settings in CUCM
> for restricting Calling Party Information don?t really eliminate it, it
> seems to just mark it as ?Restricted? so the information remains and CUC
> seems hell-bent on finding calling party information.****
>
> ** **
>
> I did find 2 solutions for you, both of which use SIP:****
>
> ** **
>
> **1) **Setup an additional integration between CUCM and CUC that is
> meant only for this anonymous line. In the SIP trunk config, you have to
> uncheck the ?Remote-Party-Id? under the ?Call Routing Information?
> section and make sure ?Calling Line ID Presentation? is set to Restricted
> under the ?Outbound Calls? section. This will result in an ?Unknown
> CallerID? message in Outlook.****
>
> **2) **Setup a Loopback SIP trunk for calls to this specific
> Anonymous DID. You only need one SIP trunk to point to CUCMs own IP
> address, it acts as the outbound and inbound SIP trunk in this scenario.
> Under the ?Outbound Calls? section, you would need define a Calling Party
> Transformation CSS that would have access to a transformation pattern that
> matches all Calling parties (remembering that only calls to this anonymous
> DID are affected) and mask the calling party with some obscure mask like
> 0000 or you can put a . at the end of the pattern you match and then drop
> all pre-dot if you want it blank. On the route pattern that points to this
> loopback SIP trunk, you would modify the called party so that once the call
> re-enters CUCM, it will be destined for the *7999 number (pulled from you
> example before) and continues through the normal process to be forwarded to
> voicemail.****
>
> ** **
>
> Neither solution is super-attractive, but both will work. I personally
> like #2 since it means you won?t have split up your CUC ports for a
> separate SIP integration. Let me know if you have any questions. It is
> probably a little more involved than the description I provided.****
>
> ** **
>
> +Chris****
>
> Unity Connection TME****
>
> ** **
>
> *From:* Ted Nugent [mailto:tednugent73 at gmail.com]
> *Sent:* Wednesday, January 23, 2013 6:47 PM
>
> *To:* Chris Ward (chrward)
> *Cc:* Cisco VoIPoE List
> *Subject:* RE: [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ** **
>
> Will do thanks!****
>
> On Jan 23, 2013 5:57 PM, "Chris Ward (chrward)" <chrward at cisco.com> wrote:
> ****
>
> Let me try it out in my lab tomorrow and get back to you. Remind me Friday
> morning if you don?t hear from me. J****
>
> ****
>
> +Chris****
>
> Unity Connection TME****
>
> ****
>
> *From:* Ted Nugent [mailto:tednugent73 at gmail.com]
> *Sent:* Wednesday, January 23, 2013 5:09 PM
> *To:* Chris Ward (chrward)
> *Cc:* Cisco VoIPoE List
> *Subject:* Re: [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ****
>
> Chris thanks for the reply, Yes it is stripping the info washing it
> through a TP, the phone I'm calling shows "Private". While using the TP
> method I'm basically using the Direct to voicemail (*XXXX) VM profile
> which is CFWDAll to VM on a CTI-RP. ****
>
> For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM****
>
> ****
>
> However using the Huntpilot way, I have a HP going directly to HL/LG
> containing the VM Ports and a Directed routing rule going to the subscriber
> greeting. The HP is configured calling party name/line presention to
> restricted, same as i did with the TP****
>
> ****
>
> As mention both have the same affect?****
>
> ****
>
> This is an SCCP integration with CUC and we get the same results via
> external calls from an MGCP controlled PRI and SIP/SCCP phones****
>
> ****
>
> Any thoughts?****
>
> Thanks****
>
> Ted****
>
> On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at cisco.com>
> wrote:****
>
> Ted,****
>
> ****
>
> Removing the calling party information from the call before it gets to CUC
> is definitely the way to do this. So, I think you are on the right track.*
> ***
>
> ****
>
> Now, as to why it?s not working, there are a few things you could try. As
> a test, I would setup a translation pattern to strip the calling
> information and then forward it to your desk phone (making sure you don?t
> receive calling party information) so you can make sure that the
> translation pattern is doing what you think it is.****
>
> ****
>
> Also, how are you routing this specific call to CUC? Are you using a dummy
> CTI RP and just setting it to CFA to CUC? And is the integration SCCP or
> SIP to CUC?****
>
> ****
>
> +Chris****
>
> Unity Connection TME****
>
> ****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
> *Sent:* Wednesday, January 23, 2013 12:37 PM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] Making a message appear anonymous/unknown via
> single inbox****
>
> ****
>
> CM 8.6, Unity Connection 8.6 and Exchange 2010****
>
> Customer has an anonymous tip line that is using single inbox and would
> like the messages to showup as anonymous or unknown as opposed to showing
> the callers name and/or phone number.****
>
> I've attempted to strip off the calling party info by washing it through a
> translation pattern and setting the calling party name/line presention to
> restricted and that doesn't work, I also attempted to setup a Hunt Pilot
> and setting the calling party presention to restricted as well and in both
> scenarios the email arrives displaying the callers info. Does anyone have
> any ideas to accomplish this? Either via CM, Unity Connection or Exchange?
> ****
>
> TIA Ted****
>
> ****
>
> ****
>
> ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/a19bf8a0/attachment.html>

From ahmed_elnagar at hotmail.com Thu Jan 24 16:56:49 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Thu, 24 Jan 2013 23:56:49 +0200
Subject: [cisco-voip] Database Replication fails
In-Reply-To: <BAY002-W226C62D821397259130882287140@phx.gbl>
References: <BAY002-W2925E4179A3ACE57068C2487140@phx.gbl>,
<75778C6826D2F248A21C5F17308148542259099ADC@USISPCLEXDB01.na.didata.local>
<BAY002-W226C62D821397259130882287140@phx.gbl>
Message-ID: <BAY149-ds14007E2B4145BEB7DF102487140@phx.gbl>

Hello Kalyan;

Do you have the bug ID?

Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 7:36 PM
To: Kalyan Iyer (AM); VOIP Group
Subject: Re: [cisco-voip] Database Replication fails

What happened is

I installed Pub and Sub, but configured 3 server "system>server" then when
tried to install the 3rd one RAID failure "RMA bla bla" new hardware come
after two months "during which I changed the security password.

Now I install normally and having the below issue after installtion "even
now reverted back to the old password on all servers :("

I opened a TAC for this now.

Thanks,
Ahmed Elnagar

_____
From: kalyan.iyer at dimensiondata.com
To: ahmed_elnagar at hotmail.com
Date: Thu, 24 Jan 2013 12:28:53 -0500
Subject: RE: [cisco-voip] Database Replication fails

Ahmed,

Was the security password changed recently? I ran into the same bug on CUCM
8.5 once, when I tried to add a Sub to an existing cluster and the security
password was misplaced and I had to change it using the pwrecovery option
and reboot it. I was able to add the Sub during the installation but the
replication failed. The symptoms seem to be the same. It's something to do
with the way the password gets hashed after changing it. This is a known bug
on CUCM 8.5 and only TAC can fix this by running a script.

Thanks,

Kalyan

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 11:55 AM
To: VOIP Group; rratliff at cisco.com
Subject: [cisco-voip] Database Replication fails

I am having the below issue with one subscriber "my setup is one publisher
and two subscribers"

>From the Publisher I have the below:

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

Cluster Replication State: BROADCAST SYNC Completed on 1 servers at:


2013-01-24-19-11

Last Sync Result: SYNC COMPLETED 541 tables sync'ed out of 541

Sync Errors: 1 Errors or failures were found


Use this command to see the output - file view activelog
/cm/trace/dbl/2013_01_24_19_10_13_dbl_repl_cdr_Broadcast.log

DB Version: ccm8_6_2_22900_9

Number of replicated tables: 541

Cluster Detailed View from PUB (3 Servers):

PING REPLICATION REPL.


DBver& REPL. REPLICATION SETUP

SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE


TABLES LOOP? (RTMT) & details

----------- ------------ ------ ---- ----------- -----


------- ----- -----------------

PUB 10.x.x.x 0.033 Yes Connected 0 match Yes


(2) PUB Setup Completed

SUB01 10.x.x.y 0.115 Yes Connected 0 match Yes


(2) Setup Completed

SUB02 10.x.x.z 0.107 Yes Off-Line N/A 0 N/A


(0) Not Setup

admin:

and on the publisher I see this for the 2nd subscriber I am having an issue
with

admin:file view activelog cm/log/informix/ccm.log

19:16:17 Password Validation for user [dblpm] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dblpm at SUB02: User


(dblpm at SUB02)'s password is not correct for the database server.

19:16:17 Password Validation for user [dbmon] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User


(dbmon at SUB02)'s password is not correct for the database server.
19:16:17 Password Validation for user [dbris] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbris at SUB02: User


(dbris at SUB02)'s password is not correct for the database server.

19:16:19 Password Validation for user [dbauditlog] failed!

19:16:19 Check for password aging/account lock-out.

19:16:19 listener-thread: err = -952: oserr = 0: errstr = dbauditlog at SUB02:


User (dbauditlog at SUB02)'s password is not correct for the database server.

19:16:20 Password Validation for user [dbmon] failed!

19:16:20 Check for password aging/account lock-out.

19:16:20 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User


(dbmon at SUB02)'s password is not correct for the database server.

options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 20 of 5708) :

admin:

I am sure that security password is the same everywhere, what do you think
the problem is?

Thanks,
Ahmed Elnagar

itevomcid

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/518d66a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/518d66a2/attachment.jpg>

From chrward at cisco.com Thu Jan 24 17:14:38 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Thu, 24 Jan 2013 22:14:38 +0000
Subject: [cisco-voip] List Users in CUC 8.6
In-Reply-To: <B2EFD7619F56A14783B1F0170ABF3B0E011C2C4380@EX7T2-CV10.TDBFG.COM>
References: <B2EFD7619F56A14783B1F0170ABF3B0E011C2C4380@EX7T2-CV10.TDBFG.COM>
Message-ID: <C3D1FCA271936B48839E081F898E17AA2018BD@xmb-rcd-x13.cisco.com>

If you go to each of the roles and select them individually, you can click on the
"Assignments" and see who is a member of that role. Is there something
more/different you are looking for?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Cooke, Dave
Sent: Thursday, January 24, 2013 1:08 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] List Users in CUC 8.6

Trying to list users with by assigned roles is this possible? Thanks

Thank you,

David Cooke
Senior Engineer, Team Lead
Technology Solutions, Contact Center Infrastructure
TD Bank, Americas Most Convenient Bank
17000 Horizon Way
Mount Laurel, NJ 08054
AIM # NJ5-005-173
(o) 856.470.3400
(f) 856.533.2852
(e) david.cooke at td.com<mailto:david.cooke at td.com> - New Email Address as of
8/31/2011

This message and any attachments may contain confidential or privileged


information and are intended only for the use of the intended recipients
of this message. If you are not the intended recipient of this message,
please notify the sender by return email, and delete this and all copies
of this message and any attachments from your system. Any unauthorized
disclosure, use, distribution, or reproduction of this message or any attachments
is prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/a9de32a0/attachment.html>

From david.Cooke at td.com Thu Jan 24 17:16:21 2013


From: david.Cooke at td.com (Cooke, Dave)
Date: Thu, 24 Jan 2013 17:16:21 -0500
Subject: [cisco-voip] List Users in CUC 8.6
In-Reply-To: <C3D1FCA271936B48839E081F898E17AA2018BD@xmb-rcd-x13.cisco.com>
References: <B2EFD7619F56A14783B1F0170ABF3B0E011C2C4380@EX7T2-CV10.TDBFG.COM>
<C3D1FCA271936B48839E081F898E17AA2018BD@xmb-rcd-x13.cisco.com>
Message-ID: <B2EFD7619F56A14783B1F0170ABF3B0E011C39642C@EX7T2-CV10.TDBFG.COM>

Hi Chris,
Just looking for a report that list all users with roles. Instead of listing one
at a time.

Thank you,

David Cooke
Senior Engineer, Team Lead
Technology Solutions, Contact Center Infrastructure
TD Bank, Americas Most Convenient Bank
17000 Horizon Way
Mount Laurel, NJ 08054
AIM # NJ5-005-173
(o) 856.470.3400
(f) 856.533.2852
(e) david.cooke at td.com<mailto:david.cooke at td.com> - New Email Address as of
8/31/2011

From: Chris Ward (chrward) [mailto:chrward at cisco.com]


Sent: Thursday, January 24, 2013 5:15 PM
To: Cooke, Dave; cisco-voip at puck.nether.net
Subject: RE: List Users in CUC 8.6

If you go to each of the roles and select them individually, you can click on the
"Assignments" and see who is a member of that role. Is there something
more/different you are looking for?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Cooke, Dave
Sent: Thursday, January 24, 2013 1:08 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] List Users in CUC 8.6

Trying to list users with by assigned roles is this possible? Thanks

Thank you,

David Cooke
Senior Engineer, Team Lead
Technology Solutions, Contact Center Infrastructure
TD Bank, Americas Most Convenient Bank
17000 Horizon Way
Mount Laurel, NJ 08054
AIM # NJ5-005-173
(o) 856.470.3400
(f) 856.533.2852
(e) david.cooke at td.com<mailto:david.cooke at td.com> - New Email Address as of
8/31/2011

This message and any attachments may contain confidential or privileged


information and are intended only for the use of the intended recipients
of this message. If you are not the intended recipient of this message,
please notify the sender by return email, and delete this and all copies
of this message and any attachments from your system. Any unauthorized
disclosure, use, distribution, or reproduction of this message or any attachments
is prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/27d872e4/attachment.html>

From lelio at uoguelph.ca Thu Jan 24 17:23:31 2013


From: lelio at uoguelph.ca (Lelio Fulgenzi)
Date: Thu, 24 Jan 2013 17:23:31 -0500 (EST)
Subject: [cisco-voip] List Users in CUC 8.6
In-Reply-To: <B2EFD7619F56A14783B1F0170ABF3B0E011C39642C@EX7T2-CV10.TDBFG.COM>
References: <B2EFD7619F56A14783B1F0170ABF3B0E011C2C4380@EX7T2-CV10.TDBFG.COM>
<C3D1FCA271936B48839E081F898E17AA2018BD@xmb-rcd-x13.cisco.com>
<B2EFD7619F56A14783B1F0170ABF3B0E011C39642C@EX7T2-CV10.TDBFG.COM>
Message-ID: <5AC615EF-2095-4CA2-BA3A-C4387DB4BD71@uoguelph.ca>

Try the tools at www.ciscounitytools.com. User data dump comes to mind. There is
also CUDLI which can do wonders too.

Sent from my iPhone...

"There's no place like 127.0.0.1"

On Jan 24, 2013, at 5:17 PM, "Cooke, Dave" <david.Cooke at td.com> wrote:

> Hi Chris,
> Just looking for a report that list all users with roles. Instead of listing one
at a time.
>
>
>
> Thank you,
>
> David Cooke
> Senior Engineer, Team Lead
> Technology Solutions, Contact Center Infrastructure
> TD Bank, Americas Most Convenient Bank
> 17000 Horizon Way
> Mount Laurel, NJ 08054
> AIM # NJ5-005-173
> (o) 856.470.3400
> (f) 856.533.2852
> (e) david.cooke at td.com - New Email Address as of 8/31/2011
>
>
> From: Chris Ward (chrward) [mailto:chrward at cisco.com]
> Sent: Thursday, January 24, 2013 5:15 PM
> To: Cooke, Dave; cisco-voip at puck.nether.net
> Subject: RE: List Users in CUC 8.6
>
> If you go to each of the roles and select them individually, you can click on the
?Assignments? and see who is a member of that role. Is there something
more/different you are looking for?
>
> +Chris
> Unity Connection TME
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Cooke, Dave
> Sent: Thursday, January 24, 2013 1:08 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] List Users in CUC 8.6
>
> Trying to list users with by assigned roles is this possible? Thanks
>
>
>
> Thank you,
>
> David Cooke
> Senior Engineer, Team Lead
> Technology Solutions, Contact Center Infrastructure
> TD Bank, Americas Most Convenient Bank
> 17000 Horizon Way
> Mount Laurel, NJ 08054
> AIM # NJ5-005-173
> (o) 856.470.3400
> (f) 856.533.2852
> (e) david.cooke at td.com - New Email Address as of 8/31/2011
>
>
>
>
> This message and any attachments may contain confidential or privileged
> information and are intended only for the use of the intended recipients
> of this message. If you are not the intended recipient of this message,
> please notify the sender by return email, and delete this and all copies
> of this message and any attachments from your system. Any unauthorized
> disclosure, use, distribution, or reproduction of this message or any attachments
is prohibited and may be unlawful.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/7140ca36/attachment.html>

From kalyan.iyer at dimensiondata.com Thu Jan 24 17:24:24 2013


From: kalyan.iyer at dimensiondata.com (Kalyan Iyer (AM))
Date: Thu, 24 Jan 2013 17:24:24 -0500
Subject: [cisco-voip] Database Replication fails
In-Reply-To: <BAY149-ds14007E2B4145BEB7DF102487140@phx.gbl>
References: <BAY002-W2925E4179A3ACE57068C2487140@phx.gbl>,
<75778C6826D2F248A21C5F17308148542259099ADC@USISPCLEXDB01.na.didata.local>
<BAY002-W226C62D821397259130882287140@phx.gbl>
<BAY149-ds14007E2B4145BEB7DF102487140@phx.gbl>
Message-ID:
<75778C6826D2F248A21C5F17308148542259099DAE@USISPCLEXDB01.na.didata.local>

Ahmed,

The bug id is CSCti18766.

Thanks,
Kalyan

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]


Sent: Thursday, January 24, 2013 4:57 PM
To: Kalyan Iyer (AM); 'VOIP Group'
Subject: RE: [cisco-voip] Database Replication fails

Hello Kalyan;

Do you have the bug ID?

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
[cid:image001.jpg at 01CDFA57.A78A4D50]

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 7:36 PM
To: Kalyan Iyer (AM); VOIP Group
Subject: Re: [cisco-voip] Database Replication fails

What happened is

I installed Pub and Sub, but configured 3 server "system>server" then when tried to
install the 3rd one RAID failure "RMA bla bla" new hardware come after two months
"during which I changed the security password.

Now I install normally and having the below issue after installtion "even now
reverted back to the old password on all servers :("

I opened a TAC for this now.


Thanks,
Ahmed Elnagar

________________________________
From: kalyan.iyer at dimensiondata.com<mailto:kalyan.iyer at dimensiondata.com>
To: ahmed_elnagar at hotmail.com<mailto:ahmed_elnagar at hotmail.com>
Date: Thu, 24 Jan 2013 12:28:53 -0500
Subject: RE: [cisco-voip] Database Replication fails
Ahmed,

Was the security password changed recently? I ran into the same bug on CUCM 8.5
once, when I tried to add a Sub to an existing cluster and the security password
was misplaced and I had to change it using the pwrecovery option and reboot it. I
was able to add the Sub during the installation but the replication failed. The
symptoms seem to be the same. It's something to do with the way the password gets
hashed after changing it. This is a known bug on CUCM 8.5 and only TAC can fix this
by running a script.

Thanks,
Kalyan

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 11:55 AM
To: VOIP Group; rratliff at cisco.com<mailto:rratliff at cisco.com>
Subject: [cisco-voip] Database Replication fails

I am having the below issue with one subscriber "my setup is one publisher and two
subscribers"

>From the Publisher I have the below:

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING


Cluster Replication State: BROADCAST SYNC Completed on 1 servers at: 2013-01-24-19-
11
Last Sync Result: SYNC COMPLETED 541 tables sync'ed out of 541
Sync Errors: 1 Errors or failures were found
Use this command to see the output - file view activelog
/cm/trace/dbl/2013_01_24_19_10_13_dbl_repl_cdr_Broadcast.log
DB Version: ccm8_6_2_22900_9
Number of replicated tables: 541

Cluster Detailed View from PUB (3 Servers):

PING REPLICATION REPL. DBver&


REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE TABLES
LOOP? (RTMT) & details
----------- ------------ ------ ---- ----------- ----- -------
----- -----------------
PUB 10.x.x.x 0.033 Yes Connected 0 match Yes (2) PUB
Setup Completed
SUB01 10.x.x.y 0.115 Yes Connected 0 match Yes (2)
Setup Completed
SUB02 10.x.x.z 0.107 Yes Off-Line N/A 0 N/A (0)
Not Setup
admin:

and on the publisher I see this for the 2nd subscriber I am having an issue with

admin:file view activelog cm/log/informix/ccm.log

19:16:17 Password Validation for user [dblpm] failed!


19:16:17 Check for password aging/account lock-out.
19:16:17 listener-thread: err = -952: oserr = 0: errstr = dblpm at SUB02: User
(dblpm at SUB02)'s password is not correct for the database server.
19:16:17 Password Validation for user [dbmon] failed!
19:16:17 Check for password aging/account lock-out.
19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User
(dbmon at SUB02)'s password is not correct for the database server.

19:16:17 Password Validation for user [dbris] failed!


19:16:17 Check for password aging/account lock-out.
19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbris at SUB02: User
(dbris at SUB02)'s password is not correct for the database server.

19:16:19 Password Validation for user [dbauditlog] failed!


19:16:19 Check for password aging/account lock-out.
19:16:19 listener-thread: err = -952: oserr = 0: errstr = dbauditlog at SUB02:
User (dbauditlog at SUB02)'s password is not correct for the database server.

19:16:20 Password Validation for user [dbmon] failed!


19:16:20 Check for password aging/account lock-out.
19:16:20 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User
(dbmon at SUB02)'s password is not correct for the database server.

options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 20 of 5708) :


admin:

I am sure that security password is the same everywhere, what do you think the
problem is?

Thanks,
Ahmed Elnagar

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/ac1f3796/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130124/ac1f3796/attachment.jpg>

From ahmed_elnagar at hotmail.com Thu Jan 24 19:00:25 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Fri, 25 Jan 2013 02:00:25 +0200
Subject: [cisco-voip] Database Replication fails
In-Reply-To:
<75778C6826D2F248A21C5F17308148542259099DAE@USISPCLEXDB01.na.didata.local>
References: <BAY002-W2925E4179A3ACE57068C2487140@phx.gbl>,
<75778C6826D2F248A21C5F17308148542259099ADC@USISPCLEXDB01.na.didata.local>
<BAY002-W226C62D821397259130882287140@phx.gbl>
<BAY149-ds14007E2B4145BEB7DF102487140@phx.gbl>
<75778C6826D2F248A21C5F17308148542259099DAE@USISPCLEXDB01.na.didata.local>
Message-ID: <BAY149-ds21B23F7529EF15FEB2187A87140@phx.gbl>

Just finished the TAC case, there is a new bug ID for the new version now J
Bug Id is CSCua09290

Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green

From: Kalyan Iyer (AM) [mailto:kalyan.iyer at dimensiondata.com]


Sent: Friday, January 25, 2013 12:24 AM
To: Ahmed Elnagar; 'VOIP Group'
Subject: RE: [cisco-voip] Database Replication fails

Ahmed,

The bug id is CSCti18766.

Thanks,

Kalyan

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]


Sent: Thursday, January 24, 2013 4:57 PM
To: Kalyan Iyer (AM); 'VOIP Group'
Subject: RE: [cisco-voip] Database Replication fails

Hello Kalyan;

Do you have the bug ID?

Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 7:36 PM
To: Kalyan Iyer (AM); VOIP Group
Subject: Re: [cisco-voip] Database Replication fails

What happened is

I installed Pub and Sub, but configured 3 server "system>server" then when
tried to install the 3rd one RAID failure "RMA bla bla" new hardware come
after two months "during which I changed the security password.

Now I install normally and having the below issue after installtion "even
now reverted back to the old password on all servers :("

I opened a TAC for this now.

Thanks,
Ahmed Elnagar

_____

From: kalyan.iyer at dimensiondata.com


To: ahmed_elnagar at hotmail.com
Date: Thu, 24 Jan 2013 12:28:53 -0500
Subject: RE: [cisco-voip] Database Replication fails

Ahmed,

Was the security password changed recently? I ran into the same bug on CUCM
8.5 once, when I tried to add a Sub to an existing cluster and the security
password was misplaced and I had to change it using the pwrecovery option
and reboot it. I was able to add the Sub during the installation but the
replication failed. The symptoms seem to be the same. It's something to do
with the way the password gets hashed after changing it. This is a known bug
on CUCM 8.5 and only TAC can fix this by running a script.

Thanks,

Kalyan

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Thursday, January 24, 2013 11:55 AM
To: VOIP Group; rratliff at cisco.com
Subject: [cisco-voip] Database Replication fails
I am having the below issue with one subscriber "my setup is one publisher
and two subscribers"

>From the Publisher I have the below:

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

Cluster Replication State: BROADCAST SYNC Completed on 1 servers at:


2013-01-24-19-11

Last Sync Result: SYNC COMPLETED 541 tables sync'ed out of 541

Sync Errors: 1 Errors or failures were found

Use this command to see the output - file view activelog


/cm/trace/dbl/2013_01_24_19_10_13_dbl_repl_cdr_Broadcast.log

DB Version: ccm8_6_2_22900_9

Number of replicated tables: 541

Cluster Detailed View from PUB (3 Servers):

PING REPLICATION REPL.


DBver& REPL. REPLICATION SETUP

SERVER-NAME IP ADDRESS (msec) RPC? STATUS QUEUE


TABLES LOOP? (RTMT) & details

----------- ------------ ------ ---- ----------- -----


------- ----- -----------------

PUB 10.x.x.x 0.033 Yes Connected 0 match Yes


(2) PUB Setup Completed

SUB01 10.x.x.y 0.115 Yes Connected 0 match Yes


(2) Setup Completed

SUB02 10.x.x.z 0.107 Yes Off-Line N/A 0 N/A


(0) Not Setup

admin:
and on the publisher I see this for the 2nd subscriber I am having an issue
with

admin:file view activelog cm/log/informix/ccm.log

19:16:17 Password Validation for user [dblpm] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dblpm at SUB02: User


(dblpm at SUB02)'s password is not correct for the database server.

19:16:17 Password Validation for user [dbmon] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User


(dbmon at SUB02)'s password is not correct for the database server.

19:16:17 Password Validation for user [dbris] failed!

19:16:17 Check for password aging/account lock-out.

19:16:17 listener-thread: err = -952: oserr = 0: errstr = dbris at SUB02: User


(dbris at SUB02)'s password is not correct for the database server.

19:16:19 Password Validation for user [dbauditlog] failed!

19:16:19 Check for password aging/account lock-out.

19:16:19 listener-thread: err = -952: oserr = 0: errstr = dbauditlog at SUB02:


User (dbauditlog at SUB02)'s password is not correct for the database server.

19:16:20 Password Validation for user [dbmon] failed!

19:16:20 Check for password aging/account lock-out.

19:16:20 listener-thread: err = -952: oserr = 0: errstr = dbmon at SUB02: User


(dbmon at SUB02)'s password is not correct for the database server.

options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 20 of 5708) :

admin:
I am sure that security password is the same everywhere, what do you think
the problem is?

Thanks,
Ahmed Elnagar

itevomcid

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/a2ec4389/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/a2ec4389/attachment.jpg>

From medtaha99 at gmail.com Fri Jan 25 05:43:04 2013


From: medtaha99 at gmail.com (Abdelkefi/Mohamed taha)
Date: Fri, 25 Jan 2013 11:43:04 +0100
Subject: [cisco-voip] mercie
Message-ID: <CALDqBnWhqGv0FuaMsZUS2+a3VMiGGZ4kr+z+1tP44efJcC=oRw@mail.gmail.com>

je suis heureux de cette inscription

mercie beucoup

From wsisk at cisco.com Fri Jan 25 11:23:45 2013


From: wsisk at cisco.com (Wes Sisk)
Date: Fri, 25 Jan 2013 11:23:45 -0500
Subject: [cisco-voip] Bulk Import of Gateways - CUCM 8.6
In-Reply-To: <CAF5YbzVAW6sECtFB+19O4pFpe9eLVshO95rFwsUxJ8FCeua3bw@mail.gmail.com>
References: <CAF5YbzV3gHHCyfQ3+CmG12iKgzAxXtWyeZ=H=m3EUwmSVpzbPA@mail.gmail.com>
<CAF5YbzVAW6sECtFB+19O4pFpe9eLVshO95rFwsUxJ8FCeua3bw@mail.gmail.com>
Message-ID: <235B2220-597D-455A-BA7F-513E153E5D20@cisco.com>

sounds like you need a test bed?

On Jan 17, 2013, at 9:22 AM, Kris Edgar <kris.edgar82 at gmail.com> wrote:

Hi Folks,

Great group going on here!! I'm hoping someone can give me advice on the
following:

We are using CUCM 8.6 and are looking to import a large number of H323 GW's, RG's,
RL's etc.

I've used the Import/Export tool and selected GW's and used the "Check dependency"
to capture all the other associated fields.

I now have a tar file with all the CSV's needed. Happy so far!!

I'm not too sure if i need to keep the existing data in the CSV's, and add to it?
Or can I strip out the existing elements (keeping the headers) and just have the
new file with the elements that i need to import?

I have a horrible thought that if i re-import the file without the original GW's
etc, it might delete them from CM and leave me with my new GW's etc.

Paranoid.com!!!

Thanks for your help on this.

Kris

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/92381960/attachment.html>

From wsisk at cisco.com Fri Jan 25 11:32:44 2013


From: wsisk at cisco.com (Wes Sisk)
Date: Fri, 25 Jan 2013 11:32:44 -0500
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
Message-ID: <3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>

Typically this happens because the hold actually failed. did the PSTN user actually
hear music on hold? look for codec mismatches or misconfiguration in delivering MoH
to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za> wrote:

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a ? Bearer capability not implemented? error. Any
ideas what the problem could be ?
Regards
Rynard
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/81f58401/attachment.html>

From salamka at gmail.com Fri Jan 25 12:44:08 2013


From: salamka at gmail.com (Abdul Salam .)
Date: Fri, 25 Jan 2013 23:14:08 +0530
Subject: [cisco-voip] tomcat
Message-ID: <CAKav0XTCn-_gGpf8ExAhtNpF8ufzObR61GHstHyWFmBiXyMMnA@mail.gmail.com>

Hi All,

anyone got a good documentation on tomcat ? like JVM, thread analysis ,


MAT analysis , Catalina logs ?

*---AS*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/3485007e/attachment.html>

From jason.aarons at dimensiondata.com Fri Jan 25 14:08:12 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Fri, 25 Jan 2013 14:08:12 -0500
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>

I can't find the CUPS version of ciscocm.cup.refresh_upgrade_v<latest_version on


cisco.com downloads. Help.

I pulled a version down and the installer in CUPS came back with wrong version.

-jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/d3c47e22/attachment.html>

From jason.aarons at dimensiondata.com Fri Jan 25 14:12:12 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Fri, 25 Jan 2013 14:12:12 -0500
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC0511C@USISPCLEXDB01.na.didata.local>

The COP file ciscocm.cup.refresh_upgrade_v<latest_ gets installed on the CUPS


server and subscriber right ?
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Friday, January 25, 2013 2:08 PM
To: cisco-voip (cisco-voip at puck.nether.net)
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

I can't find the CUPS version of ciscocm.cup.refresh_upgrade_v<latest_version on


cisco.com downloads. Help.

I pulled a version down and the installer in CUPS came back with wrong version.

-jason

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/b83eba94/attachment.html>

From jason.aarons at dimensiondata.com Fri Jan 25 14:15:09 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Fri, 25 Jan 2013 14:15:09 -0500
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade
In-Reply-To: <CAFdHCp7_4_TScUtmXHO-9Zgg4mv7-xzxS0OBt72LN_KV+tdKAQ@mail.gmail.com>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>
<CAFdHCp7_4_TScUtmXHO-9Zgg4mv7-xzxS0OBt72LN_KV+tdKAQ@mail.gmail.com>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05123@USISPCLEXDB01.na.didata.local>

Yes 8.6 is a Refresh upgrade due to Security Enhanced Linux upgrade.

From: abbas Wali [mailto:abbaseo at gmail.com]


Sent: Friday, January 25, 2013 2:14 PM
To: Jason Aarons (AM)
Subject: Re: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

just to confirm with you, do you really need that CUPs when you are going from 8.5
to 8.6 ???
On 25 January 2013 19:08, Jason Aarons (AM) <jason.aarons at
dimensiondata.com<mailto:jason.aarons at dimensiondata.com>> wrote:
I can't find the CUPS version of ciscocm.cup.refresh_upgrade_v<latest_version on
cisco.com<http://cisco.com> downloads. Help.

I pulled a version down and the installer in CUPS came back with wrong version.

-jason

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
--
@bbas..

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/cac63b70/attachment.html>

From jason.aarons at dimensiondata.com Fri Jan 25 14:32:35 2013


From: jason.aarons at dimensiondata.com (Jason Aarons (AM))
Date: Fri, 25 Jan 2013 14:32:35 -0500
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05123@USISPCLEXDB01.na.didata.local>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>
<CAFdHCp7_4_TScUtmXHO-9Zgg4mv7-xzxS0OBt72LN_KV+tdKAQ@mail.gmail.com>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05123@USISPCLEXDB01.na.didata.local>
Message-ID:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC0513C@USISPCLEXDB01.na.didata.local>

I'm only upgrading CUPS, so does the ciscocm.cup.refresh_upgrade_v<latest_version


file get installed on CallManager in order for CUPS to upgrade?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Friday, January 25, 2013 2:15 PM
To: abbas Wali
Cc: cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

Yes 8.6 is a Refresh upgrade due to Security Enhanced Linux upgrade.

From: abbas Wali [mailto:abbaseo at gmail.com]


Sent: Friday, January 25, 2013 2:14 PM
To: Jason Aarons (AM)
Subject: Re: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

just to confirm with you, do you really need that CUPs when you are going from 8.5
to 8.6 ???
On 25 January 2013 19:08, Jason Aarons (AM) <jason.aarons at
dimensiondata.com<mailto:jason.aarons at dimensiondata.com>> wrote:
I can't find the CUPS version of ciscocm.cup.refresh_upgrade_v<latest_version on
cisco.com<http://cisco.com> downloads. Help.

I pulled a version down and the installer in CUPS came back with wrong version.

-jason

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
--
@bbas..

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/dd656ec6/attachment.html>

From rratliff at cisco.com Fri Jan 25 15:29:53 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Fri, 25 Jan 2013 15:29:53 -0500
Subject: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade
In-Reply-To:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC0513C@USISPCLEXDB01.na.didata.local>
References:
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05116@USISPCLEXDB01.na.didata.local>
<CAFdHCp7_4_TScUtmXHO-9Zgg4mv7-xzxS0OBt72LN_KV+tdKAQ@mail.gmail.com>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC05123@USISPCLEXDB01.na.didata.local>
<4E38DB0A1959B04C8C83EDCF069B53ED0D2DC0513C@USISPCLEXDB01.na.didata.local>
Message-ID: <E06A5FB4-A576-4F28-9804-05A6B2A8C79F@cisco.com>

It needs to go on each server that is being upgraded so that the OS pages for the
install can provide the right guidance in what is actually going to happen (re: the
extra reboot).

-Ryan

On Jan 25, 2013, at 2:32 PM, Jason Aarons (AM) <jason.aarons at dimensiondata.com>
wrote:

I?m only upgrading CUPS, so does the ciscocm.cup.refresh_upgrade_v<latest_version


file get installed on CallManager in order for CUPS to upgrade?

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Friday, January 25, 2013 2:15 PM
To: abbas Wali
Cc: cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

Yes 8.6 is a Refresh upgrade due to Security Enhanced Linux upgrade.

From: abbas Wali [mailto:abbaseo at gmail.com]


Sent: Friday, January 25, 2013 2:14 PM
To: Jason Aarons (AM)
Subject: Re: [cisco-voip] CUPS 8.5 to 8.6 COP file for upgrade

just to confirm with you, do you really need that CUPs when you are going from 8.5
to 8.6 ???

On 25 January 2013 19:08, Jason Aarons (AM) <jason.aarons at dimensiondata.com>


wrote:
I can?t find the CUPS version of ciscocm.cup.refresh_upgrade_v<latest_version on
cisco.com downloads. Help.

I pulled a version down and the installer in CUPS came back with wrong version.

-jason

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

--
@bbas..

itevomcid
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/6f6667c7/attachment.html>

From kris.edgar82 at gmail.com Fri Jan 25 16:15:02 2013


From: kris.edgar82 at gmail.com (Kris Edgar)
Date: Fri, 25 Jan 2013 21:15:02 +0000
Subject: [cisco-voip] Bulk Import of Gateways - CUCM 8.6
In-Reply-To: <235B2220-597D-455A-BA7F-513E153E5D20@cisco.com>
References: <CAF5YbzV3gHHCyfQ3+CmG12iKgzAxXtWyeZ=H=m3EUwmSVpzbPA@mail.gmail.com>
<CAF5YbzVAW6sECtFB+19O4pFpe9eLVshO95rFwsUxJ8FCeua3bw@mail.gmail.com>
<235B2220-597D-455A-BA7F-513E153E5D20@cisco.com>
Message-ID: <2217B727-B03B-4A63-BD5D-BCCD1B499A4E@gmail.com>

Indeed I do!! However that's the reality of financial cuts in the public sector.

All sorted now though.....don't know what I was worried about!!

Cheers

Kris

Sent from my iPad

On 25 Jan 2013, at 16:23, Wes Sisk <wsisk at cisco.com> wrote:

> sounds like you need a test bed?


>
> On Jan 17, 2013, at 9:22 AM, Kris Edgar <kris.edgar82 at gmail.com> wrote:
>
> Hi Folks,
>
> Great group going on here!! I'm hoping someone can give me advice on the
following:
>
> We are using CUCM 8.6 and are looking to import a large number of H323 GW's,
RG's, RL's etc.
>
> I've used the Import/Export tool and selected GW's and used the "Check
dependency" to capture all the other associated fields.
>
> I now have a tar file with all the CSV's needed. Happy so far!!
>
> I'm not too sure if i need to keep the existing data in the CSV's, and add to it?
Or can I strip out the existing elements (keeping the headers) and just have the
new file with the elements that i need to import?
>
> I have a horrible thought that if i re-import the file without the original GW's
etc, it might delete them from CM and leave me with my new GW's etc.
>
> Paranoid.com!!!
>
> Thanks for your help on this.
>
> Kris
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/d59965a0/attachment.html>

From ahmed_elnagar at hotmail.com Sun Jan 27 09:19:34 2013


From: ahmed_elnagar at hotmail.com (Ahmed Elnagar)
Date: Sun, 27 Jan 2013 16:19:34 +0200
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
Message-ID: <BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>

Check you media termination point configuration also.

Regards,

Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice

Description: Description: Description: MS Green

From: cisco-voip-bounces at puck.nether.net


[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Wes Sisk
Sent: Friday, January 25, 2013 6:33 PM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold

Typically this happens because the hold actually failed. did the PSTN user
actually hear music on hold? look for codec mismatches or misconfiguration
in delivering MoH to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za>


wrote:

Hi

I have the following scenario at a client site ,call comes from PSTN via
H323 GW ,I can answer the call and place the caller on hold ,when I try and
resume the call ,the Telco drops the call with a " Bearer capability not
implemented" error. Any ideas what the problem could be ?

Regards

Rynard

_______________________________________________
cisco-voip mailing list
<mailto:cisco-voip at puck.nether.net> cisco-voip at puck.nether.net
<https://puck.nether.net/mailman/listinfo/cisco-voip>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130127/21da312c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130127/21da312c/attachment.jpg>

From ryan.l.dowdy at gmail.com Sun Jan 27 09:45:12 2013


From: ryan.l.dowdy at gmail.com (Ryan Dowdy)
Date: Sun, 27 Jan 2013 08:45:12 -0600
Subject: [cisco-voip] Problems with Conference, Transfer,
and Hold between Nortel QSig, h.323, and UCM
Message-ID: <51053D78.3030204@gmail.com>

Here's the situation:


Nortel PBX (QSig) -> Cisco 2921 (H.323) -> Cisco 3945 (H.323) -> UCM 8.5.1

Calls coming from the Nortel to the UCM complete fine, but Hold,
Transfer and Conference do not work. The call hears silence for a few
seconds - up to 30 sec - and then the call disconnects. Calls only
initiate in the above direction. Not sending calls directly to UCM
because some calls go out PRIs on the 3945 (maybe I can put dial peers
on the 2921, pointed to the subscriber, specifically for UCM?). Tried
checking the Requires MTP box on the UCM Gateway config. A colleague
suggested:

*voice service voip**


supplementary-service h450.2
**supplementary-service h450.3
*

Hadn't tried this yet because I did not want to affect calls as this
site it always critical and in use - never any real down time. Just
looking for suggestions. Anyone have some?

Ryan

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130127/d68f1890/attachment.html>

From Rynard.Coetzee at bytes.co.za Mon Jan 28 03:16:08 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Mon, 28 Jan 2013 08:16:08 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
Message-ID: <97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>

Hi
MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]


Sent: 27 January 2013 04:20 PM
To: 'Wes Sisk'; Rynard Coetzee
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Call drops after taking off hold

Check you media termination point configuration also.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
[Description: Description: Description: MS Green]

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Wes Sisk
Sent: Friday, January 25, 2013 6:33 PM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Typically this happens because the hold actually failed. did the PSTN user actually
hear music on hold? look for codec mismatches or misconfiguration in delivering MoH
to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a " Bearer capability not implemented" error. Any
ideas what the problem could be ?
Regards
Rynard
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/ed279e0b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/ed279e0b/attachment.jpg>

From Zoltan.Kelemen at emerson.com Mon Jan 28 04:43:36 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Mon, 28 Jan 2013 09:43:36 +0000
Subject: [cisco-voip] g729 gateway / transcoding?
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061ACBC171B3@GBLONZ-PMSGEM02.emrsn.org>

Hi,

This may be a very basic question, but I'm looking for a straight forward answer,
and so far couldn't find anything.

I have a remote voice gateway, with an E1 card connecting to a PBX on one end and
SIP trunk towards the WAN on the other.
On the WAN I'd like to have g729.

The router has a PVDM3-64 inside.

Do I need to set up transcoding as well, or is it enough to specify


codec g729br8
on the voip dial-peer?
Thanks,

Zoltan Kelemen
Emerson

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/c671874f/attachment.html>

From carlo_calabrese2006 at yahoo.com Mon Jan 28 09:22:45 2013


From: carlo_calabrese2006 at yahoo.com (Carlo)
Date: Mon, 28 Jan 2013 06:22:45 -0800
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
<97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
Message-ID: <33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>

We ran into the same problem when we upgraded to 8.6 and we use SIP. TAC said CUCM
will ask for the resource but never uses it.

Sent from my iPad

On Jan 28, 2013, at 12:16 AM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za> wrote:

> Hi
> MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?
>
> From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]
> Sent: 27 January 2013 04:20 PM
> To: 'Wes Sisk'; Rynard Coetzee
> Cc: cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] Call drops after taking off hold
>
> Check you media termination point configuration also.
>
> Regards,
> Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
> <image001.jpg>
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Wes Sisk
> Sent: Friday, January 25, 2013 6:33 PM
> To: Rynard Coetzee
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Call drops after taking off hold
>
> Typically this happens because the hold actually failed. did the PSTN user
actually hear music on hold? look for codec mismatches or misconfiguration in
delivering MoH to the PSTN caller.
>
> /wes
>
> On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za>
wrote:
>
> Hi
> I have the following scenario at a client site ,call comes from PSTN via H323
GW ,I can answer the call and place the caller on hold ,when I try and resume the
call ,the Telco drops the call with a ? Bearer capability not implemented? error.
Any ideas what the problem could be ?
> Regards
> Rynard
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/f29c4552/attachment.html>

From Rynard.Coetzee at bytes.co.za Mon Jan 28 09:28:58 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Mon, 28 Jan 2013 14:28:58 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
<97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
<33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>
Message-ID: <97D19F256B859A48A6A93E8A9210E52A84331DCF@BYTESEXCH2K10N1.bytes.local>

Not in my case ,I can actually see the MTP resources are active and in use on my GW
,using show sccp connections .

From: Carlo [mailto:carlo_calabrese2006 at yahoo.com]


Sent: 28 January 2013 04:23 PM
To: Rynard Coetzee
Cc: Ahmed Elnagar; Wes Sisk; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold

We ran into the same problem when we upgraded to 8.6 and we use SIP. TAC said CUCM
will ask for the resource but never uses it.

Sent from my iPad

On Jan 28, 2013, at 12:16 AM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:
Hi
MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]<mailto:


[mailto:ahmed_elnagar at hotmail.com]>
Sent: 27 January 2013 04:20 PM
To: 'Wes Sisk'; Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] Call drops after taking off hold

Check you media termination point configuration also.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Wes Sisk
Sent: Friday, January 25, 2013 6:33 PM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Typically this happens because the hold actually failed. did the PSTN user actually
hear music on hold? look for codec mismatches or misconfiguration in delivering MoH
to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a ? Bearer capability not implemented? error. Any
ideas what the problem could be ?
Regards
Rynard
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/538baed8/attachment.html>

From chrward at cisco.com Mon Jan 28 09:32:03 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Mon, 28 Jan 2013 14:32:03 +0000
Subject: [cisco-voip] Problems with Conference, Transfer,
and Hold between Nortel QSig, h.323, and UCM
In-Reply-To: <51053D78.3030204@gmail.com>
References: <51053D78.3030204@gmail.com>
Message-ID: <C3D1FCA271936B48839E081F898E17AA20526E@xmb-rcd-x13.cisco.com>

I would also go with MTP. However, I would make sure that you are actually
allocating and MTP with the call when you check the box. You need to have an MTP
capable of the codec that is configured in your region setup in the MRGL of the GW
where the call is coming in from Nortel (3945?). Also, while the call is up, you
could check the RTP statistics of the call and see where the phone is sending RTP
to and verify it is going to the IP address of the MTP.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Ryan Dowdy
Sent: Sunday, January 27, 2013 9:45 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Problems with Conference, Transfer, and Hold between Nortel
QSig, h.323, and UCM

Here's the situation:

Nortel PBX (QSig) -> Cisco 2921 (H.323) -> Cisco 3945 (H.323) -> UCM 8.5.1

Calls coming from the Nortel to the UCM complete fine, but Hold, Transfer and
Conference do not work. The call hears silence for a few seconds - up to 30 sec -
and then the call disconnects. Calls only initiate in the above direction. Not
sending calls directly to UCM because some calls go out PRIs on the 3945 (maybe I
can put dial peers on the 2921, pointed to the subscriber, specifically for UCM?).
Tried checking the Requires MTP box on the UCM Gateway config. A colleague
suggested:

voice service voip


supplementary-service h450.2
supplementary-service h450.3

Hadn't tried this yet because I did not want to affect calls as this site it always
critical and in use - never any real down time. Just looking for suggestions.
Anyone have some?

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/bf38f543/attachment.html>

From rratliff at cisco.com Mon Jan 28 10:54:34 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Mon, 28 Jan 2013 10:54:34 -0500
Subject: [cisco-voip] g729 gateway / transcoding?
In-Reply-To: <F8E0CC3253A10C4CB137F12F568DAD061ACBC171B3@GBLONZ-PMSGEM02.emrsn.org>
References: <F8E0CC3253A10C4CB137F12F568DAD061ACBC171B3@GBLONZ-PMSGEM02.emrsn.org>
Message-ID: <0018165F-ADE5-4A70-AEE3-C531F55C348A@cisco.com>

You would only need transcoding if you have call flows that could connect this
gateway to a device across the wan that doesn't support g729. In that case if
you still want to have g729 go across the wan you'd need to be transcoding to 711
at the central site, not at the remote site gateway.

As far as the dial-peer goes I'd recommend a codec class with all the variants of
729 (that don't have 'b' in them) to prevent potential failures because of
variations in codec support across your devices or other gateways. You don't want
to use g729b because it includes voice activity detection (vad) and will cause even
poorer voice quality than you'll be getting with 729.

-Ryan

On Jan 28, 2013, at 4:43 AM, Zoltan.Kelemen at emerson.com wrote:

Hi,

This may be a very basic question, but I?m looking for a straight forward answer,
and so far couldn?t find anything.

I have a remote voice gateway, with an E1 card connecting to a PBX on one end and
SIP trunk towards the WAN on the other.
On the WAN I?d like to have g729.

The router has a PVDM3-64 inside.

Do I need to set up transcoding as well, or is it enough to specify


codec g729br8
on the voip dial-peer?

Thanks,

Zoltan Kelemen
Emerson

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/c192bf06/attachment.html>

From Zoltan.Kelemen at emerson.com Mon Jan 28 17:17:57 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Mon, 28 Jan 2013 22:17:57 +0000
Subject: [cisco-voip] g729 gateway / transcoding?
In-Reply-To: <0018165F-ADE5-4A70-AEE3-C531F55C348A@cisco.com>
References: <F8E0CC3253A10C4CB137F12F568DAD061ACBC171B3@GBLONZ-PMSGEM02.emrsn.org>,
<0018165F-ADE5-4A70-AEE3-C531F55C348A@cisco.com>
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061ACBE241F1@GBLONZ-PMSGEM02.emrsn.org>

Thanks Ryan.

That's also a good point about annex b, hopefully I can convince others on the team
as well to give up VAD :)

Cheers,
Zoltan

________________________________
From: Ryan Ratliff [rratliff at cisco.com]
Sent: Monday, January 28, 2013 5:54 PM
To: Kelemen, Zoltan [CORP/RO]
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] g729 gateway / transcoding?

You would only need transcoding if you have call flows that could connect this
gateway to a device across the wan that doesn't support g729. In that case if
you still want to have g729 go across the wan you'd need to be transcoding to 711
at the central site, not at the remote site gateway.

As far as the dial-peer goes I'd recommend a codec class with all the variants of
729 (that don't have 'b' in them) to prevent potential failures because of
variations in codec support across your devices or other gateways. You don't want
to use g729b because it includes voice activity detection (vad) and will cause even
poorer voice quality than you'll be getting with 729.

-Ryan

On Jan 28, 2013, at 4:43 AM, Zoltan.Kelemen at emerson.com<mailto:Zoltan.Kelemen at


emerson.com> wrote:

Hi,

This may be a very basic question, but I?m looking for a straight forward answer,
and so far couldn?t find anything.

I have a remote voice gateway, with an E1 card connecting to a PBX on one end and
SIP trunk towards the WAN on the other.
On the WAN I?d like to have g729.

The router has a PVDM3-64 inside.

Do I need to set up transcoding as well, or is it enough to specify


codec g729br8
on the voip dial-peer?

Thanks,

Zoltan Kelemen
Emerson

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130128/74744096/attachment.html>

From cristina_petre80 at yahoo.de Tue Jan 29 03:50:48 2013


From: cristina_petre80 at yahoo.de (Cristina Petre)
Date: Tue, 29 Jan 2013 09:50:48 +0100
Subject: [cisco-voip] VoIP for Branch Users
Message-ID: <83865095-7857-4496-B48D-6E2A30C71672@yahoo.de>

Hi all,

there are some Users in Branch Offices and they want to use ip phones. Is this
possible with the following routers on-site?

Cisco892-k9
Cisco891-k9
Cisco 1812 routers.

How is the implemetation in cucm? How can i Deploy this with ata-187 and dect or
analog phones?!

Many thanks in advance.

Best regards,
Cristina

Von meinem iPhone gesendet

From Zoltan.Kelemen at emerson.com Tue Jan 29 06:17:35 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Tue, 29 Jan 2013 11:17:35 +0000
Subject: [cisco-voip] FACILITY / Mandatory information element missing on
ISDN PRI to PBX
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061ACBC17BCE@GBLONZ-PMSGEM02.emrsn.org>

Hi,

A IOS Gateway is given that connects through a E1 ISDN PRI to a Nortel PBX, The
router acting as network side. (primary-net5)

Calls are coming in through a SIP trunk from two different CUCM clusters (both
being trunked to a central CUCM cluster that only acts as a call router).

Call setup works in both cases, SIP messages seem identical (through debug ccsip
messages)
However, once the call is established, on calls coming from "SITE A", a FACILITY
message is sent towards the PBX, with no information element. Because of this the
PBX throws an error and the gateway disconnects:

Jan 28 12:55:44.291 UTC: //478350/9DBBB8800000/CCAPI/cc_api_call_facility:


Interface=0x311D76B8, Call Id=478350
Jan 28 12:55:44.291 UTC: //478351/9DBBB8800000/CCAPI/ccCallFacility:
Call Id=478351
Jan 28 12:55:44.291 UTC: ISDN Se0/0/0:15 Q931: TX -> FACILITY pd = 8 callref =
0x0423
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: RX <- STATUS pd = 8 callref =
0x8423
Cause i = 0x81E0 - Mandatory information element missing
Call State i = 0x0A
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref =
0x0423
Cause i = 0x82E0 - Mandatory information element missing
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref =
0x8423
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref =
0x0423
Calls from "SITE B" never generate this facility message so the call works as
expected.

I tried to block forwarding of facility messages altogether on the PRI, but it


doesn't seem to make any difference (not even after restarting the serial
interface):

interface Serial0/0/0:15
description VOICE|E1 PRI towards local Nortel PBX
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no isdn outgoing ie facility
no cdp enable
!

Any clues as to what triggers the facility manager in the CUCM setup and/or how can
I block this on the gateway?

Thanks,
Zoltan Kelemen
Emerson

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/9d09ff76/attachment.html>

From rratliff at cisco.com Tue Jan 29 10:50:49 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 29 Jan 2013 10:50:49 -0500
Subject: [cisco-voip] FACILITY / Mandatory information element missing
on ISDN PRI to PBX
In-Reply-To: <F8E0CC3253A10C4CB137F12F568DAD061ACBC17BCE@GBLONZ-PMSGEM02.emrsn.org>
References: <F8E0CC3253A10C4CB137F12F568DAD061ACBC17BCE@GBLONZ-PMSGEM02.emrsn.org>
Message-ID: <F540E38B-ED43-43E5-804B-EA760DD13678@cisco.com>

What version of CUCM, and what do the ccm traces show around the time the facility
is generated? I assume this is an MGCP PRI?

-Ryan

On Jan 29, 2013, at 6:17 AM, Zoltan.Kelemen at emerson.com wrote:

Hi,

A IOS Gateway is given that connects through a E1 ISDN PRI to a Nortel PBX, The
router acting as network side. (primary-net5)

Calls are coming in through a SIP trunk from two different CUCM clusters (both
being trunked to a central CUCM cluster that only acts as a call router).

Call setup works in both cases, SIP messages seem identical (through debug ccsip
messages)
However, once the call is established, on calls coming from ?SITE A?, a FACILITY
message is sent towards the PBX, with no information element. Because of this the
PBX throws an error and the gateway disconnects:

Jan 28 12:55:44.291 UTC: //478350/9DBBB8800000/CCAPI/cc_api_call_facility:


Interface=0x311D76B8, Call Id=478350
Jan 28 12:55:44.291 UTC: //478351/9DBBB8800000/CCAPI/ccCallFacility:
Call Id=478351
Jan 28 12:55:44.291 UTC: ISDN Se0/0/0:15 Q931: TX -> FACILITY pd = 8 callref =
0x0423
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: RX <- STATUS pd = 8 callref =
0x8423
Cause i = 0x81E0 - Mandatory information element missing
Call State i = 0x0A
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref =
0x0423
Cause i = 0x82E0 - Mandatory information element missing
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref =
0x8423
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref =
0x0423

Calls from ?SITE B? never generate this facility message so the call works as
expected.

I tried to block forwarding of facility messages altogether on the PRI, but it


doesn?t seem to make any difference (not even after restarting the serial
interface):

interface Serial0/0/0:15
description VOICE|E1 PRI towards local Nortel PBX
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no isdn outgoing ie facility
no cdp enable
!

Any clues as to what triggers the facility manager in the CUCM setup and/or how can
I block this on the gateway?

Thanks,
Zoltan Kelemen
Emerson

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/25ae724c/attachment.html>

From VanMarenNP at ldschurch.org Tue Jan 29 11:00:28 2013


From: VanMarenNP at ldschurch.org (Nate VanMaren)
Date: Tue, 29 Jan 2013 16:00:28 +0000
Subject: [cisco-voip] http download of firmware matrix
Message-ID: <2F143E71016CA34C924BF4C33AEF211056EBCED1@W12112.ldschurch.org>

I have lots of phones at remote sites. This has always been a challenge to get
firmware pushed to them. HTTP Download, peer firmware sharing, and Load Server
have helped, but the 6900s don't have peer firmware sharing or load server
capability.

I got tired of trying to remember/look up what version added HTTP download so I


made myself a little chart, I share it here because I am cool like that.

Model

Version HTTP downloaded enabled

Upgrade considerations

6901

???

need unsigned load to get to 9.x firmware

6911

???

need unsigned load to get to 9.x firmware

6921

9.2(1)

need unsigned load to get to 9.x firmware

6941

9.2(1)

need unsigned load to get to 9.x firmware

6945

9.2(1)

need unsigned load to get to 9.x firmware

6961

9.2(1)

need unsigned load to get to 9.x firmware

7905

Probably not going to be enabled

7906
9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7911

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7912

Probably not going to be enabled

7931

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7937

Probably not going to be enabled

7940

Probably not going to be enabled

7941

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7942

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7945

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7960

Probably not going to be enabled

7961

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7962

9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+

7965

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7970

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7971

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

7975

9.3(1)

need 8.3(3) to 8.5(2) to get to 8.5(3)+

8941

9.2(3)

need 9.3.1 to get to 9.3.2

8945

9.2(3)

need 9.3.1 to get to 9.3.2

8961

9.1(1)+Peer Firmware

9951

9.1(1)+Peer Firmware

9971

9.1(1)+Peer Firmware

Does anyone know if the 6901/6911s support http download and what version it was
added? I have looked through all of the release notes and did not see it
highlighted.

Thanks
-Nate
NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/067b14d5/attachment.html>

From rratliff at cisco.com Tue Jan 29 11:46:06 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 29 Jan 2013 11:46:06 -0500
Subject: [cisco-voip] http download of firmware matrix
In-Reply-To: <2F143E71016CA34C924BF4C33AEF211056EBCED1@W12112.ldschurch.org>
References: <2F143E71016CA34C924BF4C33AEF211056EBCED1@W12112.ldschurch.org>
Message-ID: <2B86388C-AFC6-4C01-8709-F0F8AD915E3F@cisco.com>

6901/11 is the same family as the other 69XX models but did not get HTTP download
in 9.2(1) and I would not expect them to pick it up in the future. I don't know
the reason for them being left out but they don't seem to be getting many of the
new features other 69XXs are over the last few releases.

-Ryan

On Jan 29, 2013, at 11:00 AM, Nate VanMaren <VanMarenNP at ldschurch.org> wrote:

I have lots of phones at remote sites. This has always been a challenge to get
firmware pushed to them. HTTP Download, peer firmware sharing, and Load Server
have helped, but the 6900s don?t have peer firmware sharing or load server
capability.

I got tired of trying to remember/look up what version added HTTP download so I


made myself a little chart, I share it here because I am cool like that.

Model
Version HTTP downloaded enabled
Upgrade considerations
6901
???
need unsigned load to get to 9.x firmware
6911
???
need unsigned load to get to 9.x firmware
6921
9.2(1)
need unsigned load to get to 9.x firmware
6941
9.2(1)
need unsigned load to get to 9.x firmware
6945
9.2(1)
need unsigned load to get to 9.x firmware
6961
9.2(1)
need unsigned load to get to 9.x firmware
7905
Probably not going to be enabled
7906
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7911
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7912
Probably not going to be enabled
7931
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7937
Probably not going to be enabled
7940
Probably not going to be enabled
7941
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7942
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7945
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7960
Probably not going to be enabled
7961
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7962
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7965
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7970
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7971
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7975
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
8941
9.2(3)
need 9.3.1 to get to 9.3.2
8945
9.2(3)
need 9.3.1 to get to 9.3.2
8961
9.1(1)+Peer Firmware
9951
9.1(1)+Peer Firmware
9971
9.1(1)+Peer Firmware
Does anyone know if the 6901/6911s support http download and what version it was
added? I have looked through all of the release notes and did not see it
highlighted.

Thanks
-Nate

NOTICE: This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/e12cf819/attachment.html>

From Ariel.ROZA at LA.LOGICALIS.COM Tue Jan 29 11:22:53 2013


From: Ariel.ROZA at LA.LOGICALIS.COM (ROZA, Ariel)
Date: Tue, 29 Jan 2013 16:22:53 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <97D19F256B859A48A6A93E8A9210E52A84331DCF@BYTESEXCH2K10N1.bytes.local>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
<97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
<33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>
<97D19F256B859A48A6A93E8A9210E52A84331DCF@BYTESEXCH2K10N1.bytes.local>
Message-ID: <ADA96573E777E542A8C51E329C001EE70604CE5D@SAR-DC-
EXC01.LA.LOGICALIS.COM>

Rynard,

About the explanation? It seems that the H323 Gateway does not like the IP Address
change when you put the call on hold. The audio stream source ip address changes
from your phone to the assigned MOH server, and when you release the call, it goes
back from the MOH server to your phone.
The use of MTP masks this behavior to the gateway.

I would check that the Gateways IOS is updated.

Hth,

Ariel.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Rynard Coetzee
Sent: lunes, 28 de enero de 2013 11:29 a.m.
To: Carlo
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold
Not in my case ,I can actually see the MTP resources are active and in use on my GW
,using show sccp connections .

From: Carlo [mailto:carlo_calabrese2006 at yahoo.com]


Sent: 28 January 2013 04:23 PM
To: Rynard Coetzee
Cc: Ahmed Elnagar; Wes Sisk; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold

We ran into the same problem when we upgraded to 8.6 and we use SIP. TAC said CUCM
will ask for the resource but never uses it.

Sent from my iPad

On Jan 28, 2013, at 12:16 AM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:
Hi
MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]<mailto:


[mailto:ahmed_elnagar at hotmail.com]>
Sent: 27 January 2013 04:20 PM
To: 'Wes Sisk'; Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] Call drops after taking off hold

Check you media termination point configuration also.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Wes Sisk
Sent: Friday, January 25, 2013 6:33 PM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Typically this happens because the hold actually failed. did the PSTN user actually
hear music on hold? look for codec mismatches or misconfiguration in delivering MoH
to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a ? Bearer capability not implemented? error. Any
ideas what the problem could be ?
Regards
Rynard
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/4fc746be/attachment.html>

From Ariel.ROZA at LA.LOGICALIS.COM Tue Jan 29 11:24:31 2013


From: Ariel.ROZA at LA.LOGICALIS.COM (ROZA, Ariel)
Date: Tue, 29 Jan 2013 16:24:31 +0000
Subject: [cisco-voip] Bulk Import of Gateways - CUCM 8.6
In-Reply-To: <2217B727-B03B-4A63-BD5D-BCCD1B499A4E@gmail.com>
References: <CAF5YbzV3gHHCyfQ3+CmG12iKgzAxXtWyeZ=H=m3EUwmSVpzbPA@mail.gmail.com>
<CAF5YbzVAW6sECtFB+19O4pFpe9eLVshO95rFwsUxJ8FCeua3bw@mail.gmail.com>
<235B2220-597D-455A-BA7F-513E153E5D20@cisco.com>
<2217B727-B03B-4A63-BD5D-BCCD1B499A4E@gmail.com>
Message-ID: <ADA96573E777E542A8C51E329C001EE70604CE6F@SAR-DC-
EXC01.LA.LOGICALIS.COM>

Kris,

Care to share your conclusions? ?

Regards,

A.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Kris Edgar
Sent: viernes, 25 de enero de 2013 06:15 p.m.
To: Wes Sisk
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Bulk Import of Gateways - CUCM 8.6

Indeed I do!! However that's the reality of financial cuts in the public sector.

All sorted now though.....don't know what I was worried about!!

Cheers

Kris

Sent from my iPad

On 25 Jan 2013, at 16:23, Wes Sisk <wsisk at cisco.com<mailto:wsisk at cisco.com>>


wrote:
sounds like you need a test bed?

On Jan 17, 2013, at 9:22 AM, Kris Edgar <kris.edgar82 at


gmail.com<mailto:kris.edgar82 at gmail.com>> wrote:

Hi Folks,
Great group going on here!! I'm hoping someone can give me advice on the
following:

We are using CUCM 8.6 and are looking to import a large number of H323 GW's, RG's,
RL's etc.
I've used the Import/Export tool and selected GW's and used the "Check dependency"
to capture all the other associated fields.
I now have a tar file with all the CSV's needed. Happy so far!!
I'm not too sure if i need to keep the existing data in the CSV's, and add to it?
Or can I strip out the existing elements (keeping the headers) and just have the
new file with the elements that i need to import?
I have a horrible thought that if i re-import the file without the original GW's
etc, it might delete them from CM and leave me with my new GW's etc.
Paranoid.com<http://Paranoid.com>!!!
Thanks for your help on this.

Kris

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/dae88029/attachment.html>

From abbaseo at gmail.com Tue Jan 29 12:59:41 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 29 Jan 2013 17:59:41 +0000
Subject: [cisco-voip] error: Unprovisioned
Message-ID: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>

Hi,

getting this unprovisioned error on the physcial phones i.e. 7942/75.


this is after a fresh vm install of CM 8.

i have checked the phone has got its firmware and list of CM's.

in servicability i have checekd all the services

not sure what else is blocking these phones from coming up. tried it with
CIPC and they are working fine. only the phy. phones.

the status mesg on the phones says,


"TFTP Error: ram/SEP.......cnf.xml"

any help please!


thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/d7878d99/attachment.html>
From rratliff at cisco.com Tue Jan 29 13:16:05 2013
From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 29 Jan 2013 13:16:05 -0500
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
Message-ID: <BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>

Unprovisioned typically means the phone isn't configured in CUCM.

-Ryan

On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:

Hi,

getting this unprovisioned error on the physcial phones i.e. 7942/75.


this is after a fresh vm install of CM 8.

i have checked the phone has got its firmware and list of CM's.

in servicability i have checekd all the services

not sure what else is blocking these phones from coming up. tried it with CIPC and
they are working fine. only the phy. phones.

the status mesg on the phones says,


"TFTP Error: ram/SEP.......cnf.xml"

any help please!


thanks
--
@bbas..
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/37623f70/attachment.html>

From abbaseo at gmail.com Tue Jan 29 13:20:37 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 29 Jan 2013 18:20:37 +0000
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
Message-ID: <CAFdHCp4XMApWNLHfnfEF50014BB3VYkwzWQqLxfPEg-j3z-RHQ@mail.gmail.com>

well, the phone actualy is there in the CM. with the correct mac.

On 29 January 2013 18:16, Ryan Ratliff <rratliff at cisco.com> wrote:

> Unprovisioned typically means the phone isn't configured in CUCM.


>
> -Ryan
>
> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> Hi,
>
> getting this unprovisioned error on the physcial phones i.e. 7942/75.
> this is after a fresh vm install of CM 8.
>
> i have checked the phone has got its firmware and list of CM's.
>
> in servicability i have checekd all the services
>
> not sure what else is blocking these phones from coming up. tried it with
> CIPC and they are working fine. only the phy. phones.
>
> the status mesg on the phones says,
> "TFTP Error: ram/SEP.......cnf.xml"
>
>
> any help please!
> thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/fb6baa53/attachment.html>

From kennethwhayes at gmail.com Tue Jan 29 13:22:00 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Tue, 29 Jan 2013 13:22:00 -0500
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
Message-ID: <5068068431302989518@unknownmsgid>

SIP or SCCP that you are trying to setup?

Sent from my iPhone

On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

Unprovisioned typically means the phone isn't configured in CUCM.

-Ryan

On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
Hi,

getting this unprovisioned error on the physcial phones i.e. 7942/75.


this is after a fresh vm install of CM 8.

i have checked the phone has got its firmware and list of CM's.

in servicability i have checekd all the services

not sure what else is blocking these phones from coming up. tried it with
CIPC and they are working fine. only the phy. phones.

the status mesg on the phones says,


"TFTP Error: ram/SEP.......cnf.xml"

any help please!


thanks
--
@bbas..
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/7e23a610/attachment.html>

From abbaseo at gmail.com Tue Jan 29 13:24:40 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 29 Jan 2013 18:24:40 +0000
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <5068068431302989518@unknownmsgid>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
Message-ID: <CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>

its the standard SCCP

On 29 January 2013 18:22, Kenneth Hayes <kennethwhayes at gmail.com> wrote:

> SIP or SCCP that you are trying to setup?


>
> Sent from my iPhone
>
> On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
> Unprovisioned typically means the phone isn't configured in CUCM.
>
> -Ryan
>
> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> Hi,
>
> getting this unprovisioned error on the physcial phones i.e. 7942/75.
> this is after a fresh vm install of CM 8.
>
> i have checked the phone has got its firmware and list of CM's.
>
> in servicability i have checekd all the services
>
> not sure what else is blocking these phones from coming up. tried it with
> CIPC and they are working fine. only the phy. phones.
>
> the status mesg on the phones says,
> "TFTP Error: ram/SEP.......cnf.xml"
>
>
> any help please!
> thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/4c2811b2/attachment.html>

From rratliff at cisco.com Tue Jan 29 13:34:44 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Tue, 29 Jan 2013 13:34:44 -0500
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <5068068431302989518@unknownmsgid>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
Message-ID: <27C775AE-9947-4335-BE08-648318BD2CEE@cisco.com>

Have the phones registered to another cluster before this one? If so check for ITL
issues. The painful part about errors like the one you see in the status messages
log is it doesn't say what TFTP server the error came from. You need to look at
console logs or a packet capture to see what the phone is really doing.

If you enable auto-registration does that allow them to get registered?


-Ryan

On Jan 29, 2013, at 1:22 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:

SIP or SCCP that you are trying to setup?

Sent from my iPhone

On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> Unprovisioned typically means the phone isn't configured in CUCM.


>
> -Ryan
>
> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> Hi,
>
> getting this unprovisioned error on the physcial phones i.e. 7942/75.
> this is after a fresh vm install of CM 8.
>
> i have checked the phone has got its firmware and list of CM's.
>
> in servicability i have checekd all the services
>
> not sure what else is blocking these phones from coming up. tried it with CIPC
and they are working fine. only the phy. phones.
>
> the status mesg on the phones says,
> "TFTP Error: ram/SEP.......cnf.xml"
>
>
> any help please!
> thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/c5eb229c/attachment.html>

From abbaseo at gmail.com Tue Jan 29 13:43:03 2013


From: abbaseo at gmail.com (abbas Wali)
Date: Tue, 29 Jan 2013 18:43:03 +0000
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
<CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
Message-ID: <CAFdHCp6bARW3zN6HHTbq863=Vy9wmfYjAfLHtOJLUvz+vzL0Ng@mail.gmail.com>

interesting.

i think its mising the "load file"


when its reg with the LIVE CM the load file field on the phone says
"SCCP42.9-1-1SR1S"
but incase of reg with the test CM8 it says "term42.default"

On 29 January 2013 18:24, abbas Wali <abbaseo at gmail.com> wrote:

> its the standard SCCP


>
>
> On 29 January 2013 18:22, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>
>> SIP or SCCP that you are trying to setup?
>>
>> Sent from my iPhone
>>
>> On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>> Unprovisioned typically means the phone isn't configured in CUCM.
>>
>> -Ryan
>>
>> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> Hi,
>>
>> getting this unprovisioned error on the physcial phones i.e. 7942/75.
>> this is after a fresh vm install of CM 8.
>>
>> i have checked the phone has got its firmware and list of CM's.
>>
>> in servicability i have checekd all the services
>>
>> not sure what else is blocking these phones from coming up. tried it with
>> CIPC and they are working fine. only the phy. phones.
>>
>> the status mesg on the phones says,
>> "TFTP Error: ram/SEP.......cnf.xml"
>>
>>
>> any help please!
>> thanks
>> --
>> @bbas..
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/b90c6108/attachment.html>

From tednugent73 at gmail.com Tue Jan 29 14:01:00 2013


From: tednugent73 at gmail.com (Ted Nugent)
Date: Tue, 29 Jan 2013 14:01:00 -0500
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <CAFdHCp6bARW3zN6HHTbq863=Vy9wmfYjAfLHtOJLUvz+vzL0Ng@mail.gmail.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
<CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
<CAFdHCp6bARW3zN6HHTbq863=Vy9wmfYjAfLHtOJLUvz+vzL0Ng@mail.gmail.com>
Message-ID: <CAHs2VYshb4zcAkL+jhT8pga-X27-MNVfP1RA92nFgE0od1n+Fw@mail.gmail.com>

only seen this when a customer accidentially configured the wrong model
phone in CM...

On Tue, Jan 29, 2013 at 1:43 PM, abbas Wali <abbaseo at gmail.com> wrote:

> interesting.
>
> i think its mising the "load file"
> when its reg with the LIVE CM the load file field on the phone says
> "SCCP42.9-1-1SR1S"
> but incase of reg with the test CM8 it says "term42.default"
>
>
> On 29 January 2013 18:24, abbas Wali <abbaseo at gmail.com> wrote:
>
>> its the standard SCCP
>>
>>
>> On 29 January 2013 18:22, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>>
>>> SIP or SCCP that you are trying to setup?
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>>
>>> Unprovisioned typically means the phone isn't configured in CUCM.
>>>
>>> -Ryan
>>>
>>> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> getting this unprovisioned error on the physcial phones i.e. 7942/75.
>>> this is after a fresh vm install of CM 8.
>>>
>>> i have checked the phone has got its firmware and list of CM's.
>>>
>>> in servicability i have checekd all the services
>>>
>>> not sure what else is blocking these phones from coming up. tried it
>>> with CIPC and they are working fine. only the phy. phones.
>>>
>>> the status mesg on the phones says,
>>> "TFTP Error: ram/SEP.......cnf.xml"
>>>
>>>
>>> any help please!
>>> thanks
>>> --
>>> @bbas..
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> @bbas..
>>
>
>
>
> --
> @bbas..
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/789e60b4/attachment.html>

From Dana_Tong at bridgepoint.com.au Tue Jan 29 17:32:28 2013


From: Dana_Tong at bridgepoint.com.au (Dana Tong)
Date: Tue, 29 Jan 2013 22:32:28 +0000
Subject: [cisco-voip] Reporting on Native Call Queuing in UCM 9.x
Message-ID: <F70E081B078BC5408CF74D42B09E7C6601B8D7D5@SVEXCBNE01.bpc.local>
Hi all,

Do you guys know if there is any basic reporting for the native call queuing that
is included in the new UCM 9.x suite?

Cheers
Dana

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/1f7c2ca5/attachment.html>

From miwilusz at cisco.com Tue Jan 29 18:51:41 2013


From: miwilusz at cisco.com (Mike Wilusz (miwilusz))
Date: Tue, 29 Jan 2013 23:51:41 +0000
Subject: [cisco-voip] Reporting on Native Call Queuing in UCM 9.x
In-Reply-To: <F70E081B078BC5408CF74D42B09E7C6601B8D7D5@SVEXCBNE01.bpc.local>
Message-ID: <751F47C39D30604DBBE42896FD3869E62549A5BD@xmb-rcd-x02.cisco.com>

Dana,

New fields were added to the CUCM CDRs in order to support basic reporting of the
native call queuing functionality. They are ?wasCallQueued? and ?
totalWaitTimeInQueue?. ?wasCallQueued? indicates if a call was put into queue or
not (1-Yes / 0-No), and ?totalWaitTimeInQueue? indicates how long the caller has
stayed in the queue (in seconds).

-mike

From: Dana Tong <Dana_Tong at bridgepoint.com.au<mailto:Dana_Tong at


bridgepoint.com.au>>
Date: Tuesday, January 29, 2013 5:32 PM
To: "cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>" <cisco-
voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] Reporting on Native Call Queuing in UCM 9.x

Hi all,

Do you guys know if there is any basic reporting for the native call queuing that
is included in the new UCM 9.x suite?

Cheers
Dana

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/51781129/attachment.html>

From kennethwhayes at gmail.com Tue Jan 29 13:26:35 2013


From: kennethwhayes at gmail.com (Kenneth Hayes)
Date: Tue, 29 Jan 2013 13:26:35 -0500
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
<CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
Message-ID: <-4205605442812364652@unknownmsgid>

Make sure you are using the correct phone button template.

Sent from my iPad

On Jan 29, 2013, at 1:24 PM, abbas Wali <abbaseo at gmail.com> wrote:

its the standard SCCP

On 29 January 2013 18:22, Kenneth Hayes <kennethwhayes at gmail.com> wrote:

> SIP or SCCP that you are trying to setup?


>
> Sent from my iPhone
>
> On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
> Unprovisioned typically means the phone isn't configured in CUCM.
>
> -Ryan
>
> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> Hi,
>
> getting this unprovisioned error on the physcial phones i.e. 7942/75.
> this is after a fresh vm install of CM 8.
>
> i have checked the phone has got its firmware and list of CM's.
>
> in servicability i have checekd all the services
>
> not sure what else is blocking these phones from coming up. tried it with
> CIPC and they are working fine. only the phy. phones.
>
> the status mesg on the phones says,
> "TFTP Error: ram/SEP.......cnf.xml"
>
>
> any help please!
> thanks
> --
> @bbas..
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/52419f79/attachment.html>

From grccie at gmail.com Tue Jan 29 20:09:20 2013


From: grccie at gmail.com (Gr)
Date: Wed, 30 Jan 2013 12:09:20 +1100
Subject: [cisco-voip] H323 Call preserve feature
Message-ID: <223049A4-088F-43DE-AC61-0AA4EB5A9A07@gmail.com>

Hi List,

Would the h323 call preserve work with IOS 12.4 or prior 15?

If we enable h323 call preserve from cucm (8.6 in this case) but have gateways with
IOS 12.x and not 15 - would it make any difference? If it does not works, it makes
no difference whether the call preserve is enabled in CUCM or not?? Or will it be
still of any use?

Thanks

Sent from my iPhone

From Zoltan.Kelemen at emerson.com Tue Jan 29 21:50:28 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Wed, 30 Jan 2013 02:50:28 +0000
Subject: [cisco-voip] FACILITY / Mandatory information element missing
on ISDN PRI to PBX
In-Reply-To: <F540E38B-ED43-43E5-804B-EA760DD13678@cisco.com>
References: <F8E0CC3253A10C4CB137F12F568DAD061ACBC17BCE@GBLONZ-PMSGEM02.emrsn.org>,
<F540E38B-ED43-43E5-804B-EA760DD13678@cisco.com>
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061ACBE241F2@GBLONZ-PMSGEM02.emrsn.org>

CUCM's involved are all some 8.x variant, and the trunks are all SIP.
It's a slightly complicated setup (for reasons too long to explain here) so here's
a drawing:
http://s1115.beta.photobucket.com/user/kdotzoltan/media/CallFlow_zps0ad6283d.png.ht
ml
(excuse my lack of artistic skills :) )

I haven't thought about looking at CCM traces, but will be doing so tomorrow.

Cheers,
Zoltan

________________________________
From: Ryan Ratliff [rratliff at cisco.com]
Sent: Tuesday, January 29, 2013 5:50 PM
To: Kelemen, Zoltan [CORP/RO]
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FACILITY / Mandatory information element missing on ISDN
PRI to PBX

What version of CUCM, and what do the ccm traces show around the time the facility
is generated? I assume this is an MGCP PRI?
-Ryan

On Jan 29, 2013, at 6:17 AM, Zoltan.Kelemen at emerson.com<mailto:Zoltan.Kelemen at


emerson.com> wrote:

Hi,

A IOS Gateway is given that connects through a E1 ISDN PRI to a Nortel PBX, The
router acting as network side. (primary-net5)

Calls are coming in through a SIP trunk from two different CUCM clusters (both
being trunked to a central CUCM cluster that only acts as a call router).

Call setup works in both cases, SIP messages seem identical (through debug ccsip
messages)
However, once the call is established, on calls coming from ?SITE A?, a FACILITY
message is sent towards the PBX, with no information element. Because of this the
PBX throws an error and the gateway disconnects:

Jan 28 12:55:44.291 UTC: //478350/9DBBB8800000/CCAPI/cc_api_call_facility:


Interface=0x311D76B8, Call Id=478350
Jan 28 12:55:44.291 UTC: //478351/9DBBB8800000/CCAPI/ccCallFacility:
Call Id=478351
Jan 28 12:55:44.291 UTC: ISDN Se0/0/0:15 Q931: TX -> FACILITY pd = 8 callref =
0x0423
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: RX <- STATUS pd = 8 callref =
0x8423
Cause i = 0x81E0 - Mandatory information element missing
Call State i = 0x0A
Jan 28 12:55:44.311 UTC: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref =
0x0423
Cause i = 0x82E0 - Mandatory information element missing
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref =
0x8423
Jan 28 12:55:44.355 UTC: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref =
0x0423

Calls from ?SITE B? never generate this facility message so the call works as
expected.

I tried to block forwarding of facility messages altogether on the PRI, but it


doesn?t seem to make any difference (not even after restarting the serial
interface):

interface Serial0/0/0:15
description VOICE|E1 PRI towards local Nortel PBX
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no isdn outgoing ie facility
no cdp enable
!

Any clues as to what triggers the facility manager in the CUCM setup and/or how can
I block this on the gateway?

Thanks,
Zoltan Kelemen
Emerson

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/4dd6ca43/attachment.html>

From grccie at gmail.com Tue Jan 29 23:20:24 2013


From: grccie at gmail.com (Gr)
Date: Wed, 30 Jan 2013 15:20:24 +1100
Subject: [cisco-voip] H323 Call preserve feature
In-Reply-To: <F70E081B078BC5408CF74D42B09E7C6601B8E6D8@SVEXCBNE01.bpc.local>
References: <223049A4-088F-43DE-AC61-0AA4EB5A9A07@gmail.com>
<F70E081B078BC5408CF74D42B09E7C6601B8E6D8@SVEXCBNE01.bpc.local>
Message-ID: <09CBAE64-936F-42B7-A53D-0B867DA43A8C@gmail.com>

Dana - thanks for your reply, are you able to provide a brief config or any
pointer?

Thanks

Sent from my iPhone

On 30/01/2013, at 3:10 PM, Dana Tong <Dana_Tong at bridgepoint.com.au> wrote:

> Hi,
>
> Yes call preservation will work with IOS 12.4.x when using H.323. Just be sure to
have the appropriate configuration.
>
> Cheers
> Dana
>
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Gr
> Sent: Wednesday, 30 January 2013 11:09 AM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] H323 Call preserve feature
>
> Hi List,
>
> Would the h323 call preserve work with IOS 12.4 or prior 15?
>
> If we enable h323 call preserve from cucm (8.6 in this case) but have gateways
with IOS 12.x and not 15 - would it make any difference? If it does not works, it
makes no difference whether the call preserve is enabled in CUCM or not?? Or will
it be still of any use?
>
> Thanks
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

From erickbee at gmail.com Tue Jan 29 23:57:10 2013


From: erickbee at gmail.com (Erick B.)
Date: Tue, 29 Jan 2013 22:57:10 -0600
Subject: [cisco-voip] error: Unprovisioned
In-Reply-To: <-4205605442812364652@unknownmsgid>
References: <CAFdHCp55NvhSh+J9r2u9i+uus+Eu76EDpcfd7nKYP4qZQYW63Q@mail.gmail.com>
<BEDA875D-675D-426F-A8E5-AE4D3863C7E6@cisco.com>
<5068068431302989518@unknownmsgid>
<CAFdHCp6ymPLjRB2WdQ=+aNMHyQD+6bjyBoHiUMh4hb3bsXKTSw@mail.gmail.com>
<-4205605442812364652@unknownmsgid>
Message-ID: <CAHSnBQxAG04__yg7r2HQWhChgn3CeWwUZ+_20vWBV9EsvuRo3Q@mail.gmail.com>

I've seen the unprovisioned message with SIP phones that were in Call
Manager but had no DN configured on the phone.

On Tue, Jan 29, 2013 at 12:26 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Make sure you are using the correct phone button template.
>
> Sent from my iPad
>
> On Jan 29, 2013, at 1:24 PM, abbas Wali <abbaseo at gmail.com> wrote:
>
> its the standard SCCP
>
> On 29 January 2013 18:22, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
>
>> SIP or SCCP that you are trying to setup?
>>
>> Sent from my iPhone
>>
>> On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>> Unprovisioned typically means the phone isn't configured in CUCM.
>>
>> -Ryan
>>
>> On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
>>
>> Hi,
>>
>> getting this unprovisioned error on the physcial phones i.e. 7942/75.
>> this is after a fresh vm install of CM 8.
>>
>> i have checked the phone has got its firmware and list of CM's.
>>
>> in servicability i have checekd all the services
>>
>> not sure what else is blocking these phones from coming up. tried it with
>> CIPC and they are working fine. only the phy. phones.
>>
>> the status mesg on the phones says,
>> "TFTP Error: ram/SEP.......cnf.xml"
>>
>>
>> any help please!
>> thanks
>> --
>> @bbas..
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/54a0a552/attachment.html>

From grccie at gmail.com Wed Jan 30 00:26:56 2013


From: grccie at gmail.com (Gr)
Date: Wed, 30 Jan 2013 16:26:56 +1100
Subject: [cisco-voip] H323 Call preserve feature
In-Reply-To: <09CBAE64-936F-42B7-A53D-0B867DA43A8C@gmail.com>
References: <223049A4-088F-43DE-AC61-0AA4EB5A9A07@gmail.com>
<F70E081B078BC5408CF74D42B09E7C6601B8E6D8@SVEXCBNE01.bpc.local>
<09CBAE64-936F-42B7-A53D-0B867DA43A8C@gmail.com>
Message-ID: <220D2684-5782-42C9-AFF8-BB47BB3174B2@gmail.com>

And to be more clear, under h323, I dont see a call preserve option. Looks like its
an older IOS, and this feature was introduced later on. Is there any option other
than to upgrade IOS.

Sent from my iPhone

On 30/01/2013, at 3:20 PM, Gr <grccie at gmail.com> wrote:

> Dana - thanks for your reply, are you able to provide a brief config or any
pointer?
>
> Thanks
>
> Sent from my iPhone
>
> On 30/01/2013, at 3:10 PM, Dana Tong <Dana_Tong at bridgepoint.com.au> wrote:
>
>> Hi,
>>
>> Yes call preservation will work with IOS 12.4.x when using H.323. Just be sure
to have the appropriate configuration.
>>
>> Cheers
>> Dana
>>
>>
>> -----Original Message-----
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Gr
>> Sent: Wednesday, 30 January 2013 11:09 AM
>> To: cisco-voip at puck.nether.net
>> Subject: [cisco-voip] H323 Call preserve feature
>>
>> Hi List,
>>
>> Would the h323 call preserve work with IOS 12.4 or prior 15?
>>
>> If we enable h323 call preserve from cucm (8.6 in this case) but have gateways
with IOS 12.x and not 15 - would it make any difference? If it does not works, it
makes no difference whether the call preserve is enabled in CUCM or not?? Or will
it be still of any use?
>>
>> Thanks
>>
>> Sent from my iPhone
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/ae2d4829/attachment.html>

From burdag at gmail.com Wed Jan 30 02:20:34 2013


From: burdag at gmail.com (Burak Dag)
Date: Wed, 30 Jan 2013 09:20:34 +0200
Subject: [cisco-voip] =?iso-8859-1?q?CUPS_=A6_IM_Address_-_Username_with_M?=
=?iso-8859-1?q?ail_-_Rewrite=3F?=
Message-ID: <CAMkhhq=hHACWCNnrGPaNQKcjP_WPs0FYCqKTdqefzpqcm9M=Mg@mail.gmail.com>

Hi All,

We are planning to change our CUCM userID/Usernames from samAccountName to


mail Attribute (ldap synced).

CUPs creates now a IM-Address like blbla at maildomain@topleveldomain. Normaly


the mail-domain is the toplevel-domain. Automaticly it adds the domain
suffix behind the mail address.

Is it and how is it possible to define in CUPS that the IM-Address is the


login (blbla at maildomain)?
Thanks for help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/a8809df1/attachment.html>

From sheref_hf at hotmail.com Wed Jan 30 07:13:17 2013


From: sheref_hf at hotmail.com (sheref hf)
Date: Wed, 30 Jan 2013 12:13:17 +0000
Subject: [cisco-voip] cisco IP Phone 7960 with MS Lync 2010
Message-ID: <SNT120-W14204B82CB62798D2018D2911E0@phx.gbl>

Hi all
I want to connect cisco 7962 phones with Lync 2010 but I can't
Phones already have SIP Firmware 8.3 .... but I want to configure phone with
Authenticate ID and password and SIP server IP address I searched for any SIP
configuration on phones but I didn't find anything?
Can you help me to integrate these phones with Lync 2010????

BR,

Sherif

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/d08fba36/attachment.html>

From carlo_calabrese2006 at yahoo.com Wed Jan 30 09:27:17 2013


From: carlo_calabrese2006 at yahoo.com (Carlo)
Date: Wed, 30 Jan 2013 06:27:17 -0800
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <ADA96573E777E542A8C51E329C001EE70604CE5D@SAR-DC-
EXC01.LA.LOGICALIS.COM>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
<97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
<33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>
<97D19F256B859A48A6A93E8A9210E52A84331DCF@BYTESEXCH2K10N1.bytes.local>
<ADA96573E777E542A8C51E329C001EE70604CE5D@SAR-DC-EXC01.LA.LOGICALIS.COM>
Message-ID: <0DF8D130-8282-40D9-A314-C221453BA951@yahoo.com>

Are you running Multicast for your MOH? try turning it off and see if it clears
the problem. Please let me know. I have a problem with Multicast doing almost the
same thing. I am running SIP

Sent from my iPad

On Jan 29, 2013, at 8:22 AM, "ROZA, Ariel" <Ariel.ROZA at LA.LOGICALIS.COM> wrote:
> Rynard,
>
> About the explanation? It seems that the H323 Gateway does not like the IP
Address change when you put the call on hold. The audio stream source ip address
changes from your phone to the assigned MOH server, and when you release the call,
it goes back from the MOH server to your phone.
> The use of MTP masks this behavior to the gateway.
>
> I would check that the Gateways IOS is updated.
>
> Hth,
>
> Ariel.
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Rynard Coetzee
> Sent: lunes, 28 de enero de 2013 11:29 a.m.
> To: Carlo
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Call drops after taking off hold
>
> Not in my case ,I can actually see the MTP resources are active and in use on my
GW ,using show sccp connections .
>
> From: Carlo [mailto:carlo_calabrese2006 at yahoo.com]
> Sent: 28 January 2013 04:23 PM
> To: Rynard Coetzee
> Cc: Ahmed Elnagar; Wes Sisk; cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Call drops after taking off hold
>
> We ran into the same problem when we upgraded to 8.6 and we use SIP. TAC said
CUCM will ask for the resource but never uses it.
>
> Sent from my iPad
>
> On Jan 28, 2013, at 12:16 AM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za>
wrote:
>
> Hi
> MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?
>
> From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]
> Sent: 27 January 2013 04:20 PM
> To: 'Wes Sisk'; Rynard Coetzee
> Cc: cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] Call drops after taking off hold
>
> Check you media termination point configuration also.
>
> Regards,
> Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
> <image001.jpg>
>
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Wes Sisk
> Sent: Friday, January 25, 2013 6:33 PM
> To: Rynard Coetzee
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Call drops after taking off hold
>
> Typically this happens because the hold actually failed. did the PSTN user
actually hear music on hold? look for codec mismatches or misconfiguration in
delivering MoH to the PSTN caller.
>
> /wes
>
> On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za>
wrote:
>
> Hi
> I have the following scenario at a client site ,call comes from PSTN via H323
GW ,I can answer the call and place the caller on hold ,when I try and resume the
call ,the Telco drops the call with a ? Bearer capability not implemented? error.
Any ideas what the problem could be ?
> Regards
> Rynard
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/a182ef16/attachment.html>

From Hagedorn at uni-koeln.de Wed Jan 30 10:28:14 2013


From: Hagedorn at uni-koeln.de (Sebastian Hagedorn)
Date: Wed, 30 Jan 2013 16:28:14 +0100
Subject: [cisco-voip] HuntListExhausted
Message-ID: <E229138ACF876F73639EBAAE@tyrion.rrz.uni-koeln.de>

Hi,

I'm relatively new to VoIP, but have more than 10 years of experience as a
Cisco network admin. We have been running CUCM, CUC and CUP, all version
8.6, since September 2012. All is seemingly running well, so now I'm trying
to understand the few alerts I'm seeing. Here's one:

Jan 17 11:55:31 ccm3 19: : ccm: 140892: ccm3: Jan 17 2013 10:55:31.173 UTC
: %UC_-3-UNKNOWN_ALARM:HuntListExhausted:
%[HuntListName=DE-CGN-1ST-LEVEL-HELPDESK-HL][AppID=Cisco
CallManager][ClusterID=StandAloneCluster][NodeID=ccm3]:

The configuration for the hunt pilot redirects both Forward Hunt No Answer
and Forward Hunt Busy to the hunt pilot itself. The Forward Maximum Hop
Count Required Field is 12 (default). According to the documentation the
hunt should continue for up to 30 minutes. The are three DNs in the line
group attached to the hunt list.

Here's my question: under what set of circumstances is this alert triggered


given the config outlined above? What's the result for the outside caller?

Thanks,
Sebastian
--
.:.Sebastian Hagedorn - Weyertal 121 (Geb?ude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:.
.:.Universit?t zu K?ln / Cologne University - ? +49-221-470-89578.:.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/02b9b662/attachment.p7s>

From schaehan at gmail.com Wed Jan 30 10:59:52 2013


From: schaehan at gmail.com (Shaihan Jaffrey)
Date: Wed, 30 Jan 2013 20:59:52 +0500
Subject: [cisco-voip] phone getting un register with temp fail message
Message-ID: <CAPXwYGQPQS=54OsKCOUPev25NixABVUusNoRRo-c0fs5_+KDbQ@mail.gmail.com>

Dear Team,
Phones at one WAN site are getting unregistered intermittently with temp
fail message on the ip phone.
Below are some lines from CCM traces.

01/30/2013 16:29:43.915 CCM|StationInit: (0242133) alarmSeverity=2


text="10: Name=SEP002414B3FF43 Load= SCCP11.8-4-1SR1S Last=TCP-timeout"
parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988910><IP::10.1.34.2
40><DEV::SEP002414B3FF43>
01/30/2013 16:29:43.915 CCM|StationInit: (0242132) alarmSeverity=2
text="10: Name=SEP001FCAE85A2E Load= SCCP11.8-4-1SR1S Last=TCP-timeout"
parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988911><IP::10.1.49.2
39><DEV::SEP001FCAE85A2E>

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/ea2b12d5/attachment.html>

From MLinsemier at thedoctors.com Wed Jan 30 13:04:15 2013


From: MLinsemier at thedoctors.com (Linsemier, Matthew)
Date: Wed, 30 Jan 2013 10:04:15 -0800
Subject: [cisco-voip] phone getting un register with temp fail message
In-Reply-To: <CAPXwYGQPQS=54OsKCOUPev25NixABVUusNoRRo-c0fs5_+KDbQ@mail.gmail.com>
References: <CAPXwYGQPQS=54OsKCOUPev25NixABVUusNoRRo-c0fs5_+KDbQ@mail.gmail.com>
Message-ID: <11191743FBFAB44995641CE6E5FA2E7F10E64518@NPEXCHMB102.tdc.internal>
We saw this a lot on our old CUCM 6.1(x) server.

The issue was resolved when they moved to new firmware 9.3.1SR1 during our
transition to CUCM 8.6(4).

I would load the new device pack or maybe specific firmware for that model of phone
and test one to see if it resolves the issue.

Matt

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Shaihan Jaffrey
Sent: Wednesday, January 30, 2013 11:00 AM
To: Cisco VOIP
Subject: [cisco-voip] phone getting un register with temp fail message

Dear Team,
Phones at one WAN site are getting unregistered intermittently with temp fail
message on the ip phone.
Below are some lines from CCM traces.

01/30/2013 16:29:43.915 CCM|StationInit: (0242133) alarmSeverity=2 text="10:


Name=SEP002414B3FF43 Load= SCCP11.8-4-1SR1S Last=TCP-timeout" parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988910><IP::10.1.34.2
40><DEV::SEP002414B3FF43>
01/30/2013 16:29:43.915 CCM|StationInit: (0242132) alarmSeverity=2 text="10:
Name=SEP001FCAE85A2E Load= SCCP11.8-4-1SR1S Last=TCP-timeout" parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988911><IP::10.1.49.2
39><DEV::SEP001FCAE85A2E>

Regards.

Confidentiality Notice: This message and any attachments hereto may contain
confidential and privileged communications or information and/or attorney client
communications or work-product protected by law. The information contained herein
is transmitted for the sole use of the intended recipient(s). If you are not the
intended recipient or designated agent of the recipient of such information, you
are hereby notified that any use, dissemination, copying or retention of this e-
mail or the information contained herein is strictly prohibited and may subject you
to penalties under federal and/or state law. If you received this e-mail in error,
please notify the sender immediately and permanently delete this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/6228033b/attachment.html>

From rleetun at bouldercounty.org Wed Jan 30 15:36:47 2013


From: rleetun at bouldercounty.org (Leetun, Rob)
Date: Wed, 30 Jan 2013 20:36:47 +0000
Subject: [cisco-voip] Call forard release to another phone
Message-ID:
<493392CD07C6D045837BAE6AD397BE9C880E8F00@Mailbox2.boco.co.boulder.co.us>

Good afternoon,
I am wondering why Callmanager 8.6 will not allow the call leg to be released to
the call forwaded device. When a call is forwarded to another device in the
network and the person does not pick up the call. The call does not go that
person's voicemail box. It appears the call leg from the original device is
maintained until the person picks up the call on the device. Am I confusing you
all by now?

Rob

Robert E. Leetun, CCNA, CCNA+Voice


Network Engineer
Boulder County Information Services
2025 14th Street
Boulder, Colorado 80302
303-441-3866 (W)
303-441-3983 (F)

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/e168bfe6/attachment.html>

From mays at win.net Wed Jan 30 15:21:17 2013


From: mays at win.net (Joseph Mays)
Date: Wed, 30 Jan 2013 15:21:17 -0500
Subject: [cisco-voip] Active Voice Call MIB on AS5400
In-Reply-To: <11191743FBFAB44995641CE6E5FA2E7F10E64518@NPEXCHMB102.tdc.internal>
References: <CAPXwYGQPQS=54OsKCOUPev25NixABVUusNoRRo-c0fs5_+KDbQ@mail.gmail.com>
<11191743FBFAB44995641CE6E5FA2E7F10E64518@NPEXCHMB102.tdc.internal>
Message-ID: <14C752584DD2416D816779747CC34488@Gantry>

I have been trying to find out if there are two MIB?s I can query on an AS5400 to
track voice traffic. These would be the number of voice calls currently in progress
when the box is queried, and the total number of voice calls since the last time
the counter was cleared.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/5416e4d9/attachment.html>

From John.VanLaecke at ghd.com Wed Jan 30 16:18:56 2013


From: John.VanLaecke at ghd.com (John Van Laecke)
Date: Wed, 30 Jan 2013 21:18:56 +0000
Subject: [cisco-voip] H323 Call preserve feature
In-Reply-To: <223049A4-088F-43DE-AC61-0AA4EB5A9A07@gmail.com>
References: <223049A4-088F-43DE-AC61-0AA4EB5A9A07@gmail.com>
Message-ID: <CF2E16827204E249BB155D2C1F5C1EAB1ABC5660@GLB-EXMBX-
001.ghdnet.internal>

I have this feature running on .124-24.T7

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Gr
Sent: Wednesday, 30 January 2013 11:09 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] H323 Call preserve feature
Hi List,

Would the h323 call preserve work with IOS 12.4 or prior 15?

If we enable h323 call preserve from cucm (8.6 in this case) but have gateways with
IOS 12.x and not 15 - would it make any difference? If it does not works, it makes
no difference whether the call preserve is enabled in CUCM or not?? Or will it be
still of any use?

Thanks

Sent from my iPhone


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_____________________
This e-mail has been scanned for viruses by MessageLabs.

_____________________
This email and all attachments are confidential. For further important information
about emails sent to or from GHD or if you have received this email in error,
please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.

From rratliff at cisco.com Wed Jan 30 17:06:44 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 30 Jan 2013 17:06:44 -0500
Subject: [cisco-voip] Call forard release to another phone
In-Reply-To:
<493392CD07C6D045837BAE6AD397BE9C880E8F00@Mailbox2.boco.co.boulder.co.us>
References:
<493392CD07C6D045837BAE6AD397BE9C880E8F00@Mailbox2.boco.co.boulder.co.us>
Message-ID: <27C50C45-8B20-4178-833E-E4C7FFFB9870@cisco.com>

> Am I confusing you all by now?

No, but you are trying hard to :)

The behavior you are observing is correct, though the terms you are using are not.
A call leg (in CUCM-land) requires a call to be established. When a call is
forwarded no part of it is left on the forwarding phone. What does remain is a
property of that call called the original-called-number and original-redirecting-
number. CUCM will not update either of these through multiple forwards and the
voicemail system will use that original number to send the call to a mailbox.

The reasoning behind our behavior is Steve goes to lunch and CFA his phone to Mary.
Joe calls Steve, Mary isn't at her desk and so he is dropped into Steve's
voicemail, which makes sense since as far as he know he called Steve, not Mary.

-Ryan

On Jan 30, 2013, at 3:36 PM, "Leetun, Rob" <rleetun at bouldercounty.org> wrote:

Good afternoon,
I am wondering why Callmanager 8.6 will not allow the call leg to be released to
the call forwaded device. When a call is forwarded to another device in the
network and the person does not pick up the call. The call does not go that
person?s voicemail box. It appears the call leg from the original device is
maintained until the person picks up the call on the device. Am I confusing you
all by now?

Rob

Robert E. Leetun, CCNA, CCNA+Voice


Network Engineer
Boulder County Information Services
2025 14th Street
Boulder, Colorado 80302
303-441-3866 (W)
303-441-3983 (F)

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/56a24a0b/attachment.html>

From rratliff at cisco.com Wed Jan 30 17:09:05 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Wed, 30 Jan 2013 17:09:05 -0500
Subject: [cisco-voip] phone getting un register with temp fail message
In-Reply-To: <11191743FBFAB44995641CE6E5FA2E7F10E64518@NPEXCHMB102.tdc.internal>
References: <CAPXwYGQPQS=54OsKCOUPev25NixABVUusNoRRo-c0fs5_+KDbQ@mail.gmail.com>
<11191743FBFAB44995641CE6E5FA2E7F10E64518@NPEXCHMB102.tdc.internal>
Message-ID: <94E1EA5E-8B55-4D90-A91D-F124C8788FDE@cisco.com>

> Last=TCP-timeout

This means the phone dropped because it timed out the TCP session to CUCM. A phone
load upgrade could certainly help if it's the phone's behavior that is causing the
TCP timeout but it certainly isn't guaranteed.

You'll need to look at the traffic from the phone to CUCM, check for proper QOS,
look for dropped packets, etc.

-Ryan

On Jan 30, 2013, at 1:04 PM, "Linsemier, Matthew" <MLinsemier at thedoctors.com>


wrote:

We saw this a lot on our old CUCM 6.1(x) server.

The issue was resolved when they moved to new firmware 9.3.1SR1 during our
transition to CUCM 8.6(4).

I would load the new device pack or maybe specific firmware for that model of phone
and test one to see if it resolves the issue.
Matt

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Shaihan Jaffrey
Sent: Wednesday, January 30, 2013 11:00 AM
To: Cisco VOIP
Subject: [cisco-voip] phone getting un register with temp fail message

Dear Team,
Phones at one WAN site are getting unregistered intermittently with temp fail
message on the ip phone.
Below are some lines from CCM traces.

01/30/2013 16:29:43.915 CCM|StationInit: (0242133) alarmSeverity=2 text="10:


Name=SEP002414B3FF43 Load= SCCP11.8-4-1SR1S Last=TCP-timeout" parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988910><IP::10.1.34.2
40><DEV::SEP002414B3FF43>
01/30/2013 16:29:43.915 CCM|StationInit: (0242132) alarmSeverity=2 text="10:
Name=SEP001FCAE85A2E Load= SCCP11.8-4-1SR1S Last=TCP-timeout" parm1=0(0)
parm2=0(0).|
<CLID::StandAloneCluster><NID::10.128.0.11><CT::1,100,126,1.24988911><IP::10.1.49.2
39><DEV::SEP001FCAE85A2E>

Regards.

Confidentiality Notice: This message and any attachments hereto may contain
confidential and privileged communications or information and/or attorney client
communications or work-product protected by law. The information contained herein
is transmitted for the sole use of the intended recipient(s). If you are not the
intended recipient or designated agent of the recipient of such information, you
are hereby notified that any use, dissemination, copying or retention of this e-
mail or the information contained herein is strictly prohibited and may subject you
to penalties under federal and/or state law. If you received this e-mail in error,
please notify the sender immediately and permanently delete this e-mail.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/4851b450/attachment.html>

From MLoraditch at heliontechnologies.com Wed Jan 30 17:25:22 2013


From: MLoraditch at heliontechnologies.com (Matthew Loraditch)
Date: Wed, 30 Jan 2013 22:25:22 +0000
Subject: [cisco-voip] Speechview
Message-ID: <C75AF2AD9308C246AFBDDB994E3E29831C1C399B@PHANES.helion.local>

Anyone else using it? Thoughts?


We are testing it with a few users as a replacement for simulscribe and having
mixed feelings.
I have gotten this error a few times:
The transcription request timed out

Looked it up and it doesn't appear that there are any solutions.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/6da48f7f/attachment.html>

From chrward at cisco.com Wed Jan 30 20:32:27 2013


From: chrward at cisco.com (Chris Ward (chrward))
Date: Thu, 31 Jan 2013 01:32:27 +0000
Subject: [cisco-voip] Speechview
In-Reply-To: <C75AF2AD9308C246AFBDDB994E3E29831C1C399B@PHANES.helion.local>
References: <C75AF2AD9308C246AFBDDB994E3E29831C1C399B@PHANES.helion.local>
Message-ID: <C3D1FCA271936B48839E081F898E17AA207F2C@xmb-rcd-x13.cisco.com>

Hi Matthew,

You can define error messages in the CUC Admin page to help you understand what the
actual issue is that you are facing as I think 2 or 3 error codes return that
generic message. You may need to open a TAC case to get to the bottom of it as TAC
would have the ability to engage Nuance, the transcription service, to find root
cause.

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at


puck.nether.net] On Behalf Of Matthew Loraditch
Sent: Wednesday, January 30, 2013 5:25 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Speechview

Anyone else using it? Thoughts?


We are testing it with a few users as a replacement for simulscribe and having
mixed feelings.
I have gotten this error a few times:
The transcription request timed out

Looked it up and it doesn't appear that there are any solutions.

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:support at
heliontechnologies.com?subject=Technical%20Support%20Request>

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130131/daa63d19/attachment.html>

From Rynard.Coetzee at bytes.co.za Thu Jan 31 00:35:07 2013


From: Rynard.Coetzee at bytes.co.za (Rynard Coetzee)
Date: Thu, 31 Jan 2013 05:35:07 +0000
Subject: [cisco-voip] Call drops after taking off hold
In-Reply-To: <0DF8D130-8282-40D9-A314-C221453BA951@yahoo.com>
References: <97D19F256B859A48A6A93E8A9210E52A84327E27@BYTESEXCH2K10N1.bytes.local>
<3EC1F92E-6D95-4358-884B-47271673B175@cisco.com>
<BAY149-ds1839E2CA688BACE25ADA9F87190@phx.gbl>
<97D19F256B859A48A6A93E8A9210E52A84331B48@BYTESEXCH2K10N1.bytes.local>
<33DCB925-465F-4072-905E-CFCD22391FA3@yahoo.com>
<97D19F256B859A48A6A93E8A9210E52A84331DCF@BYTESEXCH2K10N1.bytes.local>
<ADA96573E777E542A8C51E329C001EE70604CE5D@SAR-DC-EXC01.LA.LOGICALIS.COM>
<0DF8D130-8282-40D9-A314-C221453BA951@yahoo.com>
Message-ID: <97D19F256B859A48A6A93E8A9210E52A84333312@BYTESEXCH2K10N1.bytes.local>

Hi Carlo
No ,I am not running multicast MoH

From: Carlo [mailto:carlo_calabrese2006 at yahoo.com]


Sent: 30 January 2013 04:27 PM
To: ROZA, Ariel
Cc: Rynard Coetzee; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Call drops after taking off hold

Are you running Multicast for your MOH? try turning it off and see if it clears
the problem. Please let me know. I have a problem with Multicast doing almost the
same thing. I am running SIP

Sent from my iPad

On Jan 29, 2013, at 8:22 AM, "ROZA, Ariel" <Ariel.ROZA at


LA.LOGICALIS.COM<mailto:Ariel.ROZA at LA.LOGICALIS.COM>> wrote:
Rynard,

About the explanation? It seems that the H323 Gateway does not like the IP Address
change when you put the call on hold. The audio stream source ip address changes
from your phone to the assigned MOH server, and when you release the call, it goes
back from the MOH server to your phone.
The use of MTP masks this behavior to the gateway.

I would check that the Gateways IOS is updated.


Hth,

Ariel.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Rynard Coetzee
Sent: lunes, 28 de enero de 2013 11:29 a.m.
To: Carlo
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Not in my case ,I can actually see the MTP resources are active and in use on my GW
,using show sccp connections .

From: Carlo [mailto:carlo_calabrese2006 at yahoo.com]<mailto:


[mailto:carlo_calabrese2006 at yahoo.com]>
Sent: 28 January 2013 04:23 PM
To: Rynard Coetzee
Cc: Ahmed Elnagar; Wes Sisk; cisco-voip at puck.nether.net<mailto:cisco-voip at
puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

We ran into the same problem when we upgraded to 8.6 and we use SIP. TAC said CUCM
will ask for the resource but never uses it.

Sent from my iPad

On Jan 28, 2013, at 12:16 AM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:
Hi
MoH did work ,call only fails when trying to resume from being placed on hold.
Basically the problem seems to be resolved by forcing the GW to use MTP ,this is
what I don`t understand ?

From: Ahmed Elnagar [mailto:ahmed_elnagar at hotmail.com]<mailto:


[mailto:ahmed_elnagar at hotmail.com]>
Sent: 27 January 2013 04:20 PM
To: 'Wes Sisk'; Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] Call drops after taking off hold

Check you media termination point configuration also.

Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at


puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:
[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Wes Sisk
Sent: Friday, January 25, 2013 6:33 PM
To: Rynard Coetzee
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Call drops after taking off hold

Typically this happens because the hold actually failed. did the PSTN user actually
hear music on hold? look for codec mismatches or misconfiguration in delivering MoH
to the PSTN caller.

/wes

On Jan 21, 2013, at 11:55 PM, Rynard Coetzee <Rynard.Coetzee at


bytes.co.za<mailto:Rynard.Coetzee at bytes.co.za>> wrote:

Hi
I have the following scenario at a client site ,call comes from PSTN via H323 GW ,I
can answer the call and place the caller on hold ,when I try and resume the call
,the Telco drops the call with a ? Bearer capability not implemented? error. Any
ideas what the problem could be ?
Regards
Rynard
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130131/b5470cc8/attachment.html>

From Robin.Clayton at rrfa.org.uk Thu Jan 31 04:20:53 2013


From: Robin.Clayton at rrfa.org.uk (Robin Clayton)
Date: Thu, 31 Jan 2013 09:20:53 +0000
Subject: [cisco-voip] Testing Disaster Recovery of 7.x to a VM.
Message-ID: <883574BD6A83B04EAA11A5B54F4DFFE3BD2A62@SV-C-EXCHMB-
01.richardrose.internal>

CUCM 7.1.5.33900-10
ESXi 5

Dear All.

In the interest of forward planning and Disaster Recovery, I have been attempting
to restore our weekly backup from CUCM to a Virtual vMware ESXi host.

The host is built and on an identical version

It's networked away from the main network to prevent any ISSUES...

I can connect fine to the restore point , select the file, select to restore CCM,
select the publisher node.

Then hit restore.

It immediately baulks with

"Error: At least one of the servers which was requested to be restored is not
connected CCM-NODE1. This may be due to master or local Agent being down. ...."

I think the ipsec serials check out and I have checked the Agents are running..

Has anyone else ever tried this, I know production only supports 8.x on vMware but
thought it may at least be possible to do DR-Restore for testing...

Any ideas?

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY

Tel: 01228 822075


www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation<http://www.rrfa.org.uk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130131/f48bd95a/attachment.html>

From Zoltan.Kelemen at emerson.com Thu Jan 31 05:06:35 2013


From: Zoltan.Kelemen at emerson.com (Zoltan.Kelemen at emerson.com)
Date: Thu, 31 Jan 2013 10:06:35 +0000
Subject: [cisco-voip] HuntListExhausted
In-Reply-To: <E229138ACF876F73639EBAAE@tyrion.rrz.uni-koeln.de>
References: <E229138ACF876F73639EBAAE@tyrion.rrz.uni-koeln.de>
Message-ID: <F8E0CC3253A10C4CB137F12F568DAD061ACBE84EED@GBLONZ-PMSGEM02.emrsn.org>
Hi,

You would be getting HuntListExhausted when either all of your agents are busy or
none respond to the call.
Depending on your distribution algorithm, RNA timeout and Hunt Options on the Line
Group this can happen sooner or later.

As such, after the Hunt List exhausted all of its options, you would get the error,
then it would go into Forward redirect options, so your callers may not notice
anything.

Cheers,

Zoltan Kelemen
Emerson

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at
puck.nether.net] On Behalf Of Sebastian Hagedorn
Sent: Wednesday, January 30, 2013 5:28 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] HuntListExhausted

Hi,

I'm relatively new to VoIP, but have more than 10 years of experience as a Cisco
network admin. We have been running CUCM, CUC and CUP, all version 8.6, since
September 2012. All is seemingly running well, so now I'm trying to understand the
few alerts I'm seeing. Here's one:

Jan 17 11:55:31 ccm3 19: : ccm: 140892: ccm3: Jan 17 2013 10:55:31.173 UTC
: %UC_-3-UNKNOWN_ALARM:HuntListExhausted:
%[HuntListName=DE-CGN-1ST-LEVEL-HELPDESK-HL][AppID=Cisco
CallManager][ClusterID=StandAloneCluster][NodeID=ccm3]:

The configuration for the hunt pilot redirects both Forward Hunt No Answer and
Forward Hunt Busy to the hunt pilot itself. The Forward Maximum Hop Count Required
Field is 12 (default). According to the documentation the hunt should continue for
up to 30 minutes. The are three DNs in the line group attached to the hunt list.

Here's my question: under what set of circumstances is this alert triggered given
the config outlined above? What's the result for the outside caller?

Thanks,
Sebastian
--
.:.Sebastian Hagedorn - Weyertal 121 (Geb?ude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:.
.:.Universit?t zu K?ln / Cologne University - ? +49-221-470-89578.:.

From rratliff at cisco.com Thu Jan 31 11:56:41 2013


From: rratliff at cisco.com (Ryan Ratliff)
Date: Thu, 31 Jan 2013 11:56:41 -0500
Subject: [cisco-voip] Testing Disaster Recovery of 7.x to a VM.
In-Reply-To: <883574BD6A83B04EAA11A5B54F4DFFE3BD2A62@SV-C-EXCHMB-
01.richardrose.internal>
References: <883574BD6A83B04EAA11A5B54F4DFFE3BD2A62@SV-C-EXCHMB-
01.richardrose.internal>
Message-ID: <6BD9F2A1-F9ED-46B8-88D4-21229E02608A@cisco.com>

Yes this should work, but as you said isn't supported.

The error you are getting means the DRS Master or Local services isn't reachable on
CCM-NODE1. If that's your publisher then make sure both of those are running, and
try bouncing them if they are. If that's the sub, then make sure you choose to
restore only the server(s) that are built and configured as VMs.

-Ryan

On Jan 31, 2013, at 4:20 AM, Robin Clayton <Robin.Clayton at rrfa.org.uk> wrote:

CUCM 7.1.5.33900-10
ESXi 5

Dear All.

In the interest of forward planning and Disaster Recovery, I have been attempting
to restore our weekly backup from CUCM to a Virtual vMware ESXi host.

The host is built and on an identical version

It?s networked away from the main network to prevent any ISSUES?

I can connect fine to the restore point , select the file, select to restore CCM,
select the publisher node.

Then hit restore.

It immediately baulks with

?Error: At least one of the servers which was requested to be restored is not
connected CCM-NODE1. This may be due to master or local Agent being down. ?.?

I think the ipsec serials check out and I have checked the Agents are running..

Has anyone else ever tried this, I know production only supports 8.x on vMware but
thought it may at least be possible to do DR-Restore for testing?

Any ideas?

Rob

=========================
Robin Clayton

Senior I.T. Technician


Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY
Tel: 01228 822075
www: www.rrfa.org.uk

-----------------------------------------------------------------------------------
---------------------------

Important Notice:

This e-mail and any attachment are confidentialand may be privileged


or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.

The Richard Rose Federation _______________________________________________


cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------


An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130131/348a1a05/attachment.html>

You might also like