Hi Nikos, Since it sounds like you're more concerned with building something useful in vhdl rather than fully supporting SIP, I would recommend installing a SIP softphone on your computer and capture the packets of an outbound INVITE dialog and an inbound INVITE dialog with something like Wireshark. Once you see how the basics work in the real world then start reading rfc 3261 to learn a bit more about the details of the parts of SIP you're interested in. The main thing you must understand in order to get going are the require headers for the types of requests and responses you're going to support. You'll at the very least want to be able to support INVITE, ACK, BYE, CANCEL, 100, 180, 200, 4XX/5XX/6XX (you could treat all 4XX, 5XX, and 6XX responses as the same thing to make life easy, though a commercial product cannot).
You say you have a parser extracting the headers with their values. I'm guessing the parser is not actually parsing the different kinds of values correctly, like the parts of a URI or name-addr right? To have something that will really work you're going to need to do that. However, if you just want to get by, you could respond to any request URI as if it is valid. If you can't parse the value in a Contact header you might be able to get away with assuming the remote device can be contacted at the same ip and port as the source of the packet. If you need to send a BYE you could copy the value in between the angular brackets < > of the Contact header to use as your Request-URI in your BYE request. As for timers you can probably skip those as chances are you don't care about loosing packets. At some point you're going to need to handle SDP and RTP. If I were you, I'd stick with g711u/PCMU as it's fairly simple to transcode to PCM. If you need to handle DTMF, I would recommend you use SIP INFO or transmit your tones inband as audio in your PCMU payload as since you're just using hardware tone detection will actually be easier for you to do rather than something like RTP events (rfc 4733). Now please remember everything I've said above is NOT how one would go about building a real SIP device that adheres to the standards. Also if you need more specific help please be sure to specify exactly what are you need help in. Your questions so far have been fairly general so I assumed that's the sort of answer you're looking for. If I was completely wrong and you do want to adhere to the standards then the best route is to forget everything I've said, get yourself a lot of coffee, and completely read rfc 3261. Good luck, Brandon On 03/18/2012 12:36 PM, Nikos Tzanis wrote: > On 17/3/2012 8:00 μμ, Paul Kyzivat wrote: > >> Nikos, >> >> Following on to what has been said... >> >> Typically one would not set out to solve a problem in hardware unless >> there has been a demonstrated problem solving it in software. And, as >> Brandon says, you can't realistically expect to do the *whole* job in >> hw, so you will need something that can host the software part. So >> really you are talking about building a hw accelerator for a sw >> implementation. >> >> So, I would recommend looking around for a suitable sw implementation, >> and then study what could be accelerated. This probably makes no sense >> at all in a single user endpoint. There *might* be something to gain in >> a server, such as an SBC. >> >> Good luck, >> Paul >> >> On 3/17/12 12:31 PM, Brandon W. Yuille wrote: >> >>> The biggest problem I foresee is that you're trying to do something in >>> hardware which is normally done in software. With Nataraju's list I >>> would say the only point you can realistically accomplish in hardware >>> would be point 1. He also forgot to mention you'll need to handle >>> potentially the Ethernet MAC layer (must be hardware), IP/ARP, and UDP >>> transport which all could be done in hardware. With everything else >>> you're probably going to need to implement a soft core or use an >>> external cpu. Without one, you'd be attempting a monolithic problem that >>> most likely couldn't be built in under a year. So if you end up using a >>> cpu you may as well do all the protocol layers in software along with >>> the parsing to make your task easy. >>> >>> Good luck, >>> Brandon >>> >>> On 03/17/2012 08:51 AM, Nataraju A.B wrote: >>> >>>> Tzanis, >>>> >>>> Simplest proposition would be to use the bottom-up approach. >>>> >>>> start with >>>> 1. Parser (encode/decoder) module >>>> 2. Transaction module (initially you design this module one for UA >>>> only, exclude proxy specific >>>> processing to start with - for simplicity only) >>>> 3. Dialog module >>>> 4. Session module >>>> 5. Some application on top of SIP. >>>> >>>> One more suggestion would be to go through the OSIP / asterisk / others... >>>> First you understand the basics, then you can proceed with VHDL based >>>> implementation... >>>> >>>> hope this helps... >>>> >>>> Thanks, >>>> Nataraju A B >>>> >>>> 2012/3/17 νικος τζανης<[email protected]> >>>> >>>> >>>> >>>>> Hello , I am a student and i was asked to implement sip in fpga . I have >>>>> studied the rfc 3261 but i dont know where to start from .Sip is a >>>>> transaction based protocol . Do you have any idea on how to do this thing? >>>>> I have found system offload engine (SOE) implementations but i want to >>>>> implement the whole transition model in vhld . Any help would be >>>>> appreciated . >>>>> >>>>> >>>>> Nikos Tzanis >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> [email protected] >>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > First of all thank you for the quick replies .I want you to know that I > m not trying to implement a commercial porduct but to go as far as i can > for educational reasons. So a simple model with them main features of > SIP would be ok . The first module(parser) is almost ready .When a > message arrive , i can find all the header-header value pairs and save > it in memory . Where a cpu could easilly find them . Surely a cpu is > needed , but if i could create standard messages too(with the minimum > fields required. To,From,Cseq,Call-id,Max Forward,Via . ) . I mean if > hardware could find these stored values and send the message ? But how > to go from the simple transaction model to vhld???where can i find the > techniques? > > thanks a lot once more > Nikos Tzanis > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
