# RAW source **URL:** \ **Category:** GNU Radio\ **Created:** [June 19, 2014, 1:55pm UTC](https://www.ruby-forum.com/t/raw-source/230476 "2014-06-19T13:55:41Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\ **Post date:** [June 19, 2014, 1:55pm UTC](https://www.ruby-forum.com/t/raw-source/230476/1 "2014-06-19T13:55:41Z")
Hi, I want to capture packets coming from Twinkle Soft phone in gnuradio, these packet are RTP packets . But in gnuradio , there is only UDP or TCP source ! I can’t find Raw source to correspond to the RTP packets. Is there an alternative to RAW source in GNUradio ? Thanks. ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 2:12pm UTC](https://www.ruby-forum.com/t/raw-source/230476/2 "2014-06-19T14:12:21Z")
On 06/19/2014 07:54 AM, Sara C. wrote: > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > RTP is usually carried over UDP ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 2:44pm UTC](https://www.ruby-forum.com/t/raw-source/230476/3 "2014-06-19T14:44:26Z")
On Thu, Jun 19, 2014 at 8:11 PM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > RTP is usually carried over UDP Just to be more detailed, RTP is a Session Layer (OSI Layer 5) protocol [1] that lies on top of UDP (an OSI Layer 4 protocol). 1. [OSI model - Wikipedia](http://en.wikipedia.org/wiki/OSI_model) ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 2:34pm UTC](https://www.ruby-forum.com/t/raw-source/230476/4 "2014-06-19T14:34:20Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sara, RTP is a complex networking protocol, so you will have to write a decoder for this, and also for the numerous audio formats that may be contained within, if you want GNU Radio to actually do something with the speech within. If you only want to look at the packets as bytes of payload, as Marcus said, just use a UDP source. GNU Radio is about signal processing much more than about application-specific protocol decoding; both problems are fundamentally different. Given the “modern” PDU capabilities, decoding network protocol data is not entirely impossible, but it’s still cumbersome. Allow me a comparison: decoding an RTP stream including the numerous audio payloads that might be contained using GNU Radio is comparably elegant as demodulating FM radio with a webserver. But: there are numerous open source RTP decoder libraries available, and that’s what twinklephone uses to decode the packets. I think the right thing to do is use a library which decodes RTP and the contained compressed audio and gives you PCM samples, and feed this sample stream into GNU Radio. This could be done inside a GNU Radio block, but I think it would be easier to just use an external executable and let that stream audio into your flowgraph, for example using a UDP or TCP socket, or a named pipe. Considering that, with some ALSA hackery, you can have a loopback audio device, you could even just use the soft phone of your choice to generate audio samples that you capture using the GNU Radio audio source. Greetings, Marcus On 19.06.2014 14:11, Marcus D. Leech wrote: > > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > > RTP is usually carried over UDP > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Discuss-gnuradio > mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJToth9AAoJEBQ6EdjyzlHtlkYH/3L15S8wnBoq4rtE4woyhiGB 6GebGSmhb2co2I2yy3eFil0FITdDgamZDhv2S1TAe2Hk5O0hNUAQ6MJ1XO8p5G4X zwMdmJ4RwV3owaG59Cf3wWl9gWilOY65blk3DVcek0Q6/fMg42peNrHheEDZmZAo Zk3QbWmkRImgiYM3od1Jg4+Ho5S4LLGJVUzCIIEHC5qWTHt25Pq8803cvscaRvVE LLmtXj1GFofatOPbR6520zNMhObpknWvqfVyvFlUWSOlpTN0FR3nO/KJeXxsGVq+ 3UMVcZpU9tk2RRj/UoYDqppK2eDp3VvV4HCsbVt5zJq8xxbuVGEotn1P8XTsHOo= =4etW -----END PGP SIGNATURE----- ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 3:34pm UTC](https://www.ruby-forum.com/t/raw-source/230476/5 "2014-06-19T15:34:18Z")
Sorry , I forgot to say that some packets coming from Twinkle are SIP & ARP packets not only RTP. Hence , I think I need to receive RAW packets in GNU Radio ( as I have different type of packets: RTP , ARP , SIP packets) Note that : I use 4 laps & 2 USRPs. 1st & 4th lap has twinkle softphone & I will make a call between them. 2nd lap has an OFDM TX implemented by Gnuradio. 3rd lap has an OFDM RX implemented by Gnuradio. First and 2nd laps are connected by Ethernet cable. 3rd & 4th laps are connected by Ethernet cable. One USRP is connected to the 2nd lap , the other USRP is connected to the 3rd lap. 2nd lap(GNUradio ,ofdm tx) will receive the packets from 1st lap(Twinkle) using RAW socket (as I think ) . 2nd lap will send the packets to the 3rd lap by the USRPs. 3rd lap ( Gnuradio , ofdm rx) will send real time voice packets to 4th lap (Twinkle) using RAW socket(as I think). If I want only to make a call & send and receive the voip real time packets , Do I have then to write a specific block as this mentioned decoder ? Thanks in Advance. 2014-06-19 15:33 GMT+03:00 Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 4:14pm UTC](https://www.ruby-forum.com/t/raw-source/230476/6 "2014-06-19T16:14:07Z")
Hi Sara, in the stack of usual VoIP systems, there is no such thing as a “RAW” package. What you seem to want is the common transport layer for ARP, SIP and RTP to go over the air. I’m not really sure why you would want ARP, as that is something two VoIP devices usually can’t communicate over (because it’s one layer under the internet layer, and basically only exists for local networks); ARP is only necessary when you want to know the ethernet MAC address belonging to an IP address, which you don’t need to do in your case; just tell your routing table that packets for that other IP address have to go over your wireless link… Aside from ARP, the common layer would be IP. Problem here is that all of your protocols are two-way protocols: you cannot just send packets in one direction and hope everything will work, there has to be some back channel. How would your TX soft phone know the other end picked up your call? So what you must do is two-fold: 1. Implement a link-layer, and instruct your operating system to transport the IP pakets over that and 2. implement a back channel. Notes: 2.: this might need another OFDM channel in the opposite direction, or, with some firewall/ low level routing magic, another ethernet link, just used for the back channel. 1.: there’s still gr-digital/examples/ofdm/tunnel.py from the “old” OFDM framework, which has become somewhat infamous 🙂 but looking at that code, you should be able to figure out how to use your OFDM implementation with TUN/TAP devices. Also look at gr-ieee802-11, which _is_ a working OFDM layer with a TAP (that’s ethernet layer) device interface. Greetings, Marcus On 19.06.2014 15:32, Sara Ch?rif wrote: > First and 2nd laps are connected by Ethernet cable. > 3rd & 4th laps are connected by Ethernet cable. > One USRP is connected to the 2nd lap , the other USRP is connected to the > 3rd lap. > 2nd lap(GNUradio ,ofdm tx) will receive the packets from 1st lap(Twinkle) > using RAW socket (as I think ) . > 2nd lap will send the packets to the 3rd lap by the USRPs. > 3rd lap ( Gnuradio , ofdm rx) will send real time voice packets to > 4th lap > (Twinkle) using RAW socket(as I think). > > If I want only to make a call & send and receive the voip real time > packets ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 19, 2014, 3:43pm UTC](https://www.ruby-forum.com/t/raw-source/230476/7 "2014-06-19T15:43:13Z")
On 06/19/2014 09:32 AM, Sara Chérif wrote: > Sorry , I forgot to say that some packets coming from Twinkle are SIP > & ARP packets not only RTP. > Hence , I think I need to receive RAW packets in GNU Radio ( as I have > different type of packets: RTP , ARP , SIP packets) The thing is, Gnu Radio is largely about the _PHY_ layer in the protocol stack (I say “largely” because it takes excursions into non-PHY territory from time to time). The key point is that Gnu Radio _isn’t_ about packet-decoding and related machinery, but rather about _signal processing_. Granted, the “end game” of that signal processing often ends up in packetized bits, but Gnu Radio isn’t about the semantic “meaning” of those bits–it’s up to other bits and pieces to make sense of that. For example, if you implemented an 802.11 “stack”, you’d (on the receive side) inject the demodulated (and framed) bits into a virtual network interface in your operating system, which would treat them like any other bits arriving from a network interface. ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 21, 2014, 1:33pm UTC](https://www.ruby-forum.com/t/raw-source/230476/8 "2014-06-21T13:33:35Z")
Thanks Marcus Müller , Marcus D. Leech , Activecat. yes , we can call this "Ethernet to wireless bridge using GSM RF channel ". I have some questions, please : 1- Can I use both UDP source & TCP source in this way : Can I connect output of" UDP source" & output of “TCP source” to input of "Socket PDU " and connect output of "Socket PDU " to the input of the "PDU to tagged stream " block ? What is wrong in this connection ? 2- But when I connect the output of TCP or UDP source to the Socket PDU , I got an error ! what does the Socket PDU block take as an input?! 3- Also when I connect output of “TCP or UDP source” to "PDU to tagged stream " I got an error , what must be the input of the PDU to tagged stream block ?! Does the "PDU to tagged stream " is used here instead of the “stream to tagged stream” block and has same role? 4- Does the block " Socket PDU" can be used instead of a socket ? It don’t understand what is the importance of this block ? 5- Is there any flags so that when signaling packets are coming (SIP or ARP) : TCP source is enabled while UDP source is disabled ? And the inverse happens when there is RTP packets coming? Note that , in network settings in Twinkle soft phone , there is a port number for RTP different from port number of SIP & we can change these ports numbers , I don’t know if this may help me . 6- Do I have to write a code for socket ?or simply I can write ,in the “UDP source” block in Gnu radio(2nd lap) , the IP address & port number of the Ethernet connection (of 2nd lap) receiving from Twinkle(1st lap) ? 7- If there is no new packets coming , I want to send zeros instead of repeating the sent packets ? How Can I do this ? i.e: I want to insert 8 bits zeros after each ofdm symbol as a guard band : I tried to insert " pad source " block to do this , after the IFFT block and before the cyclic prefixer block , but it is not allowed to connect 2 inputs to the cyclic prefixer also I don’t know how to use the pad source to insert these zeros & I don’t know if there is a block to concatenate between the zeros coming from the pad source & the output of the ifft block . Thanks in advance . 2014-06-20 7:42 GMT+03:00 Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 20, 2014, 6:44am UTC](https://www.ruby-forum.com/t/raw-source/230476/9 "2014-06-20T06:44:51Z")
On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > First and 2nd laps are connected by Ethernet cable. > 3rd & 4th laps are connected by Ethernet cable. > One USRP is connected to the 2nd lap , the other USRP is connected to the > 3rd lap. > 2nd lap(GNUradio ,ofdm tx) will receive the packets from 1st lap(Twinkle) > using RAW socket (as I think ) . > 2nd lap will send the packets to the 3rd lap by the USRPs. > 3rd lap ( Gnuradio , ofdm rx) will send real time voice packets to 4th > lap (Twinkle) using RAW socket(as I think). Hi Sara, What you need is only a wireless bridge. A wireless bridge allows you to connect one network (1st and 2nd lap) to another (3rd and 4th lap) over the airwaves (which is USRP-to-USRP), rather than having to run wire from one room (2nd lap) to another (3rd lap). I would say you only need to work at the OSI layer 1 (physical layer). In this case you can ignore the UDP, RTP etc as far as gnuradio is concerned. In alternative you may implement the wireless bridge using 802.11, but it is not mandatory for you to work at OSI layer 2. So you may rephrase your question as “how to build wireless bridge using USRPs ?” Then you may want to work in either transparent “repeater” mode or “bridge” mode. In either case you don’t need to work at layer 3 or above. The basic requirements are just that, you need the USRPs to setup wireless link at full-duplex, and make sure the bandwidth of the wireless channel is sufficient for few concurrent VoIP calls. Anyway, I may be wrong. ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 21, 2014, 6:45pm UTC](https://www.ruby-forum.com/t/raw-source/230476/10 "2014-06-21T18:45:52Z")
On Sat, Jun 21, 2014 at 7:31 PM, Sara Chérif [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 2- But when I connect the output of TCP or UDP source to the Socket PDU , > > Thanks in advance . Looking at above questions, you doesn’t seem to understand OSI 7 layers model. You said this is a “wireless bridge”. If you have decided to have gnuradio (with USRPs) working at layer 2, then you no longer need to consider TCP, UDP, RTP etc. Even if you decided to have gnuradio working at layer 3, you also no need to handle TCP, UDP, RTP etc. If you want to have gnuradio (with USRPs) working at layer 7, then you this will be very complicated and the resulting setup will be very application specific, i.e. you will need to handle each application one by one. This approach is unnecessarily complicated and hence not recommended. An analogue to this: Says, now you have a PC that you want to connect to internet. In another room you have a DSL router which is already connected to internet. Currently the PC has no connection to the DSL router, it is standalone. To connect the PC to the DSL router, you have few options: Option 1: Use Ethernet Extender The Externet Extender do not need to understand any IP address, TCP, UDP, HTTP etc. In this case the Ethernet Extender is working at OSI layer 1. The Ethernet Extender doesn’t even need to care about the MAC address, right ? Option 2: Use a bridge The bridge need a MAC address but does not need any IP address. It will perform packet switching based on MAC addresses. It doesn’t need to look at the IP addresses of the packets, no need to talk about the TCP, HTML etc. In this case the bridge is working at OSI layer 2. Option 3: Use a router If the IP address of your PC is in different subnet from the Ethernet port of the DSL router, then you need put another router between the PC and the DSL router. The default gateway of the PC is pointing to the interconnecting router. In this case the router is working at OSI layer 3. The router doesn’t need to understand any HTTP protocol, right? Option 4: Use a proxy server The HTTP proxy server needs to understand HTTP traffic, know the contents of each website etc in order to perform filtering and caching. In this case the proxy server is working at OSI layer 7. Now let’s come back to your question. As you already decided to have gnuradio working at layer 2, why you still need to care about the UDP, TCP, RTP etc ? ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 22, 2014, 5:01pm UTC](https://www.ruby-forum.com/t/raw-source/230476/11 "2014-06-22T17:01:39Z")
Thanks very much Activecat I have some last questions please : 1- Does the block " Socket PDU" can be used instead of a socket ? It don’t understand what is the importance of this block ? what does it take as input ? I know it takes “Pdus”= "Async message " but also I don’t understand what is the block that must precedes the socket PDU. 2- Do I have to write a code for socket ?or simply I can write ,in the “UDP source” block in Gnu radio(2nd lap) , the IP address & port number of the Ethernet connection (of 2nd lap) receiving from Twinkle(1st lap) ? Or the UDP source is an interface to socket and So there must exist an external code of socket ? Thanks in advance 2014-06-21 19:43 GMT+03:00 Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 22, 2014, 5:29pm UTC](https://www.ruby-forum.com/t/raw-source/230476/12 "2014-06-22T17:29:35Z")
Hi Sara, This is all a little much to explain in Email form properly. PDUs are a concept from the packet network world. GNU Radio realizes this by using a combination of asynchronous messages and tagged streams, which is basically a contract that blocks consume /exactly/ one “chunk” of samples at a time, which boundaries are set using tags[1]. If Socket PDU is helpful is something we can’t answer, because this is your application, and we don’t know how that works. It takes network packets and generates messages, and takes messages and generates network packages. I think it could use some more documentation, but the source code should give you a good idea of what’s happening, if you know how to use message port and TCP and UDP sockets. Still, I think you need to get a firmer grip on what _your_ specific setup requires from a computer network point of view. As Activecat, Marcus L. and I already tried to point out is that you might not want to care about your IP packet content _at all_, and simply want to construct an IP Layer Bridge. That cannot be done simply by using the UDP source. You’ll need to learn some things about how lower level networking works, though, to write the software needed to bridge two networks over a wireless link. That’s why I pointed you to the tunnel.py script to analyze and understand what’s going on. This will include the need to learn quite a bit about IP network and linux kernel network interfaces, but I think that’s a burden that the mailing list can’t take of you. In the end, you are in the process of engineering a radio communication device for network data, so you’ll have to be friendly with all the concepts involved. I hope this cleared up a bit of confusion and was helpful, Greetings, Marcus [1] [http://gnuradio.org/doc/doxygen/page\_tagged\_stream\_blocks.html](http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html) ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 24, 2014, 7:07am UTC](https://www.ruby-forum.com/t/raw-source/230476/13 "2014-06-24T07:07:26Z")
On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > First and 2nd laps are connected by Ethernet cable. > packets , Do I have then to write a specific block as this mentioned > decoder ? > > Thanks in Advance. Hi Sara, After few rounds of communications, apparently you are interested to intercept the VoIP session at OSI layer 5 or above (eg. RTP session), and you try to use gnuradio (with USRPs) to accomplish that. Probably this is because your area of interest is actually those RTP and VoIP stuffs. I have few highlights: 1). To accomplish this, one of the right ways is to make your PC becomes one of the VoIP endpoints. In this case you listen to the speaker and speak to microphone attached to your PC. At the other end of the session is a SIP phone. With this, you really dig into the RTP and VoIP stuffs. You need neither gnuradio nor USRP. In this case the wireless link is trivial in your setup. 2). In this case you need ASIO [1] or something similar, and start working from the low level. But as ASIO may not sound as an easy topic, you are looking for tools like gnuradio to abstract the low level stuff. Yes gnuradio has built-in blocks that abstract ASIO, but that abstraction doesn’t mean to let you work at RTP layer. 3). In this case the gnuradio is not the right tool for your purpose. You had chosen the tool without first qualifying it. Your setup above (with the 4 laps) couldn’t actually force gnuradio to intercept the VoIP session at RTP layer. This is a wrong design. Let’s be honest about your area of interest. Anyway I could be wrong. 1. [Boost.Asio](http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio.html) ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 25, 2014, 5:07am UTC](https://www.ruby-forum.com/t/raw-source/230476/14 "2014-06-25T05:07:44Z")
Thanks Activecat very much . Now, SIP packets length is varying & RTP packets have fixed length of 87 bytes . Now to input this traffic coming from the soft phone to the Gnuradio to be processed, i use the UDP source block(to read the UDP packets from the soft phone port) in UDP source block , I can determine only one port number and Ip address. I put the IP address of the Wlan interface (my laptop IP address) , i also tried to put “0.0.0.0” and the port number of twinkle soft phone on which i receive the RTP traffic. I faced some problems: First ,How to receive now the SIP signaling packets and the Rtp packets at the same time to establish a call with another soft phone ( as the soft phone uses 2 different port numbers for sip & RTP while i have to identify only one port number in the UDP source block)?? The flow graph i use consists of :Udp source - throttle -Uchar to float and WX GUI sink scope. I tried to duplicate the flow graph (to use another one which is the same as above and runs in parallel ) Also I tried to use 2 UDP source block then the add block. But I don’t know till now how to multiplexes the two traffics (SIP and RTP) as we need to integrate the whole system to see this & what is the right method ? DO I have to write simply the port of the ethernet connection ? What will I do in this case : If I want to make the call between the 1st & 2nd lap ( One has Twinkle & the other has GNU Radio & Twinkle, and I want GNU Radio to capture packets coming to Twinkle ? (use 2 udp source + add block ) ? Second, i don’t know how to determine the payload size. what if the packet length in the case of the Sip signaling is variant. In the soft phone, we can determine the maximum transfer unit (MTU), does this help here ? Third, i have a question relating to the OFDM transmitter: what is the required packet length , I wrote it 100 as each sip packet is 87 bytes and I will use coding with rate 7/8 then after coding each packet is 100 bytes) what if the packet length is variable as in the case i stated above (SIP pkt length is not constant)? Note: i want to capture the packets coming from the soft phone in order to process them on gnuradio using OFDM system and send and receive them at the other end using two Usrps to be used as input to the other soft phone. Thanks in advance 2014-06-24 8:05 GMT+03:00 Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 25, 2014, 4:16pm UTC](https://www.ruby-forum.com/t/raw-source/230476/15 "2014-06-25T16:16:13Z")
On Tue, Jun 24, 2014 at 11:06 PM, Sara Chérif [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Also I tried to use 2 UDP source block then the add block. > length in the case of the Sip signaling is variant. In the soft phone, we > other end using two Usrps to be used as input to the other soft phone. > > > > First and 2nd laps are connected by Ethernet cable. > > > packets , Do I have then to write a specific block as this mentioned > > > intercept the VoIP session at OSI layer 5 or above (eg. RTP session), and > > > You need neither gnuradio nor USRP. In this case the wireless link is > > > You had chosen the tool without first qualifying it. Sara, I agree with what others have told you. GNU Radio isn’t the right place for doing what you’re trying to do. You want to do PHY (mostly) and MAC (when possible) layer stuff in GNU Radio, not network and app layer stuff. Instead, I would suggest you try out the gr-mac project: [https://github.com/jmalsbury/gr-mac](https://github.com/jmalsbury/gr-mac) This will set up a virtual tun interface you can then use to direct network traffic. You should hopefully be able to plug your RTP application into it. I hesitated a bit to suggest this. gr-mac is still a work-in-progress and probably needs a bit of hand-holding to get it set up initially. But it comes with support for both a GMSK and OFDM modem. I made it work with our new FEC blocks from gr-fec last month, too. So it’s pretty versatile and works well when you know how to work with it. Tom ---
**Author:** ![Sara\_ChSSrif](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7ba0ec/32.png) [@Sara\_ChSSrif](https://www.ruby-forum.com/u/Sara_ChSSrif)\ **Post date:** [June 25, 2014, 5:36am UTC](https://www.ruby-forum.com/t/raw-source/230476/16 "2014-06-25T05:36:53Z")
Sara, We don’t seem to communicate at the same frequency. I have nothing else to say. Good luck. On Wed, Jun 25, 2014 at 11:06 AM, Sara Chérif [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)