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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20141203/21ae4246/attachment.html>
