Le 13/01/2011 15:00, Sa?l Ibarra Corretg? a ?crit : > > RFC2833 defines telephone-event as a dynamic payload type (section > 4.4) thus it should work fine with any number >=96. If it doesn't, > then the other endpoint is probably doing something wrong. > Of course, but we have to be pragmatic... If google voice which is widely used AFAIK in US does not handle it properly, I have to change it in my app or provide a way to user to use a "compatibility" mode. My point is *not* to change 96 is pjsip. Specifying 101 in config_site.h works, so that's just fine ! And even it's better to keep 96 in pjsip. The only thing that we could ask for is something somewhere in the documentation warning pjsip/pjsua users that they have to be aware of the fact some sip providers misbehaves with the default setting. My remark was more about the fact with the current definition of "dynamic" RTP types we can run out of numbers very quickly (all the more so as an application decide to set telephony payload type to 101... and even worse if the application decide to set it to 127 !!!! ). So I was asking if it could not be done dynamically at SDP build time. Each codec that does not have an already defined payload type in sdp would raise as payload type some special type "DYNAMIC" and then it's up to pj to build the sdp and giving a correct dynamic payload type starting from 96 and excluding DTMF payload type... Just a thought, I have absolutely no idea whether it's possible or not. As for my use case, I'll just modify type.h and exclude unused codecs (the ones I don't build with the app). Was just to warn about that, cause I fear it will become a problem (with video codecs, and with the fact some pragmatic apps will have to set telephony events to 101).
