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

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

2018-10-16 Thread Maciej Bylica

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 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 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 of it was also trial and error with the carrier, and well when it
>> starts working sometimes things don’t get revisited….   Hows that for an
>> answer!!!
>>
>>
>>
>> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> 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 with following debug output"*
>>
>> But since you brought it up... The default for that command is:
>>
>> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5
>>
>> What is your reason for changing it from the default?  The rule of thumb
>> is "use the defaults, unless you have a reason not to"
>>
>> I see the obvious answer here: it pings less often; however, it's the
>> *why* which I am interested in.
>>
>> Thanks for sharing what you do.
>>
>> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts  wrote:
>>
>>> 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 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.
>>> Obviously don’t debug ccsip all without thinking about what that will do.
>>>
>>>
>>> Even with all of that, I’m not sure I’ll have an answer, but I’ll look.
>>> I’ve had similar issues with my CUBEs and it was due to binding issues and
>>> another time it was a straight up bug and I had to bounce the box (which
>>> “fixed” it).  I don’t know why your initial debug was showing “could
>>> not add ccb to table” and I’m not even sure which CCB it’s talking about.
>>> My thoughts were that is customer callback… but I’m probably wrong on that
>>> one.
>>>
>>>
>>> Nick
>>>
>>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 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 itself, or in one special case, still happens.  It's my own, in
 fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
 is on my to-do list, but...  The cobbler's children are always the
 worst-shod
 .
 The Calls Per Second on my CUBE is like 1.7, however, there are no other
 calls being setup, torn down, sup service, etc, and CUBE still just ignores
 its responsibility.

 On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica 
 wrote:

> 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 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 test:
>> Send 15xOPTIONS with the same Call-ID as previously but different 
>> From-tag.
>> Result: None of the OPTIONS we’re replied.
>>
>> 3)
>> Test: Test 2 was re-run after a while

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

2018-10-11 Thread Anthony Holloway

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 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 of it was also trial and error with the carrier, and well when it
> starts working sometimes things don’t get revisited….   Hows that for an
> answer!!!
>
>
>
> On Oct 11, 2018, at 2:42 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 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 with following debug output"*
>
> But since you brought it up... The default for that command is:
>
> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5
>
> What is your reason for changing it from the default?  The rule of thumb
> is "use the defaults, unless you have a reason not to"
>
> I see the obvious answer here: it pings less often; however, it's the
> *why* which I am interested in.
>
> Thanks for sharing what you do.
>
> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts  wrote:
>
>> 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 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.
>> Obviously don’t debug ccsip all without thinking about what that will do.
>>
>>
>> Even with all of that, I’m not sure I’ll have an answer, but I’ll look.
>> I’ve had similar issues with my CUBEs and it was due to binding issues and
>> another time it was a straight up bug and I had to bounce the box (which
>> “fixed” it).  I don’t know why your initial debug was showing “could not
>> add ccb to table” and I’m not even sure which CCB it’s talking about. My
>> thoughts were that is customer callback… but I’m probably wrong on that one.
>>
>>
>> Nick
>>
>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> 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 itself, or in one special case, still happens.  It's my own, in
>>> fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
>>> is on my to-do list, but...  The cobbler's children are always the
>>> worst-shod
>>> .
>>> The Calls Per Second on my CUBE is like 1.7, however, there are no other
>>> calls being setup, torn down, sup service, etc, and CUBE still just ignores
>>> its responsibility.
>>>
>>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica 
>>> wrote:
>>>
 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 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 test:
> Send 15xOPTIONS with the same Call-ID as previously but different 
> From-tag.
> Result: None of the OPTIONS we’re replied.
>
> 3)
> Test: Test 2 was re-run after a while
> Result: All OPTIONS were replied
>
> So it seems Cisco records the Call-ID and From-tag somewhere in memory
> and drops subsequent OPTIONS with the same Call-ID and different From-tag
> that come from the same endpoint for some time.
>
> I have similar situation here.
> The customer we are trying to connect sends several OPTIONS within
> miliseconds.
>

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

2018-10-11 Thread Kent Roberts

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 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 of it was 
> also trial and error with the carrier, and well when it starts working 
> sometimes things don’t get revisited….   Hows that for an answer!!!
> 
> 
> 
>> On Oct 11, 2018, at 2:42 PM, Anthony Holloway 
>> mailto:avholloway+cisco-v...@gmail.com>> 
>> wrote:
>> 
>> 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 with following debug output"
>> 
>> But since you brought it up... The default for that command is:
>> 
>> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5
>> 
>> What is your reason for changing it from the default?  The rule of thumb is 
>> "use the defaults, unless you have a reason not to"
>> 
>> I see the obvious answer here: it pings less often; however, it's the why 
>> which I am interested in.
>> 
>> Thanks for sharing what you do.
>> 
>> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts > > wrote:
>> 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 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. 
>>> Obviously don’t debug ccsip all without thinking about what that will do.
>>> 
>>>  
>>> Even with all of that, I’m not sure I’ll have an answer, but I’ll look. 
>>> I’ve had similar issues with my CUBEs and it was due to binding issues and 
>>> another time it was a straight up bug and I had to bounce the box (which 
>>> “fixed” it).  I don’t know why your initial debug was showing “could not 
>>> add ccb to table” and I’m not even sure which CCB it’s talking about. My 
>>> thoughts were that is customer callback… but I’m probably wrong on that one.
>>> 
>>>  
>>> Nick
>>> 
>>> 
>>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway 
>>> >> > wrote:
>>> 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 itself, or in one special case, still happens.  It's my own, in fact. 
>>>  It still randomly ignores inbound INVITES from my ITSP.  Fixing it, is on 
>>> my to-do list, but...  The cobbler's children are always the worst-shod 
>>> .
>>>   The Calls Per Second on my CUBE is like 1.7, however, there are no other 
>>> calls being setup, torn down, sup service, etc, and CUBE still just ignores 
>>> its responsibility.
>>> 
>>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica >> > wrote:
>>> 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 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 test: Send 
>>> 15xOPTIONS with the same Call-ID as previously but different From-tag.
>>> Result: None of the OPTIONS we’re replied.
>>> 
>>> 3) 
>>> Test: Test 2 was re-run after a while
>>> Result: All OPTIONS were replied
>>> 
>>> So it seems Cisco records the Call-ID and From-tag somewhere in memory and 
>>> drops subsequent OPTIONS with the same Call-ID and different From-tag that 
>>> come from the same endpoint for some time.

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

2018-10-11 Thread Kent Roberts

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 of it was also trial 
and error with the carrier, and well when it starts working sometimes things 
don’t get revisited….   Hows that for an answer!!!



> On Oct 11, 2018, at 2:42 PM, Anthony Holloway 
>  wrote:
> 
> 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 with following debug output"
> 
> But since you brought it up... The default for that command is:
> 
> voice class sip options-keepalive up-interval 60 down-interval 30 retry 5
> 
> What is your reason for changing it from the default?  The rule of thumb is 
> "use the defaults, unless you have a reason not to"
> 
> I see the obvious answer here: it pings less often; however, it's the why 
> which I am interested in.
> 
> Thanks for sharing what you do.
> 
> On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts  > wrote:
> 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 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. 
>> Obviously don’t debug ccsip all without thinking about what that will do.
>> 
>>  
>> Even with all of that, I’m not sure I’ll have an answer, but I’ll look. I’ve 
>> had similar issues with my CUBEs and it was due to binding issues and 
>> another time it was a straight up bug and I had to bounce the box (which 
>> “fixed” it).  I don’t know why your initial debug was showing “could not add 
>> ccb to table” and I’m not even sure which CCB it’s talking about. My 
>> thoughts were that is customer callback… but I’m probably wrong on that one.
>> 
>>  
>> Nick
>> 
>> 
>> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway 
>> mailto:avholloway%2bcisco-v...@gmail.com>> 
>> wrote:
>> 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 itself, or in one special case, still happens.  It's my own, in fact.  
>> It still randomly ignores inbound INVITES from my ITSP.  Fixing it, is on my 
>> to-do list, but...  The cobbler's children are always the worst-shod 
>> .
>>   The Calls Per Second on my CUBE is like 1.7, however, there are no other 
>> calls being setup, torn down, sup service, etc, and CUBE still just ignores 
>> its responsibility.
>> 
>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica > > wrote:
>> 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 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 test: Send 
>> 15xOPTIONS with the same Call-ID as previously but different From-tag.
>> Result: None of the OPTIONS we’re replied.
>> 
>> 3) 
>> Test: Test 2 was re-run after a while
>> Result: All OPTIONS were replied
>> 
>> So it seems Cisco records the Call-ID and From-tag somewhere in memory and 
>> drops subsequent OPTIONS with the same Call-ID and different From-tag that 
>> come from the same endpoint for some time.
>> 
>> I have similar situation here.
>> The customer we are trying to connect sends several OPTIONS within 
>> miliseconds.
>> First OPTIONS is replied properly, but subsequent packets with the same 
>> Call-ID and different From-tag dropped.
>> 
>> Is there any solution for this.
>> Our customer is very reluctant to proceed with any changes

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

2018-10-11 Thread Anthony Holloway

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 with following debug output"*

But since you brought it up... The default for that command is:

voice class sip options-keepalive up-interval 60 down-interval 30 retry 5

What is your reason for changing it from the default?  The rule of thumb is
"use the defaults, unless you have a reason not to"

I see the obvious answer here: it pings less often; however, it's the *why*
which I am interested in.

Thanks for sharing what you do.

On Thu, Oct 11, 2018 at 3:32 PM Kent Roberts  wrote:

> 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 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.
> Obviously don’t debug ccsip all without thinking about what that will do.
>
>
> Even with all of that, I’m not sure I’ll have an answer, but I’ll look.
> I’ve had similar issues with my CUBEs and it was due to binding issues and
> another time it was a straight up bug and I had to bounce the box (which
> “fixed” it).  I don’t know why your initial debug was showing “could not
> add ccb to table” and I’m not even sure which CCB it’s talking about. My
> thoughts were that is customer callback… but I’m probably wrong on that one.
>
>
> Nick
>
> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> 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 itself, or in one special case, still happens.  It's my own, in
>> fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
>> is on my to-do list, but...  The cobbler's children are always the
>> worst-shod
>> .
>> The Calls Per Second on my CUBE is like 1.7, however, there are no other
>> calls being setup, torn down, sup service, etc, and CUBE still just ignores
>> its responsibility.
>>
>> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica 
>> wrote:
>>
>>> 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 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 test: Send
 15xOPTIONS with the same Call-ID as previously but different From-tag.
 Result: None of the OPTIONS we’re replied.

 3)
 Test: Test 2 was re-run after a while
 Result: All OPTIONS were replied

 So it seems Cisco records the Call-ID and From-tag somewhere in memory
 and drops subsequent OPTIONS with the same Call-ID and different From-tag
 that come from the same endpoint for some time.

 I have similar situation here.
 The customer we are trying to connect sends several OPTIONS within
 miliseconds.
 First OPTIONS is replied properly, but subsequent packets with the same
 Call-ID and different From-tag dropped.

 Is there any solution for this.
 Our customer is very reluctant to proceed with any changes (another
 open source SIP proxies replies all the OPTIONS).

 Thanks
 Maciej.

 wt., 9 paź 2018 o 23:45 Anthony Holloway <
 avholloway+cisco-v...@gmail.com> napisał(a):

> 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

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

2018-10-11 Thread Kent Roberts

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 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. 
> Obviously don’t debug ccsip all without thinking about what that will do.
> 
>  
> Even with all of that, I’m not sure I’ll have an answer, but I’ll look. I’ve 
> had similar issues with my CUBEs and it was due to binding issues and another 
> time it was a straight up bug and I had to bounce the box (which “fixed” it). 
>  I don’t know why your initial debug was showing “could not add ccb to table” 
> and I’m not even sure which CCB it’s talking about. My thoughts were that is 
> customer callback… but I’m probably wrong on that one.
> 
>  
> Nick
> 
> 
> On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway 
> mailto:avholloway%2bcisco-v...@gmail.com>> 
> wrote:
> 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 
> itself, or in one special case, still happens.  It's my own, in fact.  It 
> still randomly ignores inbound INVITES from my ITSP.  Fixing it, is on my 
> to-do list, but...  The cobbler's children are always the worst-shod 
> .
>   The Calls Per Second on my CUBE is like 1.7, however, there are no other 
> calls being setup, torn down, sup service, etc, and CUBE still just ignores 
> its responsibility.
> 
> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica  > wrote:
> 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 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 test: Send 
> 15xOPTIONS with the same Call-ID as previously but different From-tag.
> Result: None of the OPTIONS we’re replied.
> 
> 3) 
> Test: Test 2 was re-run after a while
> Result: All OPTIONS were replied
> 
> So it seems Cisco records the Call-ID and From-tag somewhere in memory and 
> drops subsequent OPTIONS with the same Call-ID and different From-tag that 
> come from the same endpoint for some time.
> 
> I have similar situation here.
> The customer we are trying to connect sends several OPTIONS within 
> miliseconds.
> First OPTIONS is replied properly, but subsequent packets with the same 
> Call-ID and different From-tag dropped.
> 
> Is there any solution for this.
> Our customer is very reluctant to proceed with any changes (another open 
> source SIP proxies replies all the OPTIONS).
> 
> Thanks
> Maciej.
> 
> wt., 9 paź 2018 o 23:45 Anthony Holloway  > napisał(a):
> 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

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

2018-10-11 Thread Nick Barnett

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.
Obviously don’t debug ccsip all without thinking about what that will do.



Even with all of that, I’m not sure I’ll have an answer, but I’ll look.
I’ve had similar issues with my CUBEs and it was due to binding issues and
another time it was a straight up bug and I had to bounce the box (which
“fixed” it).  I don’t know why your initial debug was showing “could not
add ccb to table” and I’m not even sure which CCB it’s talking about. My
thoughts were that is customer callback… but I’m probably wrong on that one.



Nick

On Thu, Oct 11, 2018 at 11:11 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> 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 itself, or in one special case, still happens.  It's my own, in
> fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
> is on my to-do list, but...  The cobbler's children are always the
> worst-shod
> .
> The Calls Per Second on my CUBE is like 1.7, however, there are no other
> calls being setup, torn down, sup service, etc, and CUBE still just ignores
> its responsibility.
>
> On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica 
> wrote:
>
>> 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 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 test: Send
>>> 15xOPTIONS with the same Call-ID as previously but different From-tag.
>>> Result: None of the OPTIONS we’re replied.
>>>
>>> 3)
>>> Test: Test 2 was re-run after a while
>>> Result: All OPTIONS were replied
>>>
>>> So it seems Cisco records the Call-ID and From-tag somewhere in memory
>>> and drops subsequent OPTIONS with the same Call-ID and different From-tag
>>> that come from the same endpoint for some time.
>>>
>>> I have similar situation here.
>>> The customer we are trying to connect sends several OPTIONS within
>>> miliseconds.
>>> First OPTIONS is replied properly, but subsequent packets with the same
>>> Call-ID and different From-tag dropped.
>>>
>>> Is there any solution for this.
>>> Our customer is very reluctant to proceed with any changes (another open
>>> source SIP proxies replies all the OPTIONS).
>>>
>>> Thanks
>>> Maciej.
>>>
>>> wt., 9 paź 2018 o 23:45 Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> napisał(a):
>>>
 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 <
> avholloway+cisco-v...@gmail.com> 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
>> !

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

2018-10-11 Thread Anthony Holloway

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 itself, or in one special case, still happens.  It's my own, in
fact.  It still randomly ignores inbound INVITES from my ITSP.  Fixing it,
is on my to-do list, but...  The cobbler's children are always the
worst-shod
.
The Calls Per Second on my CUBE is like 1.7, however, there are no other
calls being setup, torn down, sup service, etc, and CUBE still just ignores
its responsibility.

On Thu, Oct 11, 2018 at 9:51 AM Maciej Bylica  wrote:

> 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 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 test: Send
>> 15xOPTIONS with the same Call-ID as previously but different From-tag.
>> Result: None of the OPTIONS we’re replied.
>>
>> 3)
>> Test: Test 2 was re-run after a while
>> Result: All OPTIONS were replied
>>
>> So it seems Cisco records the Call-ID and From-tag somewhere in memory
>> and drops subsequent OPTIONS with the same Call-ID and different From-tag
>> that come from the same endpoint for some time.
>>
>> I have similar situation here.
>> The customer we are trying to connect sends several OPTIONS within
>> miliseconds.
>> First OPTIONS is replied properly, but subsequent packets with the same
>> Call-ID and different From-tag dropped.
>>
>> Is there any solution for this.
>> Our customer is very reluctant to proceed with any changes (another open
>> source SIP proxies replies all the OPTIONS).
>>
>> Thanks
>> Maciej.
>>
>> wt., 9 paź 2018 o 23:45 Anthony Holloway 
>> napisał(a):
>>
>>> 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 <
 avholloway+cisco-v...@gmail.com> 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:
>>

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

2018-10-11 Thread Maciej Bylica

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 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 test: Send
> 15xOPTIONS with the same Call-ID as previously but different From-tag.
> Result: None of the OPTIONS we’re replied.
>
> 3)
> Test: Test 2 was re-run after a while
> Result: All OPTIONS were replied
>
> So it seems Cisco records the Call-ID and From-tag somewhere in memory and
> drops subsequent OPTIONS with the same Call-ID and different From-tag that
> come from the same endpoint for some time.
>
> I have similar situation here.
> The customer we are trying to connect sends several OPTIONS within
> miliseconds.
> First OPTIONS is replied properly, but subsequent packets with the same
> Call-ID and different From-tag dropped.
>
> Is there any solution for this.
> Our customer is very reluctant to proceed with any changes (another open
> source SIP proxies replies all the OPTIONS).
>
> Thanks
> Maciej.
>
> wt., 9 paź 2018 o 23:45 Anthony Holloway 
> napisał(a):
>
>> 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 <
>>> avholloway+cisco-v...@gmail.com> 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:
>

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

2018-10-10 Thread Maciej Bylica

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 test: Send
15xOPTIONS with the same Call-ID as previously but different From-tag.
Result: None of the OPTIONS we’re replied.

3)
Test: Test 2 was re-run after a while
Result: All OPTIONS were replied

So it seems Cisco records the Call-ID and From-tag somewhere in memory and
drops subsequent OPTIONS with the same Call-ID and different From-tag that
come from the same endpoint for some time.

I have similar situation here.
The customer we are trying to connect sends several OPTIONS within
miliseconds.
First OPTIONS is replied properly, but subsequent packets with the same
Call-ID and different From-tag dropped.

Is there any solution for this.
Our customer is very reluctant to proceed with any changes (another open
source SIP proxies replies all the OPTIONS).

Thanks
Maciej.

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

> 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:

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] 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.

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

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:

[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] SIP OPTIONS pings are blocked on Cisco CUBE 3945E - Resource failure, dropping OPTIONS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16 matches

Site Navigation

Mail list logo

Footer information