[OpenSIPS-Devel] Couple questions about codec_* functionality

[Mike Schwed]

Hi all,

Been using OpenSIPS (and its predecessors) for over 5 years, and it's been 
a great help in numerous way, including its codec_* family of functions in 
the textops module. So, thanks for all of your hard work.


One apparent limitation of the codec_* functions (unless I'm misreading 
the docs) is that, while we can manipulate by string/regex based on 
a=rtpmap lines and be more explicit by specifying clock, we're a little 
stuck when dealing with "well-known codecs" that exist in m=audio, but do 
not have accompanying a=rtpmap line to identify the payload explicitly.

Many vendors simply send a "m=audio XXXXX RTP/AVP 0 8" and assume that 
your equipment knows what 0 and 8 are, without being explicit about it. 
Unfortunately, with the a=rtpmap lines missing from the SDP, the codec_* 
functions fail to treat these sorts of calls in the same way.

Would it be possible to offer a by-payload version of/option for the 
codec_* functions, so that codecs without explicit a=rtpmap lines in 
their SDP can be treated like their string-based counterparts?


Also... while testing some very ugly (and unused) alternatives, I noticed 
that very strange behavior (behaves the same in 1.6.1 and 1.6.2, at least 
for notls) occurs when mixing any of the codec_* family with any of the 
replace* and subst* families of functions on the same packet, at least 
with regards to SDP modifications.

For example, when doing a simple:

if(codec_exists("PCMU")) subst_body('/AVP\ 18\ 0\ 8\ 101/AVP 18 101/g');

(or equivalents with subst, replace_body, and so on)

...in a few-line test cfg, the line of SDP in an actual packet gets 
rewritten from:

m=audio XXXXX RTP/AVP 18 0 8 101.

To:

m=audio XXXXX RTP/AVP 18 10118 0 8 101.

Whereas, when doing:

subst_body('/AVP\ 18\ 0\ 8\ 101/AVP 18 101/g');

(again, or equivalents)

...without the codec_exists() call, the line gets rewritten from:

m=audio XXXXX RTP/AVP 18 0 8 101.

To:

m=audio XXXXX RTP/AVP 18 101.

...as you'd expect it to be.

The difference appears to occur when the codec_* and subst*/replace* are 
called on the same packet, with the codec_* function either preceding or 
following the subst*/replace* function in the route block. It does not 
seem to occur in all instances (seems to be shrinking content that 
matters most), but the above example was consistently reproduceable.

While I understand that manipulating the SDP twice for a single packet may 
not be safe (or, at least, memory-safe), this behavior may not be expected 
by most users, particularly as codec_exists() isn't updating the SDP at 
all in the above example - merely requesting a boolean check for presence 
or absence.

Regards,
Mike Schwed