| Author |
|
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: March 05 2008 at 11:05am | IP Logged
|
|
|
Hello,
We want to use iLBC30ms codec to transmit voice but we are having problems with overheads. With iLBC we have a real bandwidth of 23.43Kb/s (To transmit 30ms of voice we need: 50 bytes of samples + 12 bytes of RTP Header + 8 bytes of UDP Header + 20 bytes of IP Header, Ethernet layer isn´t problem).
To reduce overhead introduced by the 40 bytes header,
multiple voice frames can be packed into a single frame to transmit, is it possible with your media engine? We know it will increase the voice delay, but isn´t any problem.
We have tried to do it with RawRtpCallback sending two packets together and ignore one of them, but it doesn´t work and we don´t know if it is our fault or, in the other hand, media engine doesn´t support to change sample buffer length in reception.
Thank you very much
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 05 2008 at 12:23pm | IP Logged
|
|
|
Hi hermes,
It sounds like you know exactly what you are doing. The raw RTP callback will allow you to do this for RTP transmissions but for RTP receptions, there is a snag.
For RTP transmissions:
It is as you describe. Your app would intercept raw RTP “ready-to-be-transmitted” 30Ms frame size RTP payloads. You can then transmit every other RTP sample block by merging the two RTP payloads and then transmit the 60Ms frame size. Your app will have to rewrite the RTP header values appropriately so they appear at the far end without any sequence gaps.
Note: If you do this, keep in mind that you will be overriding the iLBC mode parameter that was used to negotiate the SIP call. If you control what is going on at both call endpoints, then you will be OK.
For RTP receptions:
This is where the “snag” comes in. The media engine will present to your app the 60Ms iLBC RTP packet with RTP header. Unfortunately there is no way to for the app to take this data, split it into two RTP payloads and then pass it back to the phone line’s RTP receive channel for processing. What we would need is a new API that would allow the app to pass multiple RTP frames to the phone lines receiver processing functions. All data passed from the app to the RTP receiver logic would then unconditionally be injected into the received phone line media stream.
Without the above mention added API procedure, we can’t think of a way to do it cleanly.
Support
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: March 05 2008 at 5:00pm | IP Logged
|
|
|
Thank you for your response.
We don´t need this feature now because we have enough bandwidth to support all simultaneous calls that we have nowadays, anyway we would like to know how much we would cost and how long would take to develop this new functionality because it can be very usefull in a near future
Thanks again
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: March 06 2008 at 12:30am | IP Logged
|
|
|
Hi,
As we are interested to this subject I try propose another solution.
In my opinion you adding support for multiples of 20ms for G729/iLBC-20ms, multiples of 10ms for G711, multiples of 30ms for iLBC-30ms in Media Engine is a better solution. This is because Media Engine is not always placed at both ends, and in some deployments you are not source or destination.
We have expericened some voice gateways which supported above customizable duration for RTP packets. So this is one missing feature in Media Engine which may be useful for all customers.
I think it's better to move this thread to Wish List forum.
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 06 2008 at 8:15am | IP Logged
|
|
|
Hermes and Jalal,
Thanks for your responses.
We agree fully with Jalal. In the long run it would be wiser to sit down and design into the media engine additional “multiple frame size” support.
However in the mean time, if we can add a simple API that a VOIP app can use creatively to achieve the needed results now, we are all for that.
A bit of background and clarification:
G729 codecs:
Right now the media engine makes all outgoing G729 calls using a default 20Ms frame size. This is set in the calls SDP using the “ptime” media attribute:
Code:
INVITE sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK0045a111
From: "Test Phone" <sip:333@ps>;tag=45b4ed;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Contact: <sip:333@192.168.1.2:5066>;x-inst="VGVzdCBDYWxsIERhdGEgZnJvbSB0aGUgVlBob25lIGFwcC4="
Call-Id: 01c17486-0804-4c6b-85c2-07f1674fd8fa-00000fa8@192.168.1.2
CSeq: 4564822 INVITE
Max-Forwards: 70
Organization: 2456E5FD-DC94-417D-BDF7-55A654EFB9E5
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 242
User-Agent: LanScape VOIP Media Engine/5.12.8.2 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=333 4546453 4546453 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 20004 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20
a=fmtp:101 0-16
|
|
|
If the far end of the call wants to use 40, 60, 80 or some higher multiple of 20Ms rtp frame sizes, then it will respond in its “200 OK’ response with a ptime setting it wants to use. The media engine then will shift to this new larger frame size. The rub is that this is only supported right now for G729 based calls.
iLBC codecs:
Uses 20Ms and 30Ms frame size. If a call is made using 20Ms frame size, the frame size can sh*t automatically from 20Ms to 30Ms if the receiving end of the call determines it wants to use 30Ms instead. If the call is made using 30Ms frame size, then the receiving end of the call must support 30Ms. There is no shifting from 30Ms to the lower 20Ms frame size. All this occurs as the result of specific SDP media attribute parameters.
All other supported codecs (uLaw, aLaw, 8k, 11k, 22k PCM):
All other codec use a fixed frame size of 20Ms.
Hermes:
If this is something you need in the short term, email us (support) using the following web page form:
http://www.lanscapecorp.com/ASP%20Files/ContactUs.asp
We will work out the development details and discuss pricing that will fit us both.
Jalal and Hermes:
Start saving examples of SIP logs that perform different frame size negotiations. At the moment we don’t know if all the frame sizes are controlled by the “ptime” SDP attribute or not. If either of you have this info, go ahead and forward it to us. It will shorten the upfront research we will have to do to fully support his new capability. We agree, this would be a useful capability. We are all about getting as many concurrent calls “on the wire” as possible.
Thanks again to Jalal for adding his thoughts. Very good.
Support
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: March 06 2008 at 9:56am | IP Logged
|
|
|
When you say: "The rub is that this is only supported right now for G729 based calls", does it mean that your engine works with G729 in both ways with 40ms frame size?
I suppose that it only works for transmission, for reception it has the same problem that iLBC, doesn´t it?
Code:
40ms
LanScape Media engine ---------> Other phone ---> OK
40ms
Other phone ---------> LanScape Media engine ---> ERROR
|
|
|
One more question about SIP, is it possible to stablish a connection with a different frame size in each way?
Thanks again
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 06 2008 at 1:04pm | IP Logged
|
|
|
Hi hermes,
You >>>
…does it mean that your engine works with G729 in both ways with 40ms frame size?
<<< Support
Yes. But please take note: From the API, there is no current way to initiate a G729 call using something other than 20Ms frame size. All outgoing G729 calls default to 20Ms frame size unless the far end of the call specifies that 40Ms, 60Ms, or whatever multiple 20Ms frame size be used. When the media engine receives the “200 OK” from the far end, the far end will set the ptime SDP media attribute. This ptime value tells the media engine (who initiated the call) to either continue to use 20Ms frame sizes or shift to using some other multiple of 20Ms frame size. Does that make sense??
For incoming calls, the media engine will simply use the ptime value the far end sent in its INVITE request. This can be 20, 40, 60, etc…
If you know the far end of the call can support 20Ms integer multiples of G729 payloads, a “good hack” you could perform to initiate a 40Ms G729 call would be as follows:
1)
Modify the outgoing SIP INVITE the media engine wants to transmit. Change the “ptime=20” SDP parameter to whatever you want (that is supported by the far end). Let’s say we change it to: “ptime=40”.
2)
Allow the modified INVITE to be transmitted by the media engine.
3)
If the far end responds with the same “ptime=40” SDP parameter in the “200 OK” SDP, 40Ms G729 encoded audio will be used for the call.
We have NOT coded this up and tested it but the above scenario should work.
We have logged a request to support initiating G729 calls using a user defined integer 20Ms frame size. It would be useful. We will try to get it into a future release.
You >>>
… is it possible to stablish a connection with a different frame size in each way?
<<< Support
If the above did not answer this question, please repost and elaborate a bit more.
Thanks,
Support
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: iLBC overhead problem
