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

[Lelio Fulgenzi]

“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. 56354 | 
le...@uoguelph.ca

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

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 11, 2018, at 9:56 PM, Ryan Ratliff (rratliff) via cisco-voip 
mailto:cisco-voip@puck.nether.net>> wrote:

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.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/firmware/12-1-1/cs88_b_conference-8832-rn-for-12_1_1.html#concept_E6B0DE96F47A653545A3BF51ED1C1E45

You just need to get it powered up and back on the network with the ethernet 
injector or force it to boot to the alternate load (after installing a newer 
load on CUCM).

-Ryan

On Oct 9, 2018, at 3:49 PM, JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> wrote:

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 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] anonymous proximity issues?

[Lelio Fulgenzi]

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 EDUs, there’s very little segmentation when it comes to 
a student logging into wireless vs staff/faculty. Not to say all students are 
looking to cause trouble, but, well, you know.

And in today’s cubicle environment, those frequencies are reaching far outside 
the glass walls. But I’ll need to do more testing once the device is in place. 
Even a quick site survey might appease our concerns.

-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 11, 2018, at 9:50 PM, Ryan Ratliff (rratliff) 
mailto:rratl...@cisco.com>> wrote:

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 users to have control over toggling the feature take an 
example from https://github.com/CiscoDevNet/roomdevices-macros-samples and 
create a macro that works with in-room-controls to give your users a button to 
flip the config on/off.

-Ryan

On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:


Unless I am completely mistaken, it seems that proximity participation in a t/p 
session enabled for proximity is completely anonymous without acknowledgement 
from the t/p operator side of things. At least one document says that if you 
are afraid of people outside your office participating, you should disable 
proximity on your device. Wait, what?

I read somewhere where you can lower the proximity HF volume(?), but that’s 
like lowering the wifi antenna power to restrict wifi access.

I’m thinking of enabling only proximity itself and not sharing, so at least 
webex users can select the endpoint. I mean, they may call a user’s endpoint, 
but in the end, they have to accept the call. No biggie there.

But it really is a shame that there was no acknowledgement or PIN displayed, 
like on an Apple TV when you want to join the session.

Does anyone know if proximity will be PIN controlled (or anything like this) 
any time soon?

Lelio


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



___
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?

[Ryan Ratliff (rratliff) via cisco-voip]

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.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/firmware/12-1-1/cs88_b_conference-8832-rn-for-12_1_1.html#concept_E6B0DE96F47A653545A3BF51ED1C1E45

You just need to get it powered up and back on the network with the ethernet 
injector or force it to boot to the alternate load (after installing a newer 
load on CUCM).

-Ryan

On Oct 9, 2018, at 3:49 PM, JASON BURWELL 
mailto:jason.burw...@foundersfcu.com>> wrote:

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 mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] anonymous proximity issues?

[Ryan Ratliff (rratliff) via cisco-voip]

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 users to have control over toggling the feature take an 
example from https://github.com/CiscoDevNet/roomdevices-macros-samples and 
create a macro that works with in-room-controls to give your users a button to 
flip the config on/off.

-Ryan

On Oct 10, 2018, at 5:04 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:


Unless I am completely mistaken, it seems that proximity participation in a t/p 
session enabled for proximity is completely anonymous without acknowledgement 
from the t/p operator side of things. At least one document says that if you 
are afraid of people outside your office participating, you should disable 
proximity on your device. Wait, what?

I read somewhere where you can lower the proximity HF volume(?), but that’s 
like lowering the wifi antenna power to restrict wifi access.

I’m thinking of enabling only proximity itself and not sharing, so at least 
webex users can select the endpoint. I mean, they may call a user’s endpoint, 
but in the end, they have to accept the call. No biggie there.

But it really is a shame that there was no acknowledgement or PIN displayed, 
like on an Apple TV when you want to join the session.

Does anyone know if proximity will be PIN controlled (or anything like this) 
any time soon?

Lelio


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



___
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] Any Alertus integrations out there? Successful or otherwise?

[Lelio Fulgenzi]

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. Seems like quite a bit of 
work and upkeep, with lots of room for error.

It also seemed like they weren’t using the ‘superprovider’ mechanism, because 
they suggested creating a user and adding each device to the controlled devices 
section. Again, same issues as above.

The above doesn’t seem bad for a small deployment, but with over four thousand 
phones, and a model of “move your own phone”, I have a feeling groups would 
become out of sync quickly.

Feel free to respond off-line.

Lelio

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

[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

[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

[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

[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

[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

[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

[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

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