Professional Documents
Culture Documents
I didnt test to see if the 9.1 from CCO is bootable. In the past they
havent been.
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>
Well that's different than what I was seeing, mine would crash during the install,
instead of saying you can't do it.
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
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?
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.
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.
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
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?
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.
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
I did just that. after I tried with the pre-release, I used my NFR iso.
Same result.
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>
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.
-Ryan
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
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?
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.
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
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>
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.
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>
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
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.
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.
-Ryan
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
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?
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.
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
Well that's good, I can just put a PUT order in edelivery and get it. Let's see if
it works.
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>
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
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.
-Ryan
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
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?
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.
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
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
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130103/ec0b59de/attachment.html>
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.
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 ?)
Rob
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.
> 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
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
---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.
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
http://www.eset.com
http://www.eset.com
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
*---AS*
> 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>
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)
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.
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
> 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>
Terry
> 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>
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
> 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>
We mostly have 7941 and 7945 ip phones. Are these both models have build-in
bridge ?
Rob
> 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>
Rob
> 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>
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.
Terry
We mostly have 7941 and 7945 ip phones. Are these both models have build-in
bridge ?
Rob
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.
> 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.
Just curious how other folks handle deployment and subsequent device
management of wireless phone authentication on your networks?
Does anyone use the BD utility and have an open provisioning network
setup? How is that working out?
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
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.
Terry
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,
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.
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
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
Terry
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)
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.
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
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
---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.
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
http://www.eset.com
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>
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
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
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.
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,
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.
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
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:
Terry
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)
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.
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
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
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
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) __________
http://www.eset.com<http://www.eset.com/>
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>
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>
Can you just set it on the line and pass it through to the sip trunk?
Scott
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>
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>
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
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
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>
SIP SRST
sip
registrar server
Mode SRST
max-dn 100
max-pool 1
voice translation-rule 30
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
max-ephones 58
max-dn 10 octo-line
moh flash0:/MOH-MOTAB.wav
ccm-manager music-on-hold
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.
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
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.
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 ?)
Rob
CCM 7.x
Rob
=========================
Robin Clayton
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
Sorted....
Rob
=========================
Robin Clayton
CCM 7.x
=========================
Robin Clayton
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
http://redtape.nbcnews.com/_news/2013/01/04/16328998-popular-office-phones-
vulnerable-to-eavesdropping-hack-researchers-say?lite
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.
> 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>
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
> 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>
Also, this does NOT affect 7940s and 7960s as they don't run linux which is basis
of the exploit.
+Chris
Unity Connection TME
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.
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
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
Guys...
CCM 7.1.5.33900-10
I have been bashing my head on this one all afternoon
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).
Cheers
Rob
=========================
Robin Clayton
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
Sorry
Rob
=========================
Robin Clayton
Guys...
CCM 7.1.5.33900-10
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).
Cheers
Rob
=========================
Robin Clayton
Senior I.T. Technician
Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
Cumbria
CA1 1LY
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
-nick
> 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>
Uhhhhh....
I see a problem...
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
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?
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]
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.
On Fri, Jan 4, 2013 at 10:02 AM, Scott Voll <svoll.voip 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
> 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>
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
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
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
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
Hy
mabe your hardware is very very new than u can hit this
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
--
Florian Kroessbacher
gmail: florian.kroessbacher at gmail.com
> 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>
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
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>
Hi, Chris,
Tom
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
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
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.
voice. 410.252.8830
fax. 410.252.9284
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
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.
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.
-Ryan
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
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?
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.
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
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
> 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>
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.
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>
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>
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
Well that's good, I can just put a PUT order in edelivery and get it. Let's see if
it works.
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>
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
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.
-Ryan
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
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?
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.
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.
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>
Hi Scott,
You can install the app with the below command string:
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>
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.
> ** **
>
> 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>
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>
LinkedIn
------------
------------------------------------------
Ray,
Find out why I use LinkedIn. Stay in touch and build your professional network.
- Thilan
(c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
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.
Cheers,
Zoltan Kelemen
Emerson
Can you just set it on the line and pass it through to the sip trunk?
Scott
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
Hi,
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?
Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/7d294305/attachment.html>
i have done most of my upgrades this way and used all licenses on the final
version.?
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>
Hi,
thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/36e47cbe/attachment.html>
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.
i have done most of my upgrades this way and used all licenses on the final
version.
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?
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
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
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
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
Well that?s good, I can just put a PUT order in edelivery and get it. Let?s see if
it works.
voice. 410.252.8830
fax. 410.252.9284
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
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.
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.
-Ryan
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?
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.
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
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
> 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>
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?
Thanks,
Erick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130107/44038221/attachment.html>
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.
Thanks,
Goose
http://atc.go0se.com
==================================
Help those less fortunate than you
http://www.hopegivers.org
==================================
-----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.
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.
Does anyone have a example config? I'm thinking its just like a sip router config
correct?
Thanks
Mike
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
-----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.
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
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
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.
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>
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
-----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.
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
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:
And to delete:
By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.
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
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.
voice. 410.252.8830
fax. 410.252.9284
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
-----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.
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
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
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
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:
And to delete:
By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.
> 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
I concur I hit these multiple times and TAC root was needed to clean things up. Not
pleasant, nor part of my plans.
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>
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
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:
And to delete:
By using wildcard * you dont have to delete files one by one, With no confirm
option you dont have to confirm everytime.
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?
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
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.....
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
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
> 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>
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>
>>
>
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.
SeverityMatch : Alert
NodeID : NCCHQ-CCM-SUB3
ClusterID :
NodeID : NCCWG-CCM-SUB4
SeverityMatch : Alert
ClusterID :
NodeID : NCCHQ-CCM-TFTP
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/78beb086/attachment.html>
> 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>
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>
HI All,
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]
> 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>
Hi Costas,
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
HI All,
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
Thanks All.
Hi Costas,
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
HI All,
Regards
Cos
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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.....
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.
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.
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?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130108/83f3573a/attachment.html>
Hi Jamie,
Do you have a target date for CUEAC support with CUCM 9.1?
Thanks,
Eric
Hi Costas,
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
HI All,
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
> 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
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.
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?
Thanks
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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>
Hi,
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
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
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..
Cryptic but looks resolved by CSCso80710. Something about constraints on the number
of entries enforced both in PAB java code and the database.
I had to update the bug so it will take 24 hours to appear in Bug Toolkit.
/wes
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?
Thanks,
Erick
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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.
> 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>
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>
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?
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.
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
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.
> 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
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
> 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>
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.
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
All of my 7936 conference phones, when you press the corporate directory,
come up with error condition.
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>
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
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.
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
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.
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>
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
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.
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.
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
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>
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.
On Jan 10, 2013, at 1:28 PM, "Heim, Dennis" <Dennis.Heim at wwt.com> wrote:
Received:
SIP/2.0 200 OK
Content-Type: application/sdp
Content-Length: 367
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
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>
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
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]
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
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.
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.
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
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
If sip gives the cube a usable although empty name for the incoming call
then your phones won't bother to lookup the number.
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
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
Is it possible with cube to take the PAI and copy it into the from field?
Call setup
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.
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.
The problem still is that I dial a number and it does not put in the name.
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>
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
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
>
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>
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>
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.
> 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
Regards,
Security Advisories & Responses for All Voice and Unified Communications
Title
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.
____________________________________________________________________________
____
Old user had ext 1212 (and this is a DID, so people can call directly from
the outside).
New user has ext 1702.
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.
Dave
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>
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.
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.
Dave
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Hi All,
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.
> 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>
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
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.
<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
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>
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.
On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk <wsisk at cisco.com> wrote:
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
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 =)....
Very Interesting,
-Pete
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. =)
*"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.
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>
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.
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
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
"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. =)
"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.
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 =)....
Very Interesting,
-Pete
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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>
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
admin:
Subscriber:
admin:show cuc cluster status
admin:
Bill
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.
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
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. =)
"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.
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 =)....
Very Interesting,
-Pete
_______________________________________________
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>
PUB:
admin:utils ntp status
ntpd (pid 18803) is running...
SUB:
admin:utils ntp status
ntpd (pid 18919) is running...
Bill
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
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
admin:
Subscriber:
admin:show cuc cluster status
admin:
Bill
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
PUB:
admin:utils ntp status
============================================================================
==
SUB:
============================================================================
==
Bill
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
Hey Guys,
Publisher:
admin:
Subscriber:
-----------------------------------------------------------------------
admin:
Bill
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.
> 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>
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:
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.
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>
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...
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>
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.
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>
> 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
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.
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.
Dave
_______________________________________________
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
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.
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>
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...
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>
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.
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>
Hello,
I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.
After i add the CUCM instance, im trying to use the Migration Utility, but
im receiving this error:
Any suggestion?
Regards,
so would you suggest a clean reboot before the upgrade of CUC to at least
9.1 ?
> 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>
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
Hello,
I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.
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,
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.
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
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>
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.
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>
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...
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>
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.
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
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>
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.
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>
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...
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>
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.
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.
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.
[Inline image 1]
Cheers
Leslie
Follow us:
_______________________________________________
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>
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>
JonM
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>
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?
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.
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>
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
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
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
License Info:
License UDI:
-------------------------------------------------
Device# PID SN
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
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:
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
License Info:
License UDI:
-------------------------------------------------
Device# PID SN
On Jan 14, 2013, at 4:11 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
On Jan 14, 2013, at 4:18 PM, Dane Newman <dane.newman at gmail.com> wrote:
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>
On Jan 14, 2013, at 6:06 PM, Dane Newman <dane.newman at gmail.com> wrote:
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>
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:
Well have you tried debugging the codec to see if it has any errors!
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:
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:
*Hello Kenneth*
**
*I have restarted both CUCM servers so this should have restarted the
services when the utils system restart happened*
**
*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.*
On Mon, Jan 14, 2013 at 6:20 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
I have a 2960s-48fps-l and when I inserted the flex stack module I get:
TIA
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/4e227560/attachment.html>
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>
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
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
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.
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?
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
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.
You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"
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?
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
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.
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:
Looks like it finds the file, wants a signed one, appears to convert
it, then fails to find it.
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130114/6407435b/attachment.html>
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?
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
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.
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
You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"
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?
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
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.
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
You don't need DNs on a device anymore for them to be active. They just
need to be marked as "active"
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?
-Nate
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.
Goto
call routing
Directory number
Add new
And you can add a range in and create the call forwards.
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
You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"
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?
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
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>
How long had the server been up before the you started the first upgrade?
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.
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
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.
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
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.
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.
Cleaning out log files and CDRs might also be a good idea.
Follow us:
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]
How long had the server been up before the you started the first upgrade?
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.
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>
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?
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>
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.
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>
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
What is the IOS being run? Is it IP Base? I don?t think anything lower will run the
stacking module.
Follow us:
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>
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
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.
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?
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
>>
>>
>>
>
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.
Follow us:
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>
How long had the server been up before the you started the first upgrade?
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.
voice. 410.252.8830
fax. 410.252.9284
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?
voice. 410.252.8830
fax. 410.252.9284
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.
voice. 410.252.8830
fax. 410.252.9284
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
Here is the trace from the MTP registering, showing that it supports
pass-through:
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:
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.
Goto
call routing
Directory number
Add new
And you can add a range in and create the call forwards.
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
You don't need DNs on a device anymore for them to be active. They just need to be
marked as "active"
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?
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
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.
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
On Tue, Jan 15, 2013 at 11:31 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
*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>
-Ryan
On Jan 15, 2013, at 12:35 PM, Dane Newman <dane.newman at gmail.com> wrote:
On the call when I hold the call the following debug pops out....
After I try to unhold the call the following debug comes out....
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
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.
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?
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
>>
>>
>>
>
Ryan
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>
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
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:
On the call when I hold the call the following debug pops out....
After I try to unhold the call the following debug comes out....
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
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.
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?
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
>>
>>
>>
>
Thanks Ryan
I see I am always getting a 200 ok message after my invites from the debug
Received:
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 240
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
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
Timestamp: 1358281168
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 289
v=0
s=SIP Call
t=0 0
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
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 239
v=0
t=0 0
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=inactive
Sent:
SIP/2.0 200 OK
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
a=inactive
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Length: 0
Received:
Max-Forwards: 70
Allow-Events: presence
Content-Length: 0
Received:
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281168
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
o=root 1685873050 1685873053 IN IP4 64.154.41.150
t=0 0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
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
Received:
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 209
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=X-cisco-media:nomedia
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 251
v=0
s=SIP Call
t=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*
**
Received:
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281175
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
t=0 0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
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
Received:
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 243
v=0
o=CiscoSystemsCCM-SIP 7322 5 IN IP4 10.1.80.10
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 265
v=0
t=0 0
a=inactive
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Cisco3825#
Cisco3825#
Cisco3825#
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281175
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Contact: <sip:17705439047 at 64.154.41.150>
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
t=0 0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
c=IN IP4 10.1.200.1
t=0 0
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
Received:
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 243
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 265
v=0
s=SIP Call
t=0 0
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>
Also can you show me a copy of your voice service voip config?
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
Received:
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 240
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
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
Max-Forwards: 70
Timestamp: 1358281168
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 289
v=0
s=SIP Call
t=0 0
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
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 239
v=0
t=0 0
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=inactive
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
a=inactive
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Length: 0
Received:
Max-Forwards: 70
Allow-Events: presence
Content-Length: 0
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281168
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
t=0 0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
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
Received:
Max-Forwards: 70
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 209
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=X-cisco-media:nomedia
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
Sent:
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 251
v=0
s=SIP Call
t=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*
**
Received:
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281175
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
t=0 0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
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
Received:
Content-Type: application/sdp
Content-Length: 243
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
Max-Forwards: 70
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 265
v=0
s=SIP Call
t=0 0
a=inactive
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Cisco3825#
Cisco3825#
Cisco3825#
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
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
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
Max-Forwards: 70
Timestamp: 1358281175
Expires: 180
Allow-Events: telephone-event
Session-Expires: 1800;refresher=uas
Content-Length: 0
Sent:
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Received:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
Received:
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Require: timer
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 333
v=0
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
Sent:
SIP/2.0 200 OK
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
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
s=SIP Call
t=0 0
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
Received:
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 243
v=0
s=SIP Call
b=TIAS:64000
b=AS:64
t=0 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Sent:
Max-Forwards: 70
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
t=0 0
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>
[OK]
Cisco3825#sh run
Building configuration...
On Tue, Jan 15, 2013 at 3:31 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
Bind your media and source to your outbound interface on your voice service
voip.
On Jan 15, 2013, at 3:39 PM, Dane Newman <dane.newman at gmail.com> wrote:
[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:
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.
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>
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>
Nick
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>
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????
thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/d5df7b87/attachment.html>
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,
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>
* 1. **enable*
* 2. **configure* *terminal*
*Thanks
*
*
*
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/f42a1135/attachment.html>
1. enable
2. configure terminal
Thanks
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,
itevomcid
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/ecd63aa1/attachment.html>
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
So before I route PSTN calls to the AA I want to make sure I'm configuring
it right..
Any suggestions??????
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>
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?
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>
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>
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.
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>
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.
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>
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.
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>
MGCP, 2921
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.
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
Sounds like a DTMF...check your profile and make sure your sending the
right audio codec to the telco.
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.
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
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>
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>
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>
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>
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>
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)*
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/c96216b9/attachment.html>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130116/a608a442/attachment.html>
Sounds like a DTMF...check your profile and make sure your sending the right
audio codec to the telco.
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.
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
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
+Chris
JonM
---
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)
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
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>
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.
-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?
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
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.
-Ryan
Sounds like a DTMF...check your profile and make sure your sending the right audio
codec to the telco.
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
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:
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
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?
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>
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?
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.
-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?
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
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 ?
> 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>
Ryan
> 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>
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>
> 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>
> 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>
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:
-Ryan
On Jan 16, 2013, at 1:02 PM, abbas Wali <abbaseo at gmail.com> wrote:
how/where we can disable the HTTPS?
-Ryan
On Jan 16, 2013, at 11:34 AM, abbas Wali <abbaseo at gmail.com> wrote:
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..
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>
-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>
-nick
On Wed, Jan 16, 2013 at 11:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca>
wrote:
---
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)
________________________________
+Chris
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
+Chris
Unity Connection TME
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.
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
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
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.
---
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.
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:
---
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
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>
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>
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.
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:
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>
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
> 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>
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!!!
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/1c203349/attachment.html>
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!!!
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130117/f3fcb927/attachment.html>
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>
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#
Need to add some rules in the proxy for the phone subnet!!! I believe.
> 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>
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>
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:
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 **.
incoming called-number .
destination-pattern #74..$
codec g711ulaw
no vad
(config-dial-peer)#destination-pattern **47..
--
Mike Norton
I.T. Specialist
Helpdesk: 780-831-3080
Direct: 780-831-3076
>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
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.
Hi All,
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?
.........People First..........
Best Regards,
Vincent Dao
On Unity Connection 7.
Cheers
Rob
=========================
Robin Clayton
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
guys,
thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130118/661ccb17/attachment.html>
> 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>
Rob
=========================
Robin Clayton
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
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.
Thanks
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>
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.
Matthew Ballard
Network Manager
Otis College of Art and Design
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.
Thanks
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.
On Jan 18, 2013, at 10:48 AM, "Kalyan Iyer (AM)" <kalyan.iyer at dimensiondata.com>
wrote:
Correct, SCCP doesn't support standards based T.38. The VG224 port would need to
be changed from SCCP.
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.
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
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.
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>
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.
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.
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
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.
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
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,
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.
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.
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
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.
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
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.
--
Dave Wolgast
Livonia, NY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/36a31a72/attachment.html>
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.
Follow us:
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.
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>
Anyone run into a problem with IP Phone agent after upgrading to UCCX 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).
--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130121/2e0335c3/attachment.html>
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)
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
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>
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.
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>
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
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
Changing the smtp on 8.6 will make your license invalid so you will need to talk to
tac after changing.
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>
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>
If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.
Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)
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>
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>
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>
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>
*---AS*
On Tue, Jan 22, 2013 at 12:59 PM, Rynard Coetzee <Rynard.Coetzee at bytes.co.za
> wrote:
---AS
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>
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
If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.
Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)
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>
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.
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'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>
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.
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>
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
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
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
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
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.
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>
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
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
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
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
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
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
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>
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 ?
---AS
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>
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).
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.
Kind Regards,
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130123/4578d272/attachment.html>
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>
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.
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>
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?
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
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.
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
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
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>
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
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.
> 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
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.
voice. 410.252.8830
fax. 410.252.9284
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
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
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
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
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.
voice. 410.252.8830
fax. 410.252.9284
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
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:
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
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
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
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>
-Ryan
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
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.
voice. 410.252.8830
fax. 410.252.9284
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
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:
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
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
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
> 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>
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
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
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>
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
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
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
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>
Thanks Chris I presented this to the customer and let them make the call.
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
If you are never going to have another CXN cluster and won't need Unity
Networking then change the SMTP domain to match.
Else it's working as designed by Cisco and talk to your Cisco Account
Manager about a Product Enhancement Request (PERS) J
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
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
Thanks Chris I presented this to the customer and let them make the call.
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
If you are never going to have another CXN cluster and won't need Unity Networking
then change the SMTP domain to match.
Else it's working as designed by Cisco and talk to your Cisco Account Manager about
a Product Enhancement Request (PERS) :)
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>
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
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
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
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
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.
DB Version: ccm8_6_2_22900_9
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:
admin:
Thanks,
Ahmed Elnagar
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 :("
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>
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>
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.
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.
+Chris
Unity Connection TME
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
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
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
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
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
Hello,
I have a 8.6 CUCM running with 1700 DLUs and did a upgrade to 9.0.
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.
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>
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>
Hello Kalyan;
Regards,
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 :("
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
I am having the below issue with one subscriber "my setup is one publisher
and two subscribers"
Last Sync Result: SYNC COMPLETED 541 tables sync'ed out of 541
DB Version: ccm8_6_2_22900_9
admin:
and on the publisher I see this for the 2nd subscriber I am having an issue
with
admin:
I am sure that security password is the same everywhere, what do you think
the problem is?
Thanks,
Ahmed Elnagar
itevomcid
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
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
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
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
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
Try the tools at www.ciscounitytools.com. User data dump comes to mind. There is
also CUDLI which can do wonders too.
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>
Ahmed,
Thanks,
Kalyan
Hello Kalyan;
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
[cid:image001.jpg at 01CDFA57.A78A4D50]
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 :("
________________________________
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
I am having the below issue with one subscriber "my setup is one publisher and two
subscribers"
and on the publisher I see this for the 2nd subscriber I am having an issue with
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>
Just finished the TAC case, there is a new bug ID for the new version now J
Bug Id is CSCua09290
Regards,
Ahmed,
Thanks,
Kalyan
Hello Kalyan;
Regards,
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 :("
Thanks,
Ahmed Elnagar
_____
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
Last Sync Result: SYNC COMPLETED 541 tables sync'ed out of 541
DB Version: ccm8_6_2_22900_9
admin:
and on the publisher I see this for the 2nd subscriber I am having an issue
with
admin:
I am sure that security password is the same everywhere, what do you think
the problem is?
Thanks,
Ahmed Elnagar
itevomcid
mercie beucoup
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!!!
Kris
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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
Hi All,
*---AS*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130125/3485007e/attachment.html>
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>
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>
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>
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>
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:
just to confirm with you, do you really need that CUPs when you are going from 8.5
to 8.6 ???
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
Indeed I do!! However that's the reality of financial cuts in the public sector.
Cheers
Kris
Regards,
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
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
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:
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
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 ?
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
[Description: Description: Description: MS Green]
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
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
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.
Zoltan Kelemen
Emerson
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.
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>
Not in my case ,I can actually see the MTP resources are active and in use on my GW
,using show sccp connections .
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.
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
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
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>
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
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:
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>
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
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.
Thanks,
Zoltan Kelemen
Emerson
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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
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.
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
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?!
Best regards,
Cristina
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:
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
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
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:
Calls from ?SITE B? never generate this facility message so the call works as
expected.
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
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.
Model
Upgrade considerations
6901
???
6911
???
6921
9.2(1)
6941
9.2(1)
6945
9.2(1)
6961
9.2(1)
7905
7906
9.3(1)
7911
9.3(1)
7912
7931
9.3(1)
7937
7940
7941
9.3(1)
7942
9.3(1)
7945
9.3(1)
7960
7961
9.3(1)
7962
9.3(1)
need 8.3(3) to 8.5(2) to get to 8.5(3)+
7965
9.3(1)
7970
9.3(1)
7971
9.3(1)
7975
9.3(1)
8941
9.2(3)
8945
9.2(3)
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.
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.
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
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.
Hth,
Ariel.
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.
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
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
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>
Kris,
Regards,
A.
Indeed I do!! However that's the reality of financial cuts in the public sector.
Cheers
Kris
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
Hi,
i have checked the phone has got its firmware and list of CM's.
not sure what else is blocking these phones from coming up. tried it with
CIPC and they are working fine. only the phy. phones.
-Ryan
On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
Hi,
i have checked the phone has got its firmware and list of CM's.
not sure what else is blocking these phones from coming up. tried it with CIPC and
they are working fine. only the phy. phones.
well, the phone actualy is there in the CM. with the correct mac.
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/fb6baa53/attachment.html>
On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
-Ryan
On Jan 29, 2013, at 12:59 PM, abbas Wali <abbaseo at gmail.com> wrote:
Hi,
i have checked the phone has got its firmware and list of CM's.
not sure what else is blocking these phones from coming up. tried it with
CIPC and they are working fine. only the phy. phones.
_______________________________________________
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>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/4c2811b2/attachment.html>
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.
On Jan 29, 2013, at 1:22 PM, Kenneth Hayes <kennethwhayes at gmail.com> wrote:
On Jan 29, 2013, at 1:18 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
interesting.
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/b90c6108/attachment.html>
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>
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
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
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
Make sure you are using the correct phone button template.
On Jan 29, 2013, at 1:24 PM, abbas Wali <abbaseo at gmail.com> wrote:
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130129/52419f79/attachment.html>
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
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
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:
Calls from ?SITE B? never generate this facility message so the call works as
expected.
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
Dana - thanks for your reply, are you able to provide a brief config or any
pointer?
Thanks
> 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
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>
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.
> 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>
Hi All,
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
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
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>
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.
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>
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.
Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-
voip/attachments/20130130/ea2b12d5/attachment.html>
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
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.
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>
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
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>
-----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
_____________________
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.
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
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
> 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
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
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.
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
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>
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
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>
Hi Carlo
No ,I am not running multicast MoH
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
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.
Ariel.
Not in my case ,I can actually see the MTP resources are active and in use on my GW
,using show sccp connections .
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.
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
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
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>
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.
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.
"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
-----------------------------------------------------------------------------------
---------------------------
Important Notice:
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.:.
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.
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.
?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
-----------------------------------------------------------------------------------
---------------------------
Important Notice: