| Author |
|
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: February 26 2009 at 12:11pm | IP Logged
|
|
|
Hi Randal:
I take RTP callback scheme provided by media engine to perform RTP en/decryption which takes same XOR algorithm. Encryption is ok, but decryption fails. when media engine receives encrypted RTP packet from network, how to figure out packet length? Is variant length of encrypted RTP packet indicated by struct RAW_RTP_DATA member RtpPacketLengthInBytes? Even when I use this member with pRtpHeader to perform decryption, no incoming voice can be heard, i.e. one-way conversation. Thus I conclude that any encrypted RTP packet has not been decoded into original RTP traffic successfully.
In order to troubleshoot root cause, I refer to single line phone example source code for my doubt. I found that its decoding code does not use member RtpPacketLengthInBytes for decryption. Why?
How to move ahead?
George
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: February 26 2009 at 12:17pm | IP Logged
|
|
|
Hi Randal:
My own source code is as follows for your reference.
Code:
void __stdcall RawRtpCallback(RAW_RTP_DATA *pRawRtpData)
{
CPhoneBase *pCPhoneBase;
unsigned int nRtpLength;
// access the instance data.
pCPhoneBase = (CPhoneBase *)pRawRtpData->pUserData;
if(PhoneBaseSettings.RtpEncodingType == 0)
{
// no RTP encryption.
}
else if(PhoneBaseSettings.RtpEncodingType == 1)
{
if(pRawRtpData->TransmittingPacket)
{
// Encrypt
nRtpLength = RFEngineRTPEncrypt((char *)pRawRtpData->pRtpHeader, pRawRtpData->RtpPacketLengthInBytes);
pRawRtpData->NewRtpBufferLengthInBytes = nRtpLength;
}
else
{
// Decrypt
nRtpLength = RFEngineRTPDecrypt((char *)pRawRtpData->pRtpHeader, pRawRtpData->MaxRtpPacketLength);
}
}
}
unsigned int RFEngineRTPDecrypt(IN char *pRtpHeader, IN int nRtpPacketLength)
{
char decryptBuf[BUF_SIZE];
unsigned int actualLen = nRtpPacketLength;
if(!pRtpHeader)
return 0;
// Perform decryption upon packet on WORD unit basis
XOR_Algorithm(pRtpHeader, nRtpPacketLength, decryptBuf, &actualLen, g_keyBuf, KEY_SIZE, Decode_Algorithm);
// Reinject decrypted data back into packet
memcpy(pRtpHeader, decryptBuf, actualLen);
// Return decrypted RTP packet length
return actualLen;
}
static Xor_Sec_ErrorCode XOR_Algorithm(IN const char *msg_ptr,
IN unsigned short len,
OUT char *code_buffer,
INOUT unsigned int *actuallen,
IN const char *key,
IN int keySize,
IN Code_Algorithm EncryptMethod)
{
int i;
char chCurSeed;
char endKey = (char)0x53;
unsigned short endnum = 0;
if(len <= 0)
{
return Xor_SourceBuf_Len_Error;
}
if(*actuallen + 1 < len)
{
return Xor_DestBuf_Len_Error;
}
if(keySize <= 0)
{
return Xor_KeyLen_Error;
}
if(NULL == key)
{
return Xor_Key_Error;
}
*actuallen = len;
endnum = len;
if((Encode_Algorithm == EncryptMethod) && (0 != len % 2))
{
endnum = len -1;
*(code_buffer+endnum) = *(msg_ptr + endnum)^(endKey);
}
if((Decode_Algorithm == EncryptMethod) &&(0 != len % 2))
{
endnum = len -1;
*(code_buffer + endnum) = *(msg_ptr + endnum)^(endKey);
}
for(i = 0; i<endnum; ++i)
{
chCurSeed = key[i % keySize];
*(code_buffer + i) = (chCurSeed) ^ *(msg_ptr + i);
}
*(code_buffer + *actuallen) = '\0';
return Xor_Sec_Success;
}
|
|
|
Thanks,
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 26 2009 at 6:52pm | IP Logged
|
|
|
Hi George,
I am not sure why the LanScape sample code does not use the RtpPacketLengthInBytes value. Its probably because the sample RTP encoding/decoding uses the max buffer length or the buffer lengths are known.
For your situation:
The RtpPacketLengthInBytes member of the RAW_RTP_DATA structure should be set to the total number of bytes in the received “XOR encoded” RTP packet. It is the number of raw bytes from the network.
To make sure there is not a bug in the media engine, make sure the RtpPacketLengthInBytes value for the received RTP packets is equivalent to what you specified for the NewRtpBufferLengthInBytes value when the RTP packet was transmitted.
Also, I think your code line:
Code:
// Decrypt
nRtpLength = RFEngineRTPDecrypt((char *)pRawRtpData->pRtpHeader, pRawRtpData->MaxRtpPacketLength);
|
|
|
Should be:
Code:
// Decrypt
nRtpLength = RFEngineRTPDecrypt((char *)pRawRtpData->pRtpHeader, pRawRtpData->RtpPacketLengthInBytes);
|
|
|
If you want to upload your source code and project, I can take a look. This may be the quickest solution.
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: February 27 2009 at 3:14am | IP Logged
|
|
|
Hi Randal:
You mentioned "make sure the RtpPacketLengthInBytes value for the received RTP packets is equivalent to what you specified for the NewRtpBufferLengthInBytes value when the RTP packet was transmitted." at last post, I don't understand why for that. I study document and find no description on that point. So I am a little confused. It seems to me NewRtpBufferLengthInBytes value is only used at transmitting and nothing to do with RTP reception.
Yes. I have uploaded entire call related source code without GUI portion and 3rd-party skin library onto my FTP support account for your reviewing. Our application code is mainly based on your single line phone example at media engine. I use VC++ 6.0 as development IDE.
Thanks,
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 27 2009 at 10:59am | IP Logged
|
|
|
Hi George,
OK, we will look at your project right away. I will post with further info…
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 02 2009 at 9:46am | IP Logged
|
|
|
Hi Randal:
How is going with your reviewing on my source code? Any suggestions on troubleshooting issue.
Thanks,
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 02 2009 at 11:10am | IP Logged
|
|
|
Hi George,
We are working on the RTP encryption issue as we speak. With any luck, we may have it done today.
I will repost as soon as we verify/fix whatever is going on.
Thanks,
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 03 2009 at 4:03am | IP Logged
|
|
|
Hi Randal:
Any lucky can be seen by me today?
Thanks,
George
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 04 2009 at 8:51am | IP Logged
|
|
|
Hi Randal:
It seems that you have bumped into great trouble in fixing possible issues for RTP decryption. If u don't mind, would u like to discuss with me?
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 04 2009 at 12:50pm | IP Logged
|
|
|
Hi George,
We are still working the issue. We found the basic problem but before we can get you an update, we need to merge the changes onto the main code branch of the media engine. We can’t do this until we have one other item addresses. Then we need to test out the media engine to make sure that these changes do not affect any other functionality. This all takes time.
As soon as we get this issue addressed, we will then look at the SIP inter-op issue you also reported.
Unfortunately, the “free support” we offer has to take a “back seat” to paid support requests that we receive. Maybe its time for you to enter into a support agreement? :)
Thanks for your patience.
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 04 2009 at 9:46pm | IP Logged
|
|
|
Hi Randal:
How to purchase "Enhanced paid support" service? And what kind of service u can offer? Pls give me description for reviewing.
In fact, we do hope to order that support. But frankly speaking we also worry about response speed and time duration at fixing bug. If u provide me confidence with rapid bug fix and release, I think it is attractive to purchase support service.
Thanks,
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 05 2009 at 7:14am | IP Logged
|
|
|
Hi George,
I will send to you an email with a support agreement attached. Look it over and we can discuss if required.
Work continues today on the RTP encryption issue…
Thanks for your understanding and patience.
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 05 2009 at 8:54am | IP Logged
|
|
|
Hi Randal:
Yes. I do need to discuss with u on service assurance.
Thanks,
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 05 2009 at 5:48pm | IP Logged
|
|
|
Hi George,
WOW, it has been busy here! Thanks for your patience.
Part of the reason addressing your issue has taken longer than we like is because all of a sudden we had a backlog of support requests. Those customers who have paid support with us take precedence over free support. It has to be this way. I truly regret the delay! :)
Your issue with the fully encrypted RTP was pretty simple to track down. The problem you were having is not a bug. The reason you don’t hear anything audio when using fully encrypted RTP media packets is because of the normal default RTP packet filtering that the media engine performs when it receives RTP packets that do not conform to what was negotiated by the call setup.
I took a standard single line phone sample project (from the latest media engine distribution) and slightly modified the code to use your RTP codec algorithm. Your code is pretty straight forward and I had no problems grabbing your code to get a test build working.
There is an archive of this project in your support FTP account in the “RTP encryption issue” directory. Please see the following archive:
“New example source code - Release 6 - Customer.zip”
There are 2 reasons why your received audio is not being heard. See Items 1 and 3 below.
Item 1: Calling procedure VoiceBoBoPatch() is not required.
You should no longer need to call the VoiceBoBoPatch() procedure in your code. The media engine currently handles the situations that lead to the “bobo” noise artifacts you previously reported.
For more info, see the media engine version history information. Specifically item 4 of the v6.0.0.5 version info:
Version History:
http://www.lanscapecorp.com/ProductPages/VOIP%20Media%20Engi ne%20Version%20History.htm
Also, calling your VoiceBoBoPatch() procedure will tag all received encrypted RTP packets as bad and you will not hear any received audio. So… “DO NOT CALL THE VoiceBoBoPatch PROCEDURE” when your received RTP packets have their RTP headers encrypted. :)
This is the first part that caused your grief.
Item 2: Clarification of RtpPacketLengthInBytes value.
The description of the RtpPacketLengthInBytes member of the RAW_RTP_DATA structure has been revised in the Software Developer’s Reference and the .NET class reference. Hopefully this new description will better describe the value RtpPacketLengthInBytes. Here is the new text:
RtpPacketLengthInBytes
The total number of bytes in the RTP packet.
For RTP packets that are being transmitted, this value will be the sum of the RTP
header size (RtpHeaderLengthInBytes) + the total number of RTP payload bytes (SampleBufferLengthInBytes).
For RTP packets that are being received, this value represents the actual number
of RTP packet bytes read from the network.
Item 3: Disabling received RTP packet filtering.
This is the second part that caused your grief. In v6.0.0.5, the media engine was made to gracefully handle RTP packets that do not conform to SIP negotiated audio and/or RFC2833 DTMF signaling. The changes are associated with the “bobo” noise updates. By default, RTP bad packet Id and size filtering is enabled for all calls.
Unfortunately, we did not document the following API support when v6.0.0.5 was released:
Code:
typedef enum FILTER_RECEIVED_RTP_PACKETS
{
RTP_FILTER_BAD_PAYLOAD_ID = 0,
RTP_FILTER_BAD_PAYLOAD_SIZE,
RTP_FILTER_UNUSED
}FILTER_RECEIVED_RTP_PACKETS;
TELEPHONY_RETURN_VALUE VOIP_API FilterReceivedRtpPackets(
SIPHANDLE hStateMachine,
int PhoneLine,
FILTER_RECEIVED_RTP_PACKETS FilterType,
BOOL EnableState
);
|
|
|
The v6.0.0.10 “engineering release” of the media engine that is in your support FTP account has all the updates.
The FilterReceivedRtpPackets() API procedure will allow your VOIP app code to disable the RTP packet ID and RTP packet size filtering functions. For your application, you only need to disable the RTP packet ID filtering for your phone lines. See the developer’s Reference for more details. It has been updated to document this newly exposed API support.
Summary – why you have to call the FilterReceivedRtpPackets API procedure:
When your phone calls use the type of RTP encryption that you are employing (full RTP packet encryption), the entire RTP packet is “mangled”.
Transmission of these fully encrypted RTP packets is not a problem… reception is a problem – by default.
When these fully encrypted RTP packets are received by the media engine, the media engine checks them and performs a “validity test”. If the packet size or media type are not correct for the call as negotiated by the SIP, the RTP packets basically get filtered out by default.
This is a problem seeing that the RTP headers in your RTP packets are encrypted.
To remove this condition, your app must call the FilterReceivedRtpPackets() API procedure to disable the RTP packet ID filtering on each phone line. For example:
Code:
.
.
.
// turn off received packet ID filtering.
status = FilterReceivedRtpPackets(
hStateMachine,
PhoneLine,
RTP_FILTER_BAD_PAYLOAD_ID,
FALSE
);
.
.
.
|
|
|
If your RTP packet encryption code someday also changes the size of RTP packets, you will have to call the above proc to also disable RTP packet size filtering (RTP_FILTER_BAD_PAYLOAD_SIZE).
You should be use v6.0.0.10 “engineering release” of the media engine for further testing – it supports the above API and other improvements (see version history that come with the release)).
Search the sample source code I placed in your support FTP account for the FilterReceivedRtpPackets API proc to see how I used it. Basically it gets called before initiating a fully encrypted outgoing call and before answering an incoming fully encrypted call.
Item 4: Changes to the sample code.
Search the sample code for the conditional compile macro SPEEDVOIP_CHANGES. There are not many changes to the base code. You will have no problem figuring out all the simple changes.
From the sample code I placed into your support account, Test calls and everything else looks really good. Your XOR encryption algorithm works great too.
Next on the list is to resolve the SIP Inter-Op with Brekeke SIP Server SIP inter-op issue. I will be using your test proxy from the above post. Hopefully I can get this done by end of the day tomorrow. If so, I will update you again tomorrow.
We will update you with an official product image after we receive needed feedback from a few other customers and after we remove the Brekeke SIP Server issue.
Thanks George… I know waiting sucks!
Randal
|
| Back to Top |
|
| |
speedvoip
Vetran
Joined: August 07 2008
Location: Canada
Posts: 156
|
| Posted: March 11 2009 at 1:13pm | IP Logged
|
|
|
Hi Randal:
RTP decryption works fine using your latest engineering release. Thanks for your effort. After we get official latest product image, we will request annual support.
George
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 11 2009 at 2:08pm | IP Logged
|
|
|
Hi George,
That is good. Now all we need to do is track down why you were having issues with the Brekeke SIP server:
SIP Inter-Op with Brekeke SIP Server:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=569&PN =1
Lets focus on getting the above post resolved. After that we will get you an updated product image.
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: RTP Decryption within callback procedure
