Custom Query (2195 matches)
Results (1 - 3 of 2195)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#3 | worksforme | TLS support | bennylp | bennylp |
Description |
Implement TLS support for PJSIP |
|||
#50 | worksforme | Explicit use of transports | bennylp | bennylp |
Description |
BackgroundThe rules regarding transports are quite complicated with SIP, so because of this, it was decided during design that transports are managed automatically by the stack. This has benefit that application doesn't need to care about transport complexities, such as transport resolution, establishing/tearing-down transports, associating transport with destination, etc. With this approach, application should only need to care about the URI, and the stack will manage the transport to be used for that URI automatically. This approach works fine for typical applications. However, some unusual applications need more refined control on the transport, e.g. they want to be able to use specific transport to send outgoing messages. More over, the current transport design also has a limitation that currently only one transport type can be used per application. If application creates (for example) more than one UDP transports, the second one simply will not be used to send outgoing requests, although it can receive incoming requests. The reason why the second transport will not be selected is related to how transports are stored in the transport hash tables. Currently, transports are hashed by their transport-type and remote address. So everytime the stack needs to send SIP message to remote destination, it looks up the transport hash table using the transport-type and remote address as the hash key. Because of this, there can only be one transport registered per one transport type and one remote address (note that connection-less transport such as UDP will register 0.0.0.0:0 as its remote address) Proposed ChangesThe proposed changes to the transport framework should support the following requirements:
A potential solution may look like this:
|
|||
#78 | worksforme | Noisy audio with upsampling in the conference bridge | bennyp | bennylp |
Description |
There are two problems here:
For the first problem: The following file was upsampled with pjsua, from the original WAV file of 22050 Hz to 44100 Hz. You can hear clearly about the noise: http://www.pjsip.org/tmp/upsampling-noise.wav For the second problem: The following file was recorded by mixing two 16KHz sources and upsampled to 44.1KHz: |