|
Thanks 
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
You're welcome.
|
|
|
|
|
Hi @ all,
i´m trying to send an RTP Packet to a Server. My Packet Structure looks like this:
struct rtppacket
{
unsigned int version:2;
unsigned int padding:1;
unsigned int extension:1;
unsigned int csrcccount:4;
unsigned int marker:1;
unsigned int payloadtype:7;
unsigned int sequencenumber:16;
u_int32_t timestamp;
u_int32_t ssrc;
u_int32_t csrc[1];
void* datap;
int datalen;
};
that´s my way to fill and send the structure:
m_rtpPack.version = 2;
m_rtpPack.sequencenumber = 1;
m_rtpPack.csrc[0] = 0;
m_rtpPack.csrcccount = 0;
m_rtpPack.extension = 0;
m_rtpPack.marker = 1;
m_rtpPack.payloadtype = 0;
m_rtpPack.padding = 0;
m_rtpPack.ssrc = 0;
m_rtpPack.timestamp = GetTickCount();
...
...
m_rtpPack.datap = szBuffer;
m_rtpPack.datalen = sizeof(szBuffer);
nSend = sendto(m_Socket, (char*)&m_rtpPack, sizeof(m_rtpPack), 0, (SOCKADDR*)&m_saRemote, sizeof(SOCKADDR));
That doesn´t work. If I take a look of the RTP flow with packetyzer it can read the header information of rtp and the server can´t do something with incoming.
The structure padding compiler option is Zp1. What I do false?
Greetzs
Crazydogg
|
|
|
|
|
The problem is that you will send the pointer to the data (datap) and not the data itself. A pointer is 4 bytes (depending on the platform) that points to the data. Thus, when you send your structure, you will send the header correctly but for the data, you will send only the 4 bytes of the pointer. Same problem with calculating the size of the structure: it is always the same, no matter how large the buffer is (its not in the structure, it is only pointed by a member of your struct).
To fix the problem, you need to send it separateley: first the structure, as you already did (don't care about the data pointer yet), then the data buffer. On the receiver side, when you receive the data, you create a new buffer (in datap) and copy the data in it.
|
|
|
|
|
Ok I understand the problem, but I can´t influence the server side. It´s an extern Asterisk server. Because of that I have to send header and data together.
|
|
|
|
|
Is the buffer a fixed size buffer (e.g. always 1024 bytes) ?
If yes, then simply declare the buffer inside the structure:
struct MyStruct
{
...
...
unsigned char datap[1024];
...
};
|
|
|
|
|
The buffer is smaller in most cases but maximum is 1024.
I will try it so. Thank you
|
|
|
|
|
It also depends of what the serve epxects. But as the datasize field is after the data, it probably means that the server always expects 1024 bytes because it is impossible for it to know where the data field stops and where the datasize field starts.
|
|
|
|
|
So i´ve tried it as talk about. It doesn´t work too.
Is there yet another way to create this packet with header information and data?
|
|
|
|
|
CrazyDogg wrote: So i´ve tried it as talk about. It doesn´t work too.
What do you mean by doesn't work ?
|
|
|
|
|
I mean it´s the same problem as before.
|
|
|
|
|
What is the server expecting exactly ?
Post also some code of what you are doing now.
|
|
|
|
|
The Server expect a RTP Packet with RTP header information and data of payload type 0 also audio sample in uLaw Format.
All what I do now is that i´ve changed in structure from void* pData to char pData[1024]. Nothing else like before.
|
|
|
|
|
You can't just change the structure size and expect
it to work, especially if you can't alter the server code.
The server is expecting a certain number of bytes.
Also, RTP integer fields are supposed to be in network byte order
AFAIK, unless you're using your own version of RTP.
Besides fixing the pointer problem already discussed,
you need to fix your code so it implements the protocol
the server is expecting.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi Mark,
you´re right with the network byte order. The server expect in BIG ENDIAN and my was for LITTLE ENDIAN.
Now it works correctly. Thanks a lot.
|
|
|
|
|
|
did you put file.c in another directory than the one having your own sources ?
this error message is typical of when the compiler doesn't find the implementation of something (function, class, macro, ...) used elsewhere.
|
|
|
|
|
|
Chesnokov Yuriy wrote: You can not use C functions in non static MFC application functions
nowhere in the original question was mentionned that the C function was static ! 
|
|
|
|
|
As far as I know (I'm not a C expert), if you declare a C function static, its scope will be limited to the file in which it has been defined. So, you can't use it from another file.
Why do you need to have it static ?
Chesnokov Yuriy wrote: static BOOL CSomeDlg::OnInitDialog() //can not be static
{
//...
}
You can't declare OnInitDialog as static: it is implemented from the base CDlg class. A static member function means that the function doesn't not belong to a particular instance of the class (so you can access it using the :: operator: CSomeDlg::MyFunction() ).
|
|
|
|
|
Chesnokov Yuriy wrote: You can not use C functions in non static MFC application functions
That's very much incorrect.
You're basically making a statement saying "it's impossible to call Win32 API functions from non-static MFC class member functions".
The most common mistake when you get this linker error is that you're not compiling the source file with the definition of the function. It may be declared several times, but the linker could not find the implementation of it.
Which brings us back to Naveen's question: did you include the implementation file in the project? Is it the right file? Is it marked to be excluded from the build?
Chesnokov Yuriy wrote:
SomeDlg.h
static void function()
{
somefunction();
}
This doesn't prove anything. The "function" may not be called so the linker won't bother if it cannot find the implementation of it.
When you provide source code, please put your code snippets inside the <pre></pre> tags.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
|
Are you the one who's down-voting everyone on this thread? If yes, that is not at all nice of you. I can almost say that for sure by looking at the vote weightage. These people here are trying to help you and you respond to them by marking their replies as "unhelpful"? 
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
|
Actually, *you* are rubbishing the thread with your ugly votes. Everything looks gray.
If you don't care much about it, what makes you go out of your way to one vote every message on the thread? You have one-voted even those posts where people were discussing among themselves and not talking to you.
Your behavior is very amateurish, and most of all, the thread looks UGLY because of your votes. Not that I care for any low vote where there is no justification or feedback provided on 'why' it was done so.
I need not mention that people providing you with the right answer WILL depend on how well you explain your problem too.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
