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.
On 06/19/2014 07:54 AM, Sara C. wrote:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
RTP is usually carried over UDP
On Thu, Jun 19, 2014 at 8:11 PM, Marcus D. Leech [email protected]
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).
-----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
RTP is usually carried over UDP_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJToth9AAoJEBQ6EdjyzlHtlkYH/3L15S8wnBoq4rtE4woyhiGB
6GebGSmhb2co2I2yy3eFil0FITdDgamZDhv2S1TAe2Hk5O0hNUAQ6MJ1XO8p5G4X
zwMdmJ4RwV3owaG59Cf3wWl9gWilOY65blk3DVcek0Q6/fMg42peNrHheEDZmZAo
Zk3QbWmkRImgiYM3od1Jg4+Ho5S4LLGJVUzCIIEHC5qWTHt25Pq8803cvscaRvVE
LLmtXj1GFofatOPbR6520zNMhObpknWvqfVyvFlUWSOlpTN0FR3nO/KJeXxsGVq+
3UMVcZpU9tk2RRj/UoYDqppK2eDp3VvV4HCsbVt5zJq8xxbuVGEotn1P8XTsHOo=
=4etW
-----END PGP SIGNATURE-----
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 [email protected]:
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:
- Implement a link-layer, and instruct your operating system to
transport the IP pakets over that and - 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
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.
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 [email protected]:
On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif [email protected]
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.
On Sat, Jun 21, 2014 at 7:31 PM, Sara Chérif [email protected]
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 ?
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 [email protected]:
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
On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif [email protected]
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.
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 [email protected]:
On Tue, Jun 24, 2014 at 11:06 PM, Sara Chérif [email protected]
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
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
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 [email protected]