I’m developing a propreitary codec and I want to use Asterisk as a call manager. Asterisk itself does not need to support the codec, but simply connect to endpoints together. For example, I want Asterisk to connect Phone A to Phone B but after that all the media is going between A and B directly. (Encoding/Decoding is only done at the endpoints).
Currently I am running Asterisk 1.8.4 on a Asus router and I managed to make the phones communicate with each other with a supported codec using SIP and I noticed that:
-For a direct connection, Asterisk sends multiple invites to both phones even after Phone B accepted the first invite. Why? Is there a way to make Asterisk send just one invite and still create a direct connection from Phone A to Phone B?
-Upon examining the INVITE packets, Asterik does not simply relay the invite but creates a new one.
Is there a way to have Asterisk simply relay the incoming INVITE packet from Phone A to Phone B?
After the connection is terminated by Phone B, Asterisk sends another invite to Phone A just to terminate the connection. Why is this needed?
-How does Asterisk map codecs to a RTP Payload Type number? Is there a table somewhere?
There is or was a way of getting Asterisk to setup direct media on the INVITE, however it is or was buggy and is off by default and may have been disabled. It is only useful if you don’t do anything that requires Asterisk to generate tones or announcements.
Asterisk allows you to have modules that will pass through codec data without knowing how to interpret it. This can allow some simple G.729 cases to be handled without licences.
What you call multiple invites are actually called re-invites by SIP.
[quote]-Upon examining the INVITE packets, Asterik does not simply relay the invite but creates a new one.
Is there a way to have Asterisk simply relay the incoming INVITE packet from Phone A to Phone B? [/quote]
Asterisk is a back to back user agent (this is true of all SIP capable PABXes), not a SIP proxy, so the answer is no. The INVITE gets taken apart, converted into a protocol independent internal form, then reconstructed on the outgoing side. (Direct media is an optimisation that is only applied once the call is set up.)
Software layering. The code that actually supervises the call and does any relaying, does not know that there won’t be another step in the dialplan.
I’m not sure you need to know that, as except for some very basic codecs, it has to transmit the map between codec number and codec name in the SDP. I don’t know if this is dynamic, or whether it is done by the module that does the transparent codec handling. You should be using the codec map and codec name, not the numbers.
Is there a way to re-enable this in the sip.conf or elsewhere?
How can I accomplish this? I’ve tried setting allow=PropCodec in the sip.conf but it errored because Asterisk didn’t recognize it. Can I add new codecs and have Asterisk just pass them through?
If the codec implementation isn’t licensed under the GPL or if the codec uses any patented IP, be careful that you don’t run afoul of Asterisk’s GPL licensing (distribution) or international patent law.
Could you please expand on the concern of running afoul of the GLP licensing? I don’t want asterisk to do anything with the data in my codec… in fact the media itself should never touch asterisk as the phones have negotiated each other’s ip address and port number. I just want Asterisk to pass through the dynamic protocol number I’ve given the codec and the associated string.
[quote];directrtpsetup=yes ; Enable the new experimental direct RTP setup. This sets up
; the call directly with media peer-2-peer without re-invites.
; Will not work for video and cases where the callee sends
; RTP payloads and fmtp headers in the 200 OK that does not match the
; callers INVITE. This will also fail if canreinvite is enabled when
; the device is actually behind NAT.[/quote]
But you could easily have found this for yourself. If it is disabled in the code, you will have to look through the code. I haven’t confirmed that this option still exists in 1.8.
You will need to write a formats/format_PropCodec.c module and possibly adjust the make file and menuconfig configurations. If the way it is packed into RTP is similar to something else, it might be mainly cut and paste. Much of it may only be needed for annoucements/MOH.
It looks like you will also need to add an entry in a table in main/frame.c (found by grepping g729) and add a #define, locating which is left as an exercise for the reader.
Re: malcolmd’s comment, that will depend on how the licensing exceptions that allow G.729 are drafted. The format module mustn’t trigger any patent or copright issues. If you don’t include a codec module you shouldn’t create issues for the actual codec. However, if you do, you need to check whether the licence for Asterisk has a general exemption for proprietary codec modules, or whether the exemption specifically relates to G.729.
Without an exemption, a module that includes Asterisk header files would need to be GPLed, which would mean that it can’t include algorithms for which a royalty is due. The actual dynamic loading of modules is on the borderline of what the GPL might allow. My feeling is that the FSF would not allow it without an exemption.
The dynamic codec number will not be passed through, only the name. If your SIP implementation requires the codec number to be unchanged, it is broken.
[quote=“david55”];directrtpsetup=yes ; Enable the new experimental direct RTP setup. This sets up
; the call directly with media peer-2-peer without re-invites.
; Will not work for video and cases where the callee sends
; RTP payloads and fmtp headers in the 200 OK that does not match the
; callers INVITE. This will also fail if canreinvite is enabled when
; the device is actually behind NAT.
But you could easily have found this for yourself. If it is disabled in the code, you will have to look through the code. I haven’t confirmed that this option still exists in 1.8.[/quote]
Yes, I have tried that, but I think it’s disabled since there are still multiple reinvites. Any ideas where to start looking in the code?
chan_sip.c, of course. Do a search on for directrtpsetup in the file and see what comes out. It is probably also worth grepping the changelog or the SVN log, which may allow you to find out when it was disabled and what the change was that disabled it.
There will have been a good reason for doing so. My guess is that it originally related to certain failed call cases, but soubsequent changes may be incompatible.
[quote=“david55”]Re: malcolmd’s comment, that will depend on how the licensing exceptions that allow G.729 are drafted. The format module mustn’t trigger any patent or copright issues. If you don’t include a codec module you shouldn’t create issues for the actual codec. However, if you do, you need to check whether the licence for Asterisk has a general exemption for proprietary codec modules, or whether the exemption specifically relates to G.729.
Without an exemption, a module that includes Asterisk header files would need to be GPLed, which would mean that it can’t include algorithms for which a royalty is due. The actual dynamic loading of modules is on the borderline of what the GPL might allow. My feeling is that the FSF would not allow it without an exemption.[/quote]
Just to clarify, Asterisk is not going to be modified to support a new codec. The codecs are supported on Phone A and Phone B, all Asterisk is doing is establish that direct connection between Phone A and Phone B.
This shouldn’t affect the GPL correct?
So in sip.conf, for both Phone A and Phone B:
allow=all
Thus Asterisk should be able to negotiate a session between Phone A and Phone B despite not supporting the codec that Phone A and Phone B support.
SIP cannot negotiate an “all” codec. Asterisk needs to have the codec name compiled in. It probably needs a codec format module, although, unless the patents are too broadly drafted, that shouldn’t be a problem.
What all means is that Asterisk will list all the codecs it knows about in the initial offer. If it is responding, I think it lists the intersection of the ones it knows about and the ones that were requested, although that is not a requirement of SIP.
I really think you need to stop and read the SIP and SDP RFCs carefully, and you need to understand about B2BUAs.
For these reasons, bypassing the re-invite isn’t the big issue. If the call will work with the re-invite bypassed, it will not need a codec module, so it will work with Asterisk doing the relaying, possibly with the help of a format module.
Pass-through’s no biggie, see the G.723.1 pass-through capability in Asterisk today or the video pass-through support. It’s the transcoding and the distribution of codec modules that allow that transcoding that need to be assured in a license evaluation.
[quote=“david55”]You will need to write a formats/format_PropCodec.c module and possibly adjust the make file and menuconfig configurations. If the way it is packed into RTP is similar to something else, it might be mainly cut and paste. Much of it may only be needed for annoucements/MOH.
It looks like you will also need to add an entry in a table in main/frame.c (found by grepping g729) and add a #define, locating which is left as an exercise for the reader.