cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1591
Views
11
Helpful
25
Replies

What is the packet format of ip-sla udp-jitter voip command

eitanz
Level 1
Level 1

Hello,

I need to develop a router that will be the responder side of Cisco's IP-SLA UDP-JITTER VOIP command, can someone tell or point me to where I can find the details of the network send and reply packets format of that protocol?

Some specific questions:

What can be the length of those packets? is it always 32 bytes or can be different?

I know that one of the packet's fields is a timestamp, how does this timestamp is calculated?

Is there a difference in packet structure and values between using the control packet first to not using it?

thanks,

Eitan.

25 Replies 25

You are right I check the link you share and later I will do lab I will change the time Zone in one end and try to read it in Wiresharke. 
but again it not so simple it need more work in real network. 
I will update you soon 

BTW, that Wireshark reference is interesting.

It seems to imply Cisco has not publicly revealed all the workings of their SLA technology.

Joseph, you probably right, or Cisco may share that info only with specific vendors (like Aethra), I don't know.
Without any deeper info I will try to use the Wireshark page (and network captures) as reference for implementation..

There is another possible approach, to possibly solve your problem (which I'm not fully aware), which you might consider.

Rather than trying to get this function to work on your non-Cisco device (router?), or replace your non-Cisco device with a Cisco device, add an additional Cisco device, just for this function, "behind" your Cisco device.

Many, many years ago, I vaguely recall being involved where there was a need for us to monitor actual network performance (probably to prove the performance issue was NOT the network).  What we did was setup a very inexpensive remote Cisco router (e.g. low cost ISR 800?) on the same network as problem host(s), often with connection to same physical edge device, and monitor end-to-end using it.  (NB: the remote, inexpensive, router was only used, in this situation, as an end point for the SLA tests.)

Joseph, Thanks for the idea but its not good in my case, the router I need to implement this protocol on suppose to replace a Cisco router..

". . . router I need to implement this protocol on suppose to replace a Cisco router.."

Yea, I thought that, which, again, is why I mention using an inexpensive Cisco router (not the one you're replacing), behind the non-Cisco router. I.e. It's just another "host" behind the non-Cisco router, and not being used as a router.

That said, it's certainly more "convenient" being able to use the non-Cisco router, as a direct replacement for the Cisco router (maintaining all currently used features), without needing any other (or Cisco) hardware (but, laugh, I think that's what Cisco wants).

There are possible advantages to what I suggest are:  first, it might actually be "cheaper" in the long run (there's cost to your time to get this result); second, don't know where in the world you are, but in the USA (some other countries too?), reverse-engineering exposes you to some nasty liabilities.  (The latter, might have very low odds being applied to you, but you're creating risk.  [Possibly, some reverse-engineering liabilities is why Wireshark hasn't try to figure out more.])  Third, what if Cisco "enhances" this feature, assuming you too would like to use such an enhancement, you're back to spending your time to figure out the changes and incorporate them.

Joseph, thanks again for the thoughts and ideas but it wont work, the costumer I need this feature for looks for a replacement for Cisco which support this feature, telling him he needs to buy and use 2 boxes (which one of them is still a Cisco) instead of one will not please him at all

I truly understand.

I had about 40 years in IT, 30 of them as an independent "consultant".  I.e. high on the priority list, keeping your customers happy.

However, if I believe customer was "shooting themselves in the foot", I would explain why I thought so.  Sometimes they would change their mind.  Sometimes they wanted to continue on as they desired.  (In the latter, never felt it was my job to convince them to do something else, just my job to inform them of facts they may have not considered.  [Also, sometimes customers have a really good reason for doing what they want, but for various reasons, cannot share such with you.])

Wish you the best success, and if you can, post a follow-up how it all worked out.

Ok, I intend to try and implement the protocol with the info I currently have, hopefully it will do for the basic test the customer needs.
It might take some time but I hope to update how it worked out.

Joseph, I had some progress with this, didn't fully finish it since some other issues need my attention now, but after I implemented this protocol according to the Wireshark page and traffic capture it seems to work fine - both the control phase and the measurement phase, my side is the responder to Cisco's ip sla requests, according to Cisco ip sla statistics it seems it accepts correctly the response packets

Congratulations!!!