“Good save, wedding singer.” comes to mind.
Thanks for sharing this.
-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.
H, I don’t remember seeing anything on the screen when I connected via
proximity. Will have to check again. My head was likely looking down at my
device.
The idea of macros is nice, but not sure it really helps secure the system
while they actually want to use it.
It’s not ideal, but in
I think this has been covered on this list before but that specific issue is
NOT a problem that requires an RMA to resolve.
It’s an incompatibility of older loads with the PoE injector.
It’s not PIN controlled, the idea is that if the device is in range of the
ultrasound and on a network that has https connectivity to the codec then it
can connect.
Users in the room also see a notification on the screen when a proximity client
connects, so it’s not hidden.
If you want your
Wondering if anyone out there has attempted or completed an Alertus integration.
Preliminary discussions showed they required updating the Description field of
the DN in order to build custom groups if the groups we want couldn’t be built
from existing configuration options like partitions.
Fair enough. We're not always paid to perform the second O in PPDIOO.
Your answer is better than "I don't know" ;) Again, thanks for sharing
your experiences.
On Thu, Oct 11, 2018 at 3:57 PM Kent Roberts wrote:
> Oh sorry, I didn’t catch that on the receiving part.Well, I probably
>
Should also throw out that, one of the carriers, didn’t care about options as
long as there was something hitting it.
> On Oct 11, 2018, at 2:57 PM, Kent Roberts wrote:
>
> Oh sorry, I didn’t catch that on the receiving part.Well, I probably
> should re-look at some of the commands,
Oh sorry, I didn’t catch that on the receiving part.Well, I probably should
re-look at some of the commands, but we were one of the first adopters of SIP
and not all the defaults that exist today, existed back then. Some of it got
left in cause it works with the carrier.:) Some
Kent,
I'm not sure why you sent that. The problem is not with sending OPTION
Ping, it's with responding to received OPTION Ping.
*"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
Here is what I use:
voice-class sip options-keepalive up-interval 180 down-interval 60 retry 2
Sh dial-peer voice sumthe Keepalive line will show busyout or active.
> On Oct 11, 2018, at 12:36 PM, Nick Barnett wrote:
>
> I don’t know what the problem is either. Maybe if you grab ccapi
I don’t know what the problem is either. Maybe if you grab ccapi inout
debugs at the same time, your voice service voip section (at least, whole
config would be better), sh ver, and show run | sec voice. Maybe even do a
debug ccsip all if you have the ability to do that and NOT crash your CUBE.
I feel obligated to reply, since I chimed in earlierunfortunately, I
don't have any ideas for you. In fact, I have seen CUBE just ignore
incoming SIP messages before, both OPTIONS and INVITEs alike. Not many
occasions, just a few. I have never gotten resolution on it, it has either
fixed
Hello
Do you have an idea how to get around this problem?
Have you ever encountered such limitations in the process of processing
OPTIONS packages?
Thanks
Maciej.
śr., 10 paź 2018 o 09:13 Maciej Bylica napisał(a):
> Hello
>
> Anthony, thanks for the hint, but you were right this is not the
13 matches
Mail list logo
