Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Anthony Holloway
I hope you saw that I wrote "Pseudo Config" and don't just try to copy and
paste that.  I'm also not very convinced that this is the core of your
issue, but you're more than welcome to give it a try.

You said the first OPTIONS does respond, so I'm guessing it's not going to
be a binding error.  In fact, if it was a binding error, OPTIONS would
still respond, it would just have wrong IP info in the headers.

Anyway, good luck with that test.

On Tue, Oct 9, 2018 at 3:54 PM Maciej Bylica  wrote:

> Thanks, i am about to modify the config to check.
>
> Many thanks
>
>
> wt., 9 paź 2018 o 20:58 Anthony Holloway 
> napisał(a):
>
>> OPTIONS does not have to match a dial peer to work.  However, if you are
>> going to match a dial peer at all, it would likely be for the express
>> purpose of replying from the correct interface, if you have more than one
>> potential interfaces, and you for some reason cannot bind globally.  Thus
>> using the correct bind statement on a dial-peer for OPTIONS reply, would be
>> necessary.  In which case, you would need to match an incoming call leg
>> dial peer by the SIP Via header alone, and not, say for example, incoming
>> called number.
>>
>> Example Pseudo Configuration:
>>
>> voice class sip uri 100
>>  host ipv4:10.1.1.1
>> !
>> dial-peer voice 100 voip
>>  incoming uri via 100
>>  bind media interface g0/1
>>  bind control interface g0/1
>> !
>>
>> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica 
>> wrote:
>>
>>> Thanks for prompt answer.
>>>
>>> No, i am not using CCP.
>>> As i see OPTIONS ping does not match with any dialpeer
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric
>>> calling number: *stringhere*
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA
>>> URL:sip:10.10.10.10:5060, Host:100.64.4.31
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match
>>> incoming dialpeer for Calling number: : *stringhere*
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:
>>>
>>>  input arg error
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match
>>> found for P-Called-Party-ID
>>>
>>> Oct  9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:
>>>
>>>
>>>  input argument error
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition
>>> tag absent in Require/Supported header
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media
>>> Antitrombone disabled
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the
>>> configured mode as FLOW-THROUGH
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder
>>> high-density disabled
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode
>>> set to FLOW_THROUGH
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer
>>> leg - using RTP Supported Codecs
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 18
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 0
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 8
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 9
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 4
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 2
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 15
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>>> Codecs supported by GW 255
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:
>>> MF: Not a Forked SIP leg..
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp
>>> configure for this leg.
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:
>>> peer_callID=0
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:
>>>
>>>
>>>  MF: *Dial-peer is absent*..
>>>
>>> Oct  9 17:50:04.068:
>>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: 

Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Maciej Bylica
Thanks, i am about to modify the config to check.

Many thanks


wt., 9 paź 2018 o 20:58 Anthony Holloway 
napisał(a):

> OPTIONS does not have to match a dial peer to work.  However, if you are
> going to match a dial peer at all, it would likely be for the express
> purpose of replying from the correct interface, if you have more than one
> potential interfaces, and you for some reason cannot bind globally.  Thus
> using the correct bind statement on a dial-peer for OPTIONS reply, would be
> necessary.  In which case, you would need to match an incoming call leg
> dial peer by the SIP Via header alone, and not, say for example, incoming
> called number.
>
> Example Pseudo Configuration:
>
> voice class sip uri 100
>  host ipv4:10.1.1.1
> !
> dial-peer voice 100 voip
>  incoming uri via 100
>  bind media interface g0/1
>  bind control interface g0/1
> !
>
> On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica  wrote:
>
>> Thanks for prompt answer.
>>
>> No, i am not using CCP.
>> As i see OPTIONS ping does not match with any dialpeer
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric
>> calling number: *stringhere*
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA
>> URL:sip:10.10.10.10:5060, Host:100.64.4.31
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match
>> incoming dialpeer for Calling number: : *stringhere*
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:
>>
>>  input arg error
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match
>> found for P-Called-Party-ID
>>
>> Oct  9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:
>>
>>  input argument error
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition
>> tag absent in Require/Supported header
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media
>> Antitrombone disabled
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the
>> configured mode as FLOW-THROUGH
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder
>> high-density disabled
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode
>> set to FLOW_THROUGH
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer
>> leg - using RTP Supported Codecs
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 18
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 0
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 8
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 9
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 4
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 2
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 15
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
>> Codecs supported by GW 255
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:
>> MF: Not a Forked SIP leg..
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp
>> configure for this leg.
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:
>> peer_callID=0
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:
>>
>>
>>  MF: *Dial-peer is absent*..
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state
>> = 0 & New state = -1
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:
>> MF: Anchor leg config reset done...
>>
>> Oct  9 17:50:04.068:
>> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:
>>
>>
>>  MF:video profile Dial-peer is absent..
>>
>>
>> OPTIONS looks like following:
>>
>> OPTIONS sip:domain.name.here:5060 SIP/2.0
>>
>> From: ;tag=4a6000292f6a
>>
>> To: 
>>
>>
>>
>> I do not have any script in use there, the configuration in pretty basic.
>> What i have found is that second OPTIONS (the one that is left/dropped
>> without 

Re: [cisco-voip] VOIP on AS5400

2018-10-09 Thread Joseph Mays
The box has 4 NP108 cards in it. But I have heard that it is possible to run 
into processor limits on voip calls in a 5400 before the number of DSP’s is 
fully utilized. It is possible I’ve heard incorrectly; I’m just trying to find 
out what is accurate.

From: NateCCIE 
Sent: Tuesday, October 09, 2018 4:16 PM
To: 'Joseph Mays' ; cisco-voip@puck.nether.net 
Subject: RE: [cisco-voip] VOIP on AS5400

To do Voice, you will need DSPs, 1 dsp is 64 g711 calls.  That will be the 
limiting factor over PSTN connectivity.

 

https://www.cisco.com/c/en/us/products/collateral/unified-communications/as5400xm-universal-gateway/product_data_sheet0900aecd80458049.html

 

 

From: cisco-voip  On Behalf Of Joseph Mays
Sent: Tuesday, October 9, 2018 2:04 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] VOIP on AS5400

 

I am recently put in the position of working with some old AS5400s. I put the 
following question to the cisco nas list, but I thought it might be appropriate 
for here, too

 

The only other question is about the number of voip calls the box can support. 
My understanding (possibly wrong) is that there is an upper limit on the number 
of voip calls an AS5400 can sustain, depending on the memory, processor, and 
codec being used. Is this correct, and if so how do I calculate it?

 

The codec being used is G.711, which does virtually no compression, so I would 
imagine the processor usage is very low as compared to other codecs.

 

ArmoryPl-AS5400#show ver

Cisco Internetwork Operating System Software

IOS (tm) 5400 Software (C5400-JS-M), Version 12.3(3i), RELEASE SOFTWARE (fc1)

Copyright (c) 1986-2005 by cisco Systems, Inc.

Compiled Fri 12-Aug-05 22:07 by ssearch

Image text-base: 0x6000895C, data-base: 0x6190

 

ROM: System Bootstrap, Version 12.2(1r)1, RELEASE SOFTWARE (fc1)

BOOTLDR: 5400 Software (C5400-BOOT-M), Version 12.1(1)XD1, EARLY DEPLOYMENT 
RELEASE SOFTWARE (fc2)

 

ArmoryPl-AS5400 uptime is 1 week, 1 day, 3 hours, 17 minutes

System returned to ROM by bus error at PC 0x6158, address 0x59CCDEC at 
11:13:47 EDT Mon Oct 1 2018

System restarted at 11:14:51 EDT Mon Oct 1 2018

System image file is "flash:c5400-js-mz.123-3i.bin"

 

cisco AS5400 (R7K) processor (revision T) with 524288K/131072K bytes of memory.

Processor board ID JAE09054U8M

R7000 CPU at 250Mhz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3 Cache

Last reset from warm-reset

Bridging software.

X.25 software, Version 3.0.0.

SuperLAT software (copyright 1990 by Meridian Technology Corp).

TN3270 Emulation software.

Primary Rate ISDN software, Version 1.1.

Manufacture Cookie Info:

EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x31,

Board Hardware Version 3.34, Item Number 800-5171-02,

Board Revision C0, Serial Number JAE09054U8M,

PLD/ISP Version 2.2,  Manufacture Date 26-Jan-2005.

Processor 0x14, MAC Address 0x012801C6694

Backplane HW Revision 1.0, Flash Type 5V

2 FastEthernet/IEEE 802.3 interface(s)

444 Serial network interface(s)

432 terminal line(s)

64 Channelized T1/PRI port(s)

2 Channelized T3 port(s)

512K bytes of non-volatile configuration memory.

65536K bytes of processor board System flash (Read/Write)

16384K bytes of processor board Boot flash (Read/Write)

 

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


Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

2018-10-09 Thread Lelio Fulgenzi
I wonder if it would help to secure the cable to the table somehow with a 
“service” loop near the phone. This way, moving the device, it’s only got a bit 
of weight of the cable.

---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: JASON BURWELL 
Sent: Tuesday, October 9, 2018 4:10 PM
To: Lelio Fulgenzi ; 'Nimloth' 
Cc: cisco-voip voyp list 
Subject: RE: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Unfortunately not. It’s just a port on the back of the phone. The port is 
slightly recessed in to the housing so that does help some but it’s not really 
effective in keeping the cord secure. I have to wonder if some of these designs 
are ever field tested in a real world environment before they make it in to 
production. Luckily the 7832 has an RJ45 Ethernet port on it so not an issue 
for that phone but the 7832 is not a good fit for a medium sized conference 
room. Not sure why they could not have done USB-C and RJ45 on the 8832……….

Jason



From: Lelio Fulgenzi [mailto:le...@uoguelph.ca]
Sent: Tuesday, October 09, 2018 3:56 PM
To: JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>>; 
'Nimloth' mailto:niml...@nimloth.pl>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: RE: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Well, this is not encouraging to hear. ☹

And there’s likely no spot to put anything with a wire tie either? Usually, 
they have those little plastic hooks, like the ones that would hold an rj11 
cable.



---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of JASON BURWELL
Sent: Tuesday, October 9, 2018 3:49 PM
To: 'Nimloth' mailto:niml...@nimloth.pl>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Yes, also we hit some bugs with an early FW release. Once it downgraded from 
the factory load, it would brick the phone. Must be a major issue because I had 
to wait almost 2 months for RMA fulfillment. Now that we are running current 
firmware with that bugfix, we seem to be past that issue but now seeing this 
problem.


From: Nimloth [mailto:niml...@nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?

CAUTION: This email originated outside of Founders Federal Credit Union. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

To be honest I won't deploy 8832 in my org as we still struggling to get one up 
and running since few months. Few TAC/RMA already in progress.
W dniu 9 paź 2018, o 20:35, użytkownik JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> napisał:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged 
from the phone when people grab it to slide or move the phone towards them? 
Starting to see some issues with this and I only have a few deployed so far. 
Hoping someone has figured out a workaround or clip to help retain the cord.


This was never a problem before because all the other Cisco Conf phones are not 
only held in by RJ45 clip but also cord clips made in to the base. The 8832 has 
neither, just USB-C cord that plugs in to the back. Thanks! Jason





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


Re: [cisco-voip] VOIP on AS5400

2018-10-09 Thread NateCCIE
To do Voice, you will need DSPs, 1 dsp is 64 g711 calls.  That will be the
limiting factor over PSTN connectivity.

 

https://www.cisco.com/c/en/us/products/collateral/unified-communications/as5
400xm-universal-gateway/product_data_sheet0900aecd80458049.html

 

 

From: cisco-voip  On Behalf Of Joseph
Mays
Sent: Tuesday, October 9, 2018 2:04 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] VOIP on AS5400

 

I am recently put in the position of working with some old AS5400s. I put
the following question to the cisco nas list, but I thought it might be
appropriate for here, too

 

The only other question is about the number of voip calls the box can
support. My understanding (possibly wrong) is that there is an upper limit
on the number of voip calls an AS5400 can sustain, depending on the memory,
processor, and codec being used. Is this correct, and if so how do I
calculate it?

 

The codec being used is G.711, which does virtually no compression, so I
would imagine the processor usage is very low as compared to other codecs.

 

ArmoryPl-AS5400#show ver

Cisco Internetwork Operating System Software

IOS (tm) 5400 Software (C5400-JS-M), Version 12.3(3i), RELEASE SOFTWARE
(fc1)

Copyright (c) 1986-2005 by cisco Systems, Inc.

Compiled Fri 12-Aug-05 22:07 by ssearch

Image text-base: 0x6000895C, data-base: 0x6190

 

ROM: System Bootstrap, Version 12.2(1r)1, RELEASE SOFTWARE (fc1)

BOOTLDR: 5400 Software (C5400-BOOT-M), Version 12.1(1)XD1, EARLY DEPLOYMENT
RELEASE SOFTWARE (fc2)

 

ArmoryPl-AS5400 uptime is 1 week, 1 day, 3 hours, 17 minutes

System returned to ROM by bus error at PC 0x6158, address 0x59CCDEC at
11:13:47 EDT Mon Oct 1 2018

System restarted at 11:14:51 EDT Mon Oct 1 2018

System image file is "flash:c5400-js-mz.123-3i.bin"

 

cisco AS5400 (R7K) processor (revision T) with 524288K/131072K bytes of
memory.

Processor board ID JAE09054U8M

R7000 CPU at 250Mhz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3 Cache

Last reset from warm-reset

Bridging software.

X.25 software, Version 3.0.0.

SuperLAT software (copyright 1990 by Meridian Technology Corp).

TN3270 Emulation software.

Primary Rate ISDN software, Version 1.1.

Manufacture Cookie Info:

EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x31,

Board Hardware Version 3.34, Item Number 800-5171-02,

Board Revision C0, Serial Number JAE09054U8M,

PLD/ISP Version 2.2,  Manufacture Date 26-Jan-2005.

Processor 0x14, MAC Address 0x012801C6694

Backplane HW Revision 1.0, Flash Type 5V

2 FastEthernet/IEEE 802.3 interface(s)

444 Serial network interface(s)

432 terminal line(s)

64 Channelized T1/PRI port(s)

2 Channelized T3 port(s)

512K bytes of non-volatile configuration memory.

65536K bytes of processor board System flash (Read/Write)

16384K bytes of processor board Boot flash (Read/Write)

 

 

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


Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

2018-10-09 Thread JASON BURWELL
Unfortunately not. It’s just a port on the back of the phone. The port is 
slightly recessed in to the housing so that does help some but it’s not really 
effective in keeping the cord secure. I have to wonder if some of these designs 
are ever field tested in a real world environment before they make it in to 
production. Luckily the 7832 has an RJ45 Ethernet port on it so not an issue 
for that phone but the 7832 is not a good fit for a medium sized conference 
room. Not sure why they could not have done USB-C and RJ45 on the 8832……….

Jason



From: Lelio Fulgenzi [mailto:le...@uoguelph.ca]
Sent: Tuesday, October 09, 2018 3:56 PM
To: JASON BURWELL ; 'Nimloth' 

Cc: cisco-voip voyp list 
Subject: RE: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Well, this is not encouraging to hear. ☹

And there’s likely no spot to put anything with a wire tie either? Usually, 
they have those little plastic hooks, like the ones that would hold an rj11 
cable.



---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of JASON BURWELL
Sent: Tuesday, October 9, 2018 3:49 PM
To: 'Nimloth' mailto:niml...@nimloth.pl>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Yes, also we hit some bugs with an early FW release. Once it downgraded from 
the factory load, it would brick the phone. Must be a major issue because I had 
to wait almost 2 months for RMA fulfillment. Now that we are running current 
firmware with that bugfix, we seem to be past that issue but now seeing this 
problem.


From: Nimloth [mailto:niml...@nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?

CAUTION: This email originated outside of Founders Federal Credit Union. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

To be honest I won't deploy 8832 in my org as we still struggling to get one up 
and running since few months. Few TAC/RMA already in progress.
W dniu 9 paź 2018, o 20:35, użytkownik JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> napisał:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged 
from the phone when people grab it to slide or move the phone towards them? 
Starting to see some issues with this and I only have a few deployed so far. 
Hoping someone has figured out a workaround or clip to help retain the cord.


This was never a problem before because all the other Cisco Conf phones are not 
only held in by RJ45 clip but also cord clips made in to the base. The 8832 has 
neither, just USB-C cord that plugs in to the back. Thanks! Jason





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


[cisco-voip] VOIP on AS5400

2018-10-09 Thread Joseph Mays
I am recently put in the position of working with some old AS5400s. I put the 
following question to the cisco nas list, but I thought it might be appropriate 
for here, too

The only other question is about the number of voip calls the box can support. 
My understanding (possibly wrong) is that there is an upper limit on the number 
of voip calls an AS5400 can sustain, depending on the memory, processor, and 
codec being used. Is this correct, and if so how do I calculate it?

The codec being used is G.711, which does virtually no compression, so I would 
imagine the processor usage is very low as compared to other codecs.

ArmoryPl-AS5400#show ver
Cisco Internetwork Operating System Software
IOS (tm) 5400 Software (C5400-JS-M), Version 12.3(3i), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Fri 12-Aug-05 22:07 by ssearch
Image text-base: 0x6000895C, data-base: 0x6190

ROM: System Bootstrap, Version 12.2(1r)1, RELEASE SOFTWARE (fc1)
BOOTLDR: 5400 Software (C5400-BOOT-M), Version 12.1(1)XD1, EARLY DEPLOYMENT 
RELEASE SOFTWARE (fc2)

ArmoryPl-AS5400 uptime is 1 week, 1 day, 3 hours, 17 minutes
System returned to ROM by bus error at PC 0x6158, address 0x59CCDEC at 
11:13:47 EDT Mon Oct 1 2018
System restarted at 11:14:51 EDT Mon Oct 1 2018
System image file is "flash:c5400-js-mz.123-3i.bin"

cisco AS5400 (R7K) processor (revision T) with 524288K/131072K bytes of memory.
Processor board ID JAE09054U8M
R7000 CPU at 250Mhz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3 Cache
Last reset from warm-reset
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Primary Rate ISDN software, Version 1.1.
Manufacture Cookie Info:
EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x31,
Board Hardware Version 3.34, Item Number 800-5171-02,
Board Revision C0, Serial Number JAE09054U8M,
PLD/ISP Version 2.2,  Manufacture Date 26-Jan-2005.
Processor 0x14, MAC Address 0x012801C6694
Backplane HW Revision 1.0, Flash Type 5V
2 FastEthernet/IEEE 802.3 interface(s)
444 Serial network interface(s)
432 terminal line(s)
64 Channelized T1/PRI port(s)
2 Channelized T3 port(s)
512K bytes of non-volatile configuration memory.
65536K bytes of processor board System flash (Read/Write)
16384K bytes of processor board Boot flash (Read/Write)

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


Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

2018-10-09 Thread Lelio Fulgenzi
Well, this is not encouraging to hear. ☹

And there’s likely no spot to put anything with a wire tie either? Usually, 
they have those little plastic hooks, like the ones that would hold an rj11 
cable.



---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip  On Behalf Of JASON BURWELL
Sent: Tuesday, October 9, 2018 3:49 PM
To: 'Nimloth' 
Cc: cisco-voip voyp list 
Subject: Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

Yes, also we hit some bugs with an early FW release. Once it downgraded from 
the factory load, it would brick the phone. Must be a major issue because I had 
to wait almost 2 months for RMA fulfillment. Now that we are running current 
firmware with that bugfix, we seem to be past that issue but now seeing this 
problem.


From: Nimloth [mailto:niml...@nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@puck.nether.net>>
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?

CAUTION: This email originated outside of Founders Federal Credit Union. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

To be honest I won't deploy 8832 in my org as we still struggling to get one up 
and running since few months. Few TAC/RMA already in progress.
W dniu 9 paź 2018, o 20:35, użytkownik JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> napisał:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged 
from the phone when people grab it to slide or move the phone towards them? 
Starting to see some issues with this and I only have a few deployed so far. 
Hoping someone has figured out a workaround or clip to help retain the cord.


This was never a problem before because all the other Cisco Conf phones are not 
only held in by RJ45 clip but also cord clips made in to the base. The 8832 has 
neither, just USB-C cord that plugs in to the back. Thanks! Jason





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


Re: [cisco-voip] [EXTERNAL] Re: 8832 Design Issue?

2018-10-09 Thread JASON BURWELL
Yes, also we hit some bugs with an early FW release. Once it downgraded from 
the factory load, it would brick the phone. Must be a major issue because I had 
to wait almost 2 months for RMA fulfillment. Now that we are running current 
firmware with that bugfix, we seem to be past that issue but now seeing this 
problem.


From: Nimloth [mailto:niml...@nimloth.pl]
Sent: Tuesday, October 09, 2018 3:40 PM
To: JASON BURWELL 
Cc: cisco-voip voyp list 
Subject: [EXTERNAL] Re: [cisco-voip] 8832 Design Issue?

CAUTION: This email originated outside of Founders Federal Credit Union. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

To be honest I won't deploy 8832 in my org as we still struggling to get one up 
and running since few months. Few TAC/RMA already in progress.
W dniu 9 paź 2018, o 20:35, użytkownik JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> napisał:
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged 
from the phone when people grab it to slide or move the phone towards them? 
Starting to see some issues with this and I only have a few deployed so far. 
Hoping someone has figured out a workaround or clip to help retain the cord.


This was never a problem before because all the other Cisco Conf phones are not 
only held in by RJ45 clip but also cord clips made in to the base. The 8832 has 
neither, just USB-C cord that plugs in to the back. Thanks! Jason





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


Re: [cisco-voip] 8832 Design Issue?

2018-10-09 Thread Nimloth
To be honest I won't deploy 8832 in my org as we still struggling to get one up 
and running since few months. Few TAC/RMA already in progress.

W dniu 9 paź 2018, 20:35, o 20:35, użytkownik JASON BURWELL 
 napisał:
 >Has anyone else using 8832s had a problem with the USB-C cord coming
>unplugged from the phone when people grab it to slide or move the phone
>towards them? Starting to see some issues with this and I only have a
>few deployed so far. Hoping someone has figured out a workaround or
>clip to help retain the cord.
>
>This was never a problem before because all the other Cisco Conf phones
>are not only held in by RJ45 clip but also cord clips made in to the
>base. The 8832 has neither, just USB-C cord that plugs in to the back.
>Thanks! Jason
>
>
>
>
>
>___
>cisco-voip mailing list
>cisco-voip@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


[cisco-voip] 8832 Design Issue?

2018-10-09 Thread JASON BURWELL
Has anyone else using 8832s had a problem with the USB-C cord coming unplugged 
from the phone when people grab it to slide or move the phone towards them? 
Starting to see some issues with this and I only have a few deployed so far. 
Hoping someone has figured out a workaround or clip to help retain the cord.

This was never a problem before because all the other Cisco Conf phones are not 
only held in by RJ45 clip but also cord clips made in to the base. The 8832 has 
neither, just USB-C cord that plugs in to the back. Thanks! Jason

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


Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Anthony Holloway
OPTIONS does not have to match a dial peer to work.  However, if you are
going to match a dial peer at all, it would likely be for the express
purpose of replying from the correct interface, if you have more than one
potential interfaces, and you for some reason cannot bind globally.  Thus
using the correct bind statement on a dial-peer for OPTIONS reply, would be
necessary.  In which case, you would need to match an incoming call leg
dial peer by the SIP Via header alone, and not, say for example, incoming
called number.

Example Pseudo Configuration:

voice class sip uri 100
 host ipv4:10.1.1.1
!
dial-peer voice 100 voip
 incoming uri via 100
 bind media interface g0/1
 bind control interface g0/1
!

On Tue, Oct 9, 2018 at 1:12 PM Maciej Bylica  wrote:

> Thanks for prompt answer.
>
> No, i am not using CCP.
> As i see OPTIONS ping does not match with any dialpeer
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric
> calling number: *stringhere*
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA
> URL:sip:10.10.10.10:5060, Host:100.64.4.31
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match
> incoming dialpeer for Calling number: : *stringhere*
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:
>
>  input arg error
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match
> found for P-Called-Party-ID
>
> Oct  9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:
>
>  input argument error
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition
> tag absent in Require/Supported header
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media
> Antitrombone disabled
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the
> configured mode as FLOW-THROUGH
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder
> high-density disabled
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode
> set to FLOW_THROUGH
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer
> leg - using RTP Supported Codecs
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 18
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 0
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 8
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 9
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 4
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 2
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 15
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
> Codecs supported by GW 255
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:
> MF: Not a Forked SIP leg..
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp
> configure for this leg.
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:
> peer_callID=0
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:
>
>  MF: *Dial-peer is absent*..
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state
> = 0 & New state = -1
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:
> MF: Anchor leg config reset done...
>
> Oct  9 17:50:04.068:
> //3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:
>
>
>  MF:video profile Dial-peer is absent..
>
>
> OPTIONS looks like following:
>
> OPTIONS sip:domain.name.here:5060 SIP/2.0
>
> From: ;tag=4a6000292f6a
>
> To: 
>
>
>
> I do not have any script in use there, the configuration in pretty basic.
> What i have found is that second OPTIONS (the one that is left/dropped
> without OK) also generates following output:
>
> Oct  9 17:50:38.070:
> //-1//SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:
> Checking Invite Dialog
>
> Oct  9 17:50:38.070:
> //3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:
> *CCB found in UAS Request table. ccb

Re: [cisco-voip] VM Ware Support 6.7

2018-10-09 Thread Matthew Loraditch
While I’m sure it will work, TAC will probably wave a finger. 6.7 support is 
targeted for when the 12.5 releases FCS


Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com
From: cisco-voip  On Behalf Of Scott Voll
Sent: Tuesday, October 9, 2018 2:17 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] VM Ware Support 6.7

All--

I"m currently running most all UC apps on 11.5/6.  It looks like from what I 
can find, ESXi is supported up to 6.5.

My infrastructure Engineer would like to upgrade to 6.7.  Does anyone see any 
problems with that?

Will TAC explode if they find out?

TIA

Scott

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


[cisco-voip] VM Ware Support 6.7

2018-10-09 Thread Scott Voll
All--

I"m currently running most all UC apps on 11.5/6.  It looks like from what
I can find, ESXi is supported up to 6.5.

My infrastructure Engineer would like to upgrade to 6.7.  Does anyone see
any problems with that?

Will TAC explode if they find out?

TIA

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


Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Maciej Bylica
Thanks for prompt answer.

No, i am not using CCP.
As i see OPTIONS ping does not match with any dialpeer

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/1024/ccsipInitPldCallingInfo: non-numeric
calling number: *stringhere*

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetViaHostInURLFormat: VIA
URL:sip:10.10.10.10:5060, Host:100.64.4.31

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match
incoming dialpeer for Calling number: : *stringhere*

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Error/sipSPIGetPeerByCalledPartyId:

 input arg error

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/critical/10240/sipSPIGetCallConfig: No match
found for P-Called-Party-ID

Oct  9 17:50:04.068: //3652/95FFAA748E45/SIP/Error/sipSPIUpdateCallInfo:

 input argument error

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/1024/sipSPIGetCallConfig: Precondition
tag absent in Require/Supported header

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/2048/sipSPIGetCallConfig: Media
Antitrombone disabled

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Storing the
configured mode as FLOW-THROUGH

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/2304/sipSPISetMediaFlowMode: xcoder
high-density disabled

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/8192/sipSPISetMediaFlowMode: Flow Mode
set to FLOW_THROUGH

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: Non dial peer
leg - using RTP Supported Codecs

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 18

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 0

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 8

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 9

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 4

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 2

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 15

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/10240/sipSPIGetCallConfig: RTP Preferred
Codecs supported by GW 255

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec:
MF: Not a Forked SIP leg..

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/1/ccsip_set_srtp_config: No Srtp
configure for this leg.

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/verbose/12288/sipSPIGetModemInfoPerCall:
peer_callID=0

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_anchor_leg_config:

 MF: *Dial-peer is absent*..

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/36864/sipSPIMFChangeState: MF: Prev state
= 0 & New state = -1

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Info/info/32768/ccsip_ipip_media_forking_anchor_leg_reset:
MF: Anchor leg config reset done...

Oct  9 17:50:04.068:
//3652/95FFAA748E45/SIP/Error/ccsip_ipip_media_forking_intra_frame_request_config:


 MF:video profile Dial-peer is absent..


OPTIONS looks like following:

OPTIONS sip:domain.name.here:5060 SIP/2.0

From: ;tag=4a6000292f6a

To: 



I do not have any script in use there, the configuration in pretty basic.
What i have found is that second OPTIONS (the one that is left/dropped
without OK) also generates following output:

Oct  9 17:50:38.070:
//-1//SIP/Info/verbose/4096/ccsip_new_msg_preprocessor:
Checking Invite Dialog

Oct  9 17:50:38.070:
//3653/9862338A8E46/SIP/Info/verbose/4096/sipSPIFindCcbUASReqTable:
*CCB found in UAS Request table. ccb=0x2766B958

Oct  9 17:50:38.070:
//3653/9862338A8E46/SIP/Info/info/4096/sipSPICheckFromToRequest: Trying
with child CCB 0x0 index 0 curr_child 0


Oct  9 17:50:38.070: //3653/9862338A8E46/SIP/Error/sipSPICheckFromToRequest:




Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL

old_from: ;tag=4a6000292f6a

old_to: ;tag=D7E844-1438

new_from: ;tag=6c7f09452671

new_to: 



Oct  9 17:50:04.068: //-1//SIP/Error/httpish_msg_free:

 Freeing NULL pointer!

Could you please point me where i can find some information how to create
such dial-peer for OPTIONS or give me a brief example of this configuration
please.

Thanks
Maciej.




wt., 9 paź 2018 o 16:39 Nick Barnett  napisał(a):

> Are you using Customer Call Back? Which dial peer is the options ping
> hitting? Does that dial peer have the CCB script on it? If so... maybe make
> another dial peer for options pings that does not have the script enabled.
> This is just a hunch...
>
> On Tue, Oct 9, 2018 at 6:50 AM Maciej B

Re: [cisco-voip] Hola, Email relay?

2018-10-09 Thread Anthony Holloway
I'd do the Domona thing personally, because if you are electing to
integrate voicemail and email, then not having your email and voicemail
synced can become a problem.  As is the case with Accept and Relay.  Now,
you could just to do Relay with no Accept, but then you take away the
ability to check voicemail on the phone.

Whether you're doing the relay, with or without accept, or you're doing
notifications only, the easy SMTP relay server for CUC when using Gmail is
aspmx.l.google.com.

This allows you to send email from anywhere (E.g., CUC) to any gmail email
address.

It's from this article:

https://support.google.com/a/answer/176600?hl=en

On Tue, Oct 9, 2018 at 11:00 AM Parker Pearson - Donoma <
par...@donomasoftware.com> wrote:

> Unified messaging functionality between UCN and Gmail does not have to go
> Esna CloudLink.
>
>
>
> Donoma Unify for Gmail is a solution available for this functionality.
> Available as cloud service or on prem virtual application and has been
> through Cisco Interoperability Verification testing so it’s a recognized
> application by Cisco TAC.  Available from Cisco resellers, or feel free to
> contact us direct.
>
>
>
> [image: Donoma Software Web Page] 
> Parker Pearson
> Vice President, Marketing & Business Development
>
>
> * Donoma Software *1750 Kraft Dr. Suite 1200 Blacksburg, VA 24060
> 540.443.3577
> par...@donomasoftware.com
> www.donomasoftware.com
> [image: Facebook]  [image:
> Twitter]  [image: LinkedIn]
> 
>
> *From: *cisco-voip  on behalf of
> Jonatan Quezada 
> *Date: *Tuesday, October 9, 2018 at 11:48 AM
> *To: *"cisco-voip@puck.nether.net" 
> *Subject: *[cisco-voip] Hola, Email relay?
>
>
>
> Is there any one out there that is using google for their domain, but
> running cucm, unity and an ESNA cloudlink relay? I see now that ESNA might
> be part of avaya?
>
>
>
> What are seeing people trying when they want to relay voicemail to email
> boxes on google?
>
>
>
> does cisco have a voicemail relay that can be leveraged in unity?
> Apparently ESNA can pretend to be the presence server for the unification
> of a voice network. is anyone using this to do that and unify stuff on
> their network and domain?
>
>
>
> any insight would be awesome. Cheers!
>
>
>
> --
>
> For immediate assistance please reach out to Chemeketa IT Help Desk at
> 5033997899
>
> -or-
>
> Visit the help center
>
>
>
> https://projects.chemeketa.edu/servicedesk/customer/portals
>
>
>
> Johnny Q
>
> Voice Technology Analyst II
>
> Network, Infrastructure, Routing Devices, and Servers
>
> Chemeketa Community College
>
> johnn...@chemeketa.edu
>
> Building 22 Room 130
>
> Work 5033995294
>
> Mobile 9712182110
>
> SIP 5035406689
>
> FAX 5033995549
>
>
>
> --
>
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender and
> destroy any copies of this information.
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] Hola, Email relay?

2018-10-09 Thread Parker Pearson - Donoma
Unified messaging functionality between UCN and Gmail does not have to go Esna 
CloudLink.

Donoma Unify for Gmail is a solution available for this functionality.  
Available as cloud service or on prem virtual application and has been through 
Cisco Interoperability Verification testing so it’s a recognized application by 
Cisco TAC.  Available from Cisco resellers, or feel free to contact us direct.


[Donoma Software Web Page]

Parker Pearson
Vice President, Marketing & Business Development

Donoma Software
1750 Kraft Dr. Suite 1200 Blacksburg, VA 24060
540.443.3577
par...@donomasoftware.com
www.donomasoftware.com
[Facebook] [Twitter] 
  [LinkedIn] 



From: cisco-voip  on behalf of Jonatan 
Quezada 
Date: Tuesday, October 9, 2018 at 11:48 AM
To: "cisco-voip@puck.nether.net" 
Subject: [cisco-voip] Hola, Email relay?

Is there any one out there that is using google for their domain, but running 
cucm, unity and an ESNA cloudlink relay? I see now that ESNA might be part of 
avaya?

What are seeing people trying when they want to relay voicemail to email boxes 
on google?

does cisco have a voicemail relay that can be leveraged in unity? Apparently 
ESNA can pretend to be the presence server for the unification of a voice 
network. is anyone using this to do that and unify stuff on their network and 
domain?

any insight would be awesome. Cheers!

--
For immediate assistance please reach out to Chemeketa IT Help Desk at 
5033997899
-or-
Visit the help center

https://projects.chemeketa.edu/servicedesk/customer/portals

Johnny Q
Voice Technology Analyst II
Network, Infrastructure, Routing Devices, and Servers
Chemeketa Community College
johnn...@chemeketa.edu
Building 22 Room 130
Work 5033995294
Mobile 9712182110
SIP 5035406689
FAX 5033995549





The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


[cisco-voip] Hola, Email relay?

2018-10-09 Thread Jonatan Quezada
Is there any one out there that is using google for their domain, but
running cucm, unity and an ESNA cloudlink relay? I see now that ESNA might
be part of avaya?

What are seeing people trying when they want to relay voicemail to email
boxes on google?

does cisco have a voicemail relay that can be leveraged in unity?
Apparently ESNA can pretend to be the presence server for the unification
of a voice network. is anyone using this to do that and unify stuff on
their network and domain?

any insight would be awesome. Cheers!

-- 
For immediate assistance please reach out to Chemeketa IT Help Desk at
5033997899
-or-
Visit the help center

https://projects.chemeketa.edu/servicedesk/customer/portals

Johnny Q
Voice Technology Analyst II
Network, Infrastructure, Routing Devices, and Servers
Chemeketa Community College
johnn...@chemeketa.edu
Building 22 Room 130
Work 5033995294
Mobile 9712182110
SIP 5035406689
FAX 5033995549
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Nick Barnett
Are you using Customer Call Back? Which dial peer is the options ping
hitting? Does that dial peer have the CCB script on it? If so... maybe make
another dial peer for options pings that does not have the script enabled.
This is just a hunch...

On Tue, Oct 9, 2018 at 6:50 AM Maciej Bylica  wrote:

> Hi
>
> I have really strange problem with SIP OPTIONS pings.
> The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only to the
> first OPTIONS packet that is received from the endpoint.
> The rest of OPTIONs are dropped with following debug output:
>
> Oct  9 12:52:06 10.10.10.10 8694907: Oct  9 10:55:58.194:
> //-1//SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
> SIPSPI_EV_CC_OPTIONS_RESP
> Oct  9 12:52:06 10.10.10.10 8694908: Oct  9 10:55:58.194:
> //148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:
> ccsip_api_options_ind returned: SIP_SUCCESS
> Oct  9 12:52:06 10.10.10.10 8694909: Oct  9 10:55:58.194:
> //148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State
> change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
> SUBSTATE_NONE)
> Oct  9 12:52:06 10.10.10.10 8694910: Oct  9 10:55:58.194:
> //148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:
> Oct  9 12:52:06 10.10.10.10 8694911:  *Could not add ccb to table*.
> ccb=0x258D7210
> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3
> Oct  9 12:52:06 10.10.10.10 8694912: Oct  9 10:55:58.194:
> //148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:
> Oct  9 12:52:06 10.10.10.10 8694913:  *Resource failure, dropping OPTIONS*
>
> The true is that Cisco receives quite significant amount of SIP OPTIONs
> from the endpoint in short time, like 10 OPTIONS packeges within
> miliseconds.
> The after-effect i want to achieve is a response for each incoming OPTIONS
>
> Example of a successful response:
> Oct  9 11:30:37 10.10.10.10 8625106: Oct  9 09:34:28.569:
> //-1//SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
> SIPSPI_EV_CC_OPTIONS_RESP
> Oct  9 11:30:37 10.10.10.10 8625107: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:
> ccsip_api_options_ind returned: SIP_SUCCESS
> Oct  9 11:30:37 10.10.10.10 8625108: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State
> change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
> SUBSTATE_NONE)
> Oct  9 11:30:37 10.10.10.10 8625109: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to
> table. ccb=0x258B1110
> key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance
> 1
> Oct  9 11:30:37 10.10.10.10 8625110: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:
> Adding call id 23DA9 to table
> Oct  9 11:30:37 10.10.10.10 8625111: Oct  9 09:34:28.569:
> //-1//SIP/Info/info/4096/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 3 for event 38
> Oct  9 11:30:37 10.10.10.10 8625112: Oct  9 09:34:28.569:
> //-1//SIP/Info/info/1024/httpish_msg_create: created
> msg=0x203FFDA4 with refCount = 1
> Oct  9 11:30:37 10.10.10.10 8625113: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:
> Associated container=0x2673A528 to Options Response
> Oct  9 11:30:37 10.10.10.10 8625114: Oct  9 09:34:28.569:
> //-1//SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:
> sipSPIAppHandleContainerBody len 164
> Oct  9 11:30:37 10.10.10.10 8625115: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:
> msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,
> is_req=0, transport=1, switch=0, callBack=0x4F48054
> Oct  9 11:30:37 10.10.10.10 8625116: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP
> extension config:1, check sys cfg:1
> Oct  9 11:30:37 10.10.10.10 8625117: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable
> for sending msg immediately
> Oct  9 11:30:37 10.10.10.10 8625118: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to
> send resp=0x203FFDA4 to default port=5060
> Oct  9 11:30:37 10.10.10.10 8625119: Oct  9 09:34:28.569:
> //-1//SIP/Transport/sipConnectionManagerGetConnection:
> connection required for raddr:11.11.11.11, rport:5060 with laddr:
> Oct  9 11:30:37 10.10.10.10 8625120: Oct  9 09:34:28.569:
> //-1//SIP/Transport/sipInstanceGetConnectionId: Registering
> gcb=0x258B1110 with connection=0x2426673C context list
> Oct  9 11:30:37 10.10.10.10 8625121: Oct  9 09:34:28.569:
> //146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection
> obtained...sending msg=0x203FFDA4
> Oct  9 11:30:37 10.10.10.10 8625122: Oct  9 09:34:28.569:
> //-1//SIP/Transport/sipTransportPostSendMessage: Po

[cisco-voip] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

2018-10-09 Thread Maciej Bylica
Hi

I have really strange problem with SIP OPTIONS pings.
The Cisco i have (CUBE 3945 ios Version 15.3(3)M5) responds only to the
first OPTIONS packet that is received from the endpoint.
The rest of OPTIONs are dropped with following debug output:

Oct  9 12:52:06 10.10.10.10 8694907: Oct  9 10:55:58.194:
//-1//SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
SIPSPI_EV_CC_OPTIONS_RESP
Oct  9 12:52:06 10.10.10.10 8694908: Oct  9 10:55:58.194:
//148025/BCB3C79A92C0/SIP/Info/info/4096/sact_idle_new_message_options:
ccsip_api_options_ind returned: SIP_SUCCESS
Oct  9 12:52:06 10.10.10.10 8694909: Oct  9 10:55:58.194:
//148025/BCB3C79A92C0/SIP/State/sipSPIChangeState: 0x258D7210 : State
change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
SUBSTATE_NONE)
Oct  9 12:52:06 10.10.10.10 8694910: Oct  9 10:55:58.194:
//148025/BCB3C79A92C0/SIP/Error/sipSPIUaddCcbToTable:
Oct  9 12:52:06 10.10.10.10 8694911:  *Could not add ccb to table*.
ccb=0x258D7210
key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3
Oct  9 12:52:06 10.10.10.10 8694912: Oct  9 10:55:58.194:
//148025/BCB3C79A92C0/SIP/Error/sact_idle_new_message_options:
Oct  9 12:52:06 10.10.10.10 8694913:  *Resource failure, dropping OPTIONS*

The true is that Cisco receives quite significant amount of SIP OPTIONs
from the endpoint in short time, like 10 OPTIONS packeges within
miliseconds.
The after-effect i want to achieve is a response for each incoming OPTIONS

Example of a successful response:
Oct  9 11:30:37 10.10.10.10 8625106: Oct  9 09:34:28.569:
//-1//SIP/Event/sipSPIEventInfo: Queued event from SIP SPI :
SIPSPI_EV_CC_OPTIONS_RESP
Oct  9 11:30:37 10.10.10.10 8625107: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Info/info/4096/sact_idle_new_message_options:
ccsip_api_options_ind returned: SIP_SUCCESS
Oct  9 11:30:37 10.10.10.10 8625108: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/State/sipSPIChangeState: 0x258B1110 : State
change from (STATE_IDLE, SUBSTATE_NONE)  to (SIP_STATE_OPTIONS_WAIT,
SUBSTATE_NONE)
Oct  9 11:30:37 10.10.10.10 8625109: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddCcbToTable: Added to
table. ccb=0x258B1110
key=c3c4f5582a4bfa1ff4b7e741c3cb6c6822f738b4cd7e78633fc70f5441197d3 balance
1
Oct  9 11:30:37 10.10.10.10 8625110: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Info/verbose/4096/sipSPIUaddccCallIdToTable:
Adding call id 23DA9 to table
Oct  9 11:30:37 10.10.10.10 8625111: Oct  9 09:34:28.569:
//-1//SIP/Info/info/4096/ccsip_process_sipspi_queue_event:
ccsip_spi_get_msg_type returned: 3 for event 38
Oct  9 11:30:37 10.10.10.10 8625112: Oct  9 09:34:28.569:
//-1//SIP/Info/info/1024/httpish_msg_create: created
msg=0x203FFDA4 with refCount = 1
Oct  9 11:30:37 10.10.10.10 8625113: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Info/info/4096/sipSPISendOptionsResponse:
Associated container=0x2673A528 to Options Response
Oct  9 11:30:37 10.10.10.10 8625114: Oct  9 09:34:28.569:
//-1//SIP/Info/verbose/8192/sipSPIAppHandleContainerBody:
sipSPIAppHandleContainerBody len 164
Oct  9 11:30:37 10.10.10.10 8625115: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage:
msg=0x203FFDA4, addr=11.11.11.11, port=5060, sentBy_port=5060, local_addr=,
is_req=0, transport=1, switch=0, callBack=0x4F48054
Oct  9 11:30:37 10.10.10.10 8625116: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Info/info/2048/sipSPIGetExtensionCfg: SIP
extension config:1, check sys cfg:1
Oct  9 11:30:37 10.10.10.10 8625117: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Transport/sipSPITransportSendMessage: Proceedable
for sending msg immediately
Oct  9 11:30:37 10.10.10.10 8625118: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Trying to
send resp=0x203FFDA4 to default port=5060
Oct  9 11:30:37 10.10.10.10 8625119: Oct  9 09:34:28.569:
//-1//SIP/Transport/sipConnectionManagerGetConnection:
connection required for raddr:11.11.11.11, rport:5060 with laddr:
Oct  9 11:30:37 10.10.10.10 8625120: Oct  9 09:34:28.569:
//-1//SIP/Transport/sipInstanceGetConnectionId: Registering
gcb=0x258B1110 with connection=0x2426673C context list
Oct  9 11:30:37 10.10.10.10 8625121: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Transport/sipTransportLogicSendMsg: Connection
obtained...sending msg=0x203FFDA4
Oct  9 11:30:37 10.10.10.10 8625122: Oct  9 09:34:28.569:
//-1//SIP/Transport/sipTransportPostSendMessage: Posting send
for msg=0x203FFDA4, addr=11.11.11.11, port=5060, local_addr=, connId=2 for
UDP
Oct  9 11:30:37 10.10.10.10 8625123: Oct  9 09:34:28.569:
//146857/5A42A0608E30/SIP/Msg/ccsipDisplayMsg:
Oct  9 11:30:37 10.10.10.10 8625124: Sent:
Oct  9 11:30:37 10.10.10.10 8625125: SIP/2.0 200 OK#015

Could someone help me with this? I really appreciate your advice.

Maciej
___
cisco-voip mailing list
cisco-voip@puck.nether.net

Re: [cisco-voip] TAC Support Cases just shows spinning wheel

2018-10-09 Thread Lelio Fulgenzi
Hmmm, can’t comment on using it over slow links, but I’ve enjoyed the new 
tools. Except for the expanding each note section, maybe.

The file upload tool is one of the best they’ve made. They better not change 
that any tie soon. :)

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 9, 2018, at 6:40 AM, Jason Aarons (Americas) 
mailto:jason.aar...@dimensiondata.com>> wrote:



Not a fan of the website changes for TAC cases……lots of spinning wheels….. 
https://mycase.cloudapps.cisco.com/case


Contract is associated to account, yet Open TAC case can’t find the Service 
Contract, have to call in every time, took 30 minutes to open a new case over 
the phone.

Try it over a high latency satellite link and it just fails.

-jason



This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer";
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


[cisco-voip] TAC Support Cases just shows spinning wheel

2018-10-09 Thread Jason Aarons (Americas)
   Not a fan of the website changes for TAC cases..lots of spinning 
wheels. https://mycase.cloudapps.cisco.com/case


Contract is associated to account, yet Open TAC case can't find the Service 
Contract, have to call in every time, took 30 minutes to open a new case over 
the phone.

Try it over a high latency satellite link and it just fails.

-jason

This email and all contents are subject to the following disclaimer:

"http://www.dimensiondata.com/emaildisclaimer";
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip