|Summary:||ASTERISK-11883: [patch] Answer preferred codec only in SIP response|
|Reporter:||Andriy I Pylypenko (bamby)||Labels:|
|Date Opened:||2008-04-21 02:58:57||Date Closed:||2009-03-24 15:01:32|
|Environment:||Attachments:||( 0) pref_codec_only-1.diff|
|Description:||There is a following situation. The third party SIP gateway sends to Asterisk INVITEs with codecs A and B in that order. Asterisk answers the same A and B codecs. But gateway has internal policy to prefer the codec B if possible and so it immediately sends reINVITE with codec B only. This is undesirable behavior for the system. However Asterisk cannot be limited to codec A only as there can be INVITEs with codec B only from the gateway and they should be handled as well. The task is to avoid codec B when it is possible at asterisk.|
It would be nice that Asterisk is able to answer the most preferred codec only in SIP response. This leaves no choice to the SIP gateway and thus the reINVITEs are suppressed.
I've developed a patch that adds a global option to sip.conf that causes the Asterisk to include the most preferred codec only in response.
|Comments:||By: Andriy I Pylypenko (bamby) 2008-04-21 03:01:57|
To make things clear - the patch makes SIP channel to answer the most preferred codec of the incoming SIP request, not the most preferred codec from sip.conf.
By: Andriy I Pylypenko (bamby) 2008-04-21 03:22:27
Please disregard the first patch pref_codec_only.diff. It was incorrectly backported from 1.4. The correct and tested one is pref_codec_only-1.diff.
By: Olle Johansson (oej) 2008-07-01 10:07:44
Hmm. I don't know what to say really. I understand this is useful for you, but I question if it has a more general usefulness... I will have to think about it.
Anyway, thanks for contributing your code to the project!
By: Olle Johansson (oej) 2008-07-18 08:29:43
A more generic setting would be to reinvite to the preferred one after the first negotiation. That would make a lot of sense to video. So we have a first negotiation that may end up with several codecs. Then we re-invite to lock the session to one codec only, the one we prefer that the other side also offers.
By: Andriy I Pylypenko (bamby) 2008-07-18 08:36:52
And what if the calling party will send the reINVITE before us? :)
By: Olle Johansson (oej) 2008-07-18 08:41:18
That's just life, isn't it. We either stay happy with their re-invite or wait until it's over and send ours.
By: Andriy I Pylypenko (bamby) 2008-07-18 08:54:01
And this solution will give the required result with some probability but no 100% guarantee. To answer a single codec in turn guarantees that this codec will be chosen at least to send the RTP from caller to callee.
By: Olle Johansson (oej) 2008-07-20 03:17:19
Why not 100%?
By: Andriy I Pylypenko (bamby) 2008-07-21 01:55:50
If the calling SIP proxy has sent its reINVITE and received a confirmation before our reINVITE it can further refuse to switch to other codec. The probability of this event is low but not zero. However I don't know how the SIP proxy from my example will behave exactly.
Another situation can occur - the calling SIP proxy's reINVITE may come after our reINVITE has been sent (network delay, calling proxy congestion). And this situation is also not easy to deal with.
To respond with single codec leaves no choice for calling proxy except to switch to the that codec, so no reINVITEs occur, no race condition can occur and code is simpler.
By: Terry Wilson (twilson) 2008-11-19 16:47:29.000-0600
oej: do you have any additional feelings about this patch?
By: Olle Johansson (oej) 2008-11-25 02:29:43.000-0600
Well, at least it has to be configurable on a device level too, not only on the [general] level. I wonder if we could do something in the dialplan here too, like the SIP_CODEC variable works for outbound invites.
By: Digium Subversion (svnbot) 2009-03-24 15:01:31
r183995 | dvossel | 2009-03-24 15:01:30 -0500 (Tue, 24 Mar 2009) | 10 lines
SIP preferred codec only feature
Added an option to respond to a SIP invite with only the single most preferred joint codec. This limits the options of what codecs the other side can use.
(closes issue ASTERISK-11883)
Reported by: bamby