|Summary:||ASTERISK-03276: [patch] PREFERRED_CODEC - codec preference override|
|Reporter:||Michael Giagnocavo (aginamu)||Labels:|
|Date Opened:||2005-01-14 22:04:38.000-0600||Date Closed:||2011-06-07 14:05:23|
|Environment:||Attachments:||( 0) codec_override_native.diff.txt|
( 1) codec_override.diff.txt
( 2) preferred_codec_rev2.diff.txt
( 3) preferred_codec.diff.txt
|Description:||This patch adds a new channel variable, "PREFERRED_CODEC" to chan_sip and chan_iax2. If the variable is set, then when a call is initiated, that codec will be the preferred one (prefcodec in SIP, format in IAX2), if it's part of the capabilities. |
When setting the variable from the dialplan, be sure to use a leading "_" so that the variable is copied over to the new channel.
****** ADDITIONAL INFORMATION ******
[Disclaimer faxed a few minutes ago]
Example usage, assuming allow=all:
exten => 1,1,SetVar(_PREFERRED_CODEC=lpc10)
exten => 1,2,Dial(IAX2/foo/123)
LPC10 will now be the preferred codec for that call.
|Comments:||By: Brian West (bkw918) 2005-01-14 22:28:51.000-0600|
This patch is a bit wrong for both IAX and SIP. For me it outright doesn't work.
By: Michael Giagnocavo (aginamu) 2005-01-14 22:32:27.000-0600
I'd like to withdraw this patch until I can study it more. Apparently it doesn't work for some people (besides old GCC compat).
By: Brian West (bkw918) 2005-01-14 22:41:48.000-0600
no its a good start..like we talked on IRC but a few things need to be considered ;)
By: Mark Spencer (markster) 2005-01-15 00:30:02.000-0600
There's already a SIP_CODEC variable, why not just use it for outbound calls too?
By: Michael Giagnocavo (aginamu) 2005-01-15 00:34:42.000-0600
After feedback from a few people, I've changed the patch around. It now overrides the codec for call, by setting the capabilities, not just the format (prefcodec).
Also, by design, the codec can be forced to something not allowed in the iax/sip.conf. This is so that the same definition can be used to receive calls in a specific format, yet dial-out in another.
The correct file is codec_override, not preferred_codec.
By: Michael Giagnocavo (aginamu) 2005-01-15 00:39:46.000-0600
The reason to not re-use the SIP_CODEC is so that IAX and SIP (and perhaps other channels) can use the same variable. Seemed nicer than IAX2_CODEC, SIP_CODEC, etc.
I'm happy to change it though, if so desired. Perhaps add secondary support for SIP_CODEC? Or modify the current SIP_CODEC code to also allow "CODEC_OVERRIDE" and notify that SIP_CODEC should be phased out?
By: Michael Giagnocavo (aginamu) 2005-01-15 21:44:59.000-0600
Now, the 3rd incarnation: codec_override_native.diff.txt. I added support for a CODEC_OVERRIDE value of "native". What this does is take the requested format (format, when requesting a new channel), and force that codec. This should help in scenarios where clients are connecting with different codecs, but you want to minimize transcoding. By default, Asterisk *tries to prefer* the native codec, but the remote server can override this.
The only thing I feel bad about is that in iax2_request, I added "c->oldwriteformat = format". That was the best (low impact?) way I could figure out of keeping the requested format long enough for the codec override code to find it. chan_sip does this by setting the sip_pvt's "prefcodec" variable. chan_iax2_pvt does not have an equivalent var, AFAIK.
By: Mark Spencer (markster) 2005-01-16 01:03:25.000-0600
There is a great deal of duplicated code here and i can't help but think this should be substantially simpler.
Essentially, in iax2_call we use the requested format (which is, of course, the format of the inbound call if this is an outboudnd call). In order to switch preferred codecs, the only thing that should be required is to set c->nativeformats in this case -- although this may become slightly more complicated when we merge anthm's iax2 codec priority patch.
On the sip side, it is only necessary to modify p->jointcapability as is done with SIP_CODEC in sip_answer already.
I'm fine with deprecating SIP_CODEC and using PREFERRED_CODEC instead.
By: Michael Giagnocavo (aginamu) 2005-01-16 20:42:22.000-0600
Mark, you're right if all I wanted to do was set the preferred codec. After BKW pointed out that this won't work, since the callee can still choose another codec, I changed it to FORCE a codec (hence the new "override_codec"). This sets the preferred codec, as well as the capabilities. Otherwise, the receiving end can just go ahead and use another codec anyways, which defeats my purpose.
By: Brian West (bkw918) 2005-01-17 09:18:46.000-0600
What ya mean "when"... the codec stuff is in there already :P
By: Olle Johansson (oej) 2005-02-13 13:05:24.000-0600
Housekeeping reminder... Where are we with this?
By: Michael Giagnocavo (aginamu) 2005-02-13 21:43:49.000-0600
I'm waiting for orders. I think things got confusing since it started out as a "preferred" codec, and ended up as a forced codec.
By: Kevin P. Fleming (kpfleming) 2005-03-03 16:13:01.000-0600
Here is the plan we have come up with on IRC:
When a channel comes in to Asterisk from a channel driver, set a channel variable called __PREFERRED_CODE holding the name of the codec being used for that channel.
When an outbound channel is created, if __PREFERRED_CODEC contains a codec that is allowed for that peer, then make it the preferred codec, regardless of preferences defined for that peer. If it's empty, or the codec is not allowed for that peer, then ignore it.
Finally, remove the existing code in chan_sip and chan_iax2 to determines the caller's codec and makes it the preference (it will not longer be needed).
With this change, the existing behavior would be unchanged, but if the dialplan wants to force a preference for an outbound call it can do so, or if it wants to let the peer's preferences take effect it can clear the variable completely.
AgiNamu, are you willing to implement this change and post it? You've got the support of the rest of the dev team if you do.... it seems like the most elegant and straightforward solution.
(Also, as Mark mentioned, remove support for SIP_CODEC, since it will no longer be needed).
By: Michael Giagnocavo (aginamu) 2005-03-03 16:26:09.000-0600
That sounds like a good plan. I'll be willing to work on it, with one addition: a FORCE_PREFERRED_CODEC (boolean) variable. Perhaps a better name would be NO_TRANCODE. Basically, instead of just setting the preferred codec, we disallow all codecs but preferred one. This ensures no transcoding.
Does that sound like a good plan?
By: Kevin P. Fleming (kpfleming) 2005-03-03 16:28:44.000-0600
That will happen automatically in any channel driver, when the format is set as preferred.
By: Kevin P. Fleming (kpfleming) 2005-03-03 16:30:49.000-0600
Mark and I discussed an alternate way to implement this, so hold off for a bit.
By: Kevin P. Fleming (kpfleming) 2005-03-03 22:04:20.000-0600
OK, patch uploaded and basic testing done here. Nothing seems to be broken. The patch does these things:
- removes SIP_CODEC support
- adds PREFERRED_CODEC variable to read format that will be requested when channels are created by this one (this is a _real_ channel variable, not a variable in the linked list)
- adds SetPreferredCodec application to change value of PREFERRED_CODEC variable
- passes the value of PREFERRED_CODEC to ast_request whenever an outbound channel is created
- updates the value of PREFERRED_CODEC when SIP/IAX2/MGCP/H.323 peers change codecs during the call
Patch is relative to the patch in ASTERISK-3543573. Testing would be appreciated :-)
By: Kevin P. Fleming (kpfleming) 2005-03-03 22:06:09.000-0600
I don't know yet about the "disable transcoding" part... I'll have to let Mark jump in with his thoughts on how that would best be implemented.
By: Kevin P. Fleming (kpfleming) 2005-03-11 10:13:12.000-0600
rev2 uploaded to match current CVS
By: Mark Spencer (markster) 2005-03-30 01:12:28.000-0600
kpfleming, lets work on this one this week / weekend.
By: Kevin P. Fleming (kpfleming) 2005-03-30 05:45:12.000-0600
Yep, it's already on my agenda :-)
By: kb1_kanobe2 (kb1_kanobe2) 2005-05-04 22:32:07
Any chance this can see its way into cvs-head before the next feature freeze? It would make things much easier for those trying to get things like fax-over-iax working.
By: matiasg (matiasg) 2005-05-30 17:34:50
any news on this one? it would be great to have this functionality... if we can help with testing let me know...
By: Michael Jerris (mikej) 2005-06-26 18:19:45
poke. Where does this one stand?
By: Kevin P. Fleming (kpfleming) 2005-07-12 13:33:49
Like all the other complex projects, it's waiting for everything else to get out of the way...
By: Michael Jerris (mikej) 2005-07-31 21:45:42
suspending due to no activity, re-open when there is updated code for review. Thanks.
By: Michael Jerris (mikej) 2005-07-31 21:47:02
just a note that I closed this one out for now due to no activity.
By: Digium Subversion (svnbot) 2008-06-07 10:47:37
r559 | markster | 2008-06-07 10:47:37 -0500 (Sat, 07 Jun 2008) | 2 lines
Fix FXOTUNE to know which zaptel.h to use (bug ASTERISK-3276)