Right, I think setting priority to disabled just affects the INVITE SDP,
the codec can still be in use on another call. - Bill
On 12/4/2014 6:46 AM, Harald Radke wrote:
> ...and here is where I misunderstood you, or better, kinda preoccupied
> when reading your reply...I got thrown of by the sua-app reference
> (--dis-codec= mentioning) but of course the basic mechanism behind
> that one, the disabling of codecs in the codec manager is EXACTLY what
> I need!
> pjmedia_codec_mgr_set_codec_priority() will do the trick, first do a
> PJMEDIA_CODEC_PRIO_DISABLED for all and then for the one wanted
> ("L16/48000/2") set prio to e.g. highest
> Thx for your help Bill and sorry for getting you wrong (-:
> Regards,
> Harry
> *Gesendet:* Donnerstag, 04. Dezember 2014 um 12:15 Uhr
> *Von:* "Harald Radke" <harryrat at gmx.de>
> *An:* pjsip at lists.pjsip.org
> *Betreff:* Re: [pjsip] media endpoint codec questions
> Hi Bill,
> hm, I think we misunderstood eachother. What I am doing is writing a
> PJSIP application, which handles multiple calls at the same time with
> different codecs (families). So basically the program starts, and e.g.
> sets up two calls, to two different sip URIs (with two different local
> sip accounts and two different sets of requirements). Alternativly it
> listens on e.g. 5060 and handles incoming simultanious calls for
> different local sip users
> since there is only one codec factory per codec family all
> manipulation of available codec setups will affect all media endpoints
> that use that codec (factory).
> )-: either I will tailor codecs which exactly cover one set up (one
> codec for L16/48000/2 , one for L16/44100/2, one for L24/96000/2 etc)
> Or I will discard the media enpdoint/codec usage to retrieve/check the
> SDP "compatibility" of the local and remote end (which wouldnt be too
> bad since the actual media data handling will not be done in the app
> anyways, I need only the signalling).
> Thx anyways,
> Harry
> *Gesendet:* Mittwoch, 03. Dezember 2014 um 18:08 Uhr
> *Von:* "Bill Gardner" <billg at wavearts.com>
> *An:* pjsip at lists.pjsip.org
> *Betreff:* Re: [pjsip] media endpoint codec questions
> My original post was wrong. After browsing the code, I see that the
> codec manager keeps separate "fully qualified IDs" for each codec. So
> you can disable individual variants by passing, e.g.,
> --dis-codec=Speex/16000/1, which will leave other Speex codecs
> enabled. So you should be able to set up whatever L16 codecs you want
> on a call by call basis without altering any pjsip code.
>
> Bill
>
> On 12/3/2014 4:01 AM, Harald Radke wrote:
>
> Hi Bill, thx for the answer!
> 1) The thing is, I need multiple sessions, with distinct codec
> (settings), e.g. call 1 should be L16/48000/2 while call 2 uses
> L16/44000/1 and call 3 might use a different encoding at all (like
> L24 or G711).
> In order to minimize custom SDP handling, I have to media
> endpoints, each for every call, with the apropriate codec
> (factory) associated to (like L16 and G711). However I would like
> to further restrict codec selection per call (or "user" if you
> will) in order to exactly specify codec requirements , so that:
> incoming INVITEs for call/user 1 will only accepted for e.g.
> L16/4800/2 , in case of user 2 only L16/44000/1 and for outgoing
> calls only the call specific codecs will be included in the SDP
> description
> Of course I could start to heavily mess around with the SDP data
> myself but the main intention for using something like PJSIP was
> to minimize stuff like that (-:
> Alternativly I could create codecs for each and every
> configuration setup, like l16-48000-2 , l16-44000-1, etc, but you
> see that I would like to avoid that (-:
> 2) hm, the thing is, that in total, I will end up with more than
> 32 different codec settings in total, from which however there
> will only be picked a handful per session (if it was always one
> and only one, I simply could set all codec payload types for my
> codecs to fix 96 and live with it)... so I guess the best thing
> will be to indeed set the PT for my codecs to 96 fix, parse the
> created media entries of an outgoing INVITE SDP for multiple codec
> entries and add an increasing offset to subsequential PTs...e.g,
> letting the media endpoint return an SDP with:
> m=audio 24000 RTP/AVP 96 96 96
> c=IN IP4 127.0.0.1
> a=rtcp:24001 IN IP4 127.0.0.1
> a=sendrecv
> a=rtpmap:96 L16/96000/2
> a=rtpmap:96 L16/48000/2
> a=rtpmap:96 L16/44000/2
> I would go over the SDP and adjust the the PTs to
> m=audio 24000 RTP/AVP 96 97 98
> c=IN IP4 127.0.0.1
> a=rtcp:24001 IN IP4 127.0.0.1
> a=sendrecv
> a=rtpmap:96 L16/96000/2
> a=rtpmap:97 L16/48000/2
> a=rtpmap:98 L16/44000/2
> (man I would love to see that be done automatically on SDP media
> entry generation time (-: )
> Thx,
> Harry
> Hi Harry,
>
> 1) You can't do it with runtime options, but you can comment out
> the ones you don't want in l16.c, a bunch are already disabled.
>
> 2) Yes, all the dynamic payload types come from a enum in types.h
> so that each codec uses a unique type.
>
> Bill
>
> On 12/2/2014 6:17 AM, Harald Radke wrote:
>
> Hi all,
> I have two questions regarding media codecs in pjsip:
> 1) If I use e.g. the L16 codec (factory) and send out an
> INVITE, then the media endpoint puts all supported codec
> configurations into the SDP media description. Is there any
> way to restrict the set of codecs
> e.g. using the L16, it offers 44100, 8000 and 16000 Hz with
> one and two channels. But what if I only want to restrict it
> to L16/16000/1?
> (Or do I have to clone the L16 codec for the different
> possible setups and use only the one appropriate?)
> 2) I take it that using dynamic RTP payload types in the SDP
> media descriptions must be done in the codec just as with the
> fixed payload types and if there are 2 codec factories
> providing codecs with dynamic PT one has to take care himself
> of hardcoding the values properly to avoid both factories
> using the same PT?
> TIA
> Harry
>
> _______________________________________________
> Visit our blog:http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________ Visit our blog:
> http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
> _______________________________________________
> Visit our blog:http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________ Visit our blog:
> http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> _______________________________________________ Visit our blog:
> http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20141204/ac5f9074/attachment.html>
