We will try to convince the customer to adjust the settings on his side
(unique Call-ID for every OPTIONs would do the job).
As a workaround we do have C3845 with 12.x IOS :)
Many thanks for your help
Maciej.
czw., 11 paź 2018 o 23:52 Anthony Holloway
napisał(a):
> Fair enough. We're not alwa
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
> shoul
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, but
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 o
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 wit
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
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.
Obv
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 its
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 cor
Hello
Anthony, thanks for the hint, but you were right this is not the core of
the issue.
I made some test via sipp with following results
1)
Test: Send 15xOPTIONS with the same Call-ID and From-tag
Result: All OPTIONS were replied
2)
Test: shortly after completing the above test I made another
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
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 c
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 th
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/si
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:
16 matches
Mail list logo
