Hi All,
thanks ! Got it. We already have acl matching tcp 5060 and udp 5060. TLS is
not used in our environment so tcp 5061 is not included.
Looks like they will need to investigate on the CAC as we place signaling
and voice into the same queue. ( Only 5 class of service in WAN)
On Tue, Aug 29
I should have also mentioned that interface binding is very important not
only from where you'll source your OPTIONS messages, but also from where
you'll reply to them. I've seen the layer 4 and down be correct due to
where the OPTIONS was received, but then layer 5 was displaying a different
IP a
1) It's a SIP Message, specifically the OPTIONS message
2) Typically you only prioritize voice traffic and not signaling, but you
should still reserve bandwidth for signaling to ensure it's not starved.
CUBE marks all signaling traffic as AF31 by default, but CS3 is the newer
standard to go with.
Just to clarify, UDP is default in CUBE and TCP is default in CUCM.
Actually, we should further clarify that by saying, these are the default
transport protocols for SIP UAC messages. If either product were to
receive either UDP or TCP, it will respond with the same transport
protocol. I.e., It
Why does your example have options ping on an incoming dial-peer? Since
there is no peer address configured, ping wont actually do anything.
Also, most carriers will required UDP, which is what CUBE does by default.
On Sun, Aug 27, 2017 at 10:20 PM saranyan k wrote:
> Hi Ki Wi,
>
> OPTIONS pin
The OPTIONS Ping will come across in the regular SIP stack (TCP:5060/TCP:5061
or UDP:5060 typically). Prioritization is a Quality of Service technique and
not an Access Control technique. I don't think a standard ACL would look at the
application layer header to differentiate SIP messages and of
Hi Saranyan,
thanks! I would like to know how can I compose an access-list to detect SIP
option ping and prioritize it.
On Mon, Aug 28, 2017 at 11:20 AM, saranyan k wrote:
> Hi Ki Wi,
>
> OPTIONS ping is a SIP message. Ideally the transport mode of the message
> is TCP or UDP based on the con
Hi Ki Wi,
OPTIONS ping is a SIP message. Ideally the transport mode of the message is
TCP or UDP based on the configuration done under voice service voip -> sip.
Otherwise, we can configure a keepalive profile so that we can specify the
mode of transport for the OPTIONS keepalive messages.
!
voi
Hi Group,
I would like to find out if SIP option ping is a "ping" or a "sip message" ?
>From the documents, it seems like it is a sip messages.
My customer is facing issue with the dial-peers getting busy out during WAN
congestion. We would like to prioritize those messages as a WAN
provider but
