Custom Query (2195 matches)

• generation of SDP
  • how codec can put codec specific info in SDP?
• codec specific SDP negotiation, if any
• applying parameters in SDP to the codec

TODO:

1. add video SDP generation in pjmedia_endpt_create_sdp()
2. add video stream info generation from SDP in pjmedia_stream_info_from_sdp()
3. add codec specific negotiation, perhaps sdp_neg.c should have external format negotiation mechanism to handle format specific negotiation, e.g: H26x picture resolution negotiation, this negotiation result will be applied to codec param (for stream in opening the codec)
4. add auto-assignment mechanism for dynamic payload type (in endpoint when creating SDP?), currently, the space for hardcoded dynamic payload type is very tight (or even not enough for video formats)
5. auto apply (or at least validate) SDP fmtp setting to codec param (or the other way around?), e.g: when SDP fmtp setting in codec is set to "CIF=1" codec param should be set to "size=352x288 & fps=30/1.001"
6. add video capability to simpleua to test video stuffs on real SIP application

If STUN packet is equipped with MESSAGE-INTEGRITY, and if the packet size is larger than certain limit, the packet may be corrupted during MESSAGE-INTEGRITY calculation before transmission.

The corresponding ticket for 1.0.x branch is ticket #837

This is duplicate of ticket #836 for the 1.0.x branch

Requirements:

• Desktop platforms:
  • Get SILK SDK 1.0.8 or 1.0.9 FLP/FIX (floating/fixed point version) from ​here (it's no longer there, so perhaps try ​here).
• Mobile platforms:
  • iOS:
    • Get SILK SDK 1.0.8 ARM version from ​here
  • Android:
    • Get SILK SDK 1.0.8 or 1.0.9 FLP/FIX

How to build:

• Windows platforms:
  1. Build SILK SDK (the FLP version is recommended) using SILK provided VS2005 & VS2010 solutions. The output library, i.e: SKP_Silk_FLP_Win32_debug.lib for debug mode and SKP_Silk_FLP_Win32_mt.lib for release mode, will be in the SILK "src" folder.
  2. Add include and library path for SILK in the Visual Studio settings. For example, the include path should point to SILK "interface" folder and the library path should point to the SILK 'src' folder.
  3. Define SILK codec support in pjlib/include/pj/config_site.h:

     #define PJMEDIA_HAS_SILK_CODEC		    1
     

• Makefile based platforms:
  1. Run make in the SILK SDK directory. Note for iOS/Android platform: modify Makefile to use the correct iPhone SDK/Android NDK version and compiler if necessary.
  2. Run PJSIP's configure script with the option --with-silk=your_silk_sdk_flp/fix_dir

Seems that this is caused by transport manager failure in looking up existing transport in transport hash table. As the the sockaddr (address of remote target) is used as the key in transport hash table, any inconsistencies in sockaddr structure may cause PJSIP to fail to find matching transport.

Found that some new APIs don't set sin_len member of sockaddr to zero. By convention, this sin_len member must be set to zero by PJLIB.

This symptom may also occur on any platforms that has sin_len member in sockaddr, e.g: BSD family.

Reported that on SIP TLS transport failure caused by TLS verification error, the socket descriptor is not released, so after several (auto) re-registration attempts, the application will run out of descriptor and getting error such as "Too many open files".

When calling pjsip_resolve() on an IPv4 address, we will return both the IPv4 address and its synthesized IPv6 address (if any).

Note that since pjsip_resolve() has no information of the NAT64 mode nor the bound transport, it will still return the IPv6 address.

See also ticket #1976.

Since 0.7.0, when TLS transport is being used, PJSUA-LIB will generate "sips:" URI scheme for the Contact header.

This causes OpenSER-1.1.0-tls to fail to forward any requests to the user agent. The remote agent will receive this status code:

SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)

while OpenSER log shows these log messages:

11(1062) ERROR: uri2proxy: bad transport  for sips uri: 3
11(1062) ERROR:tm:t_forward_nonack: failure to add branches

According to ​http://openser.org/pipermail/users/2007-February/009417.html, this is caused by OpenSER only accepting transport=tcp URI parameter when sips: is used.

As mentioned in RFC3711 5.2 & RFC4568 6.2.

The pjsua will always restart the media transport whenever media description gets updated, e.g: SDP renegotiation in re-INVITE or UPDATE, hence the SRTP state will also get restarted, which is not desired, e.g: the ROC (Roll Over Counter) of SRTP state may get out of sync.

Symptom

Log line:

Transport send_rtp() error: replay check failed (index too old) [err:259809]

Analysis

In updating media in both call hold and unhold, stream (or video stream) is destroyed and recreated. Before stream is destroyed, pjsua always saves last transmitted RTP seq number & timestamp, and pass them back to the new stream, so outgoing RTP will have continued seq number & timestamp.

Unfortunately for video, when call is on hold, currently no RTP frame will be sent, so both values last transmitted RTP seq number & timestamp are zero, and pjsua saves them when video stream (of a call hold) is destroyed. When a new video stream is created (for call unhold), the zero values will be used to initiate it. This will make outgoing RTP seq number restarted/discontinued, and a restarted RTP seq number will upset SRTP.

In audio stream, normally there are still some outgoing RTPs (for keep-alive) when call is on hold, so the issue may not appear on audio stream.

SRTP library initialization is currently performed by pjmedia_transport_srtp_create(), it is reported that the initialization will cause about 1 sec delay to the first time call. So moving the SRTP initialization to pjsua-lib may reduce/solve the first time call delay issue.

Tag 0 (in SDP crypto attribute) is valid, so it shouldn't be rejected. However, we'll keep the existing behaviour to generate SDP crypto tag starting from 1.

The corresponding ticket for 1.0.x branch is #903

This is duplicate of ticket #862 for 1.0.x

SRTP session creation will return failure after the (PJSUA-LIB or PJMEDIA) library is shutdown and reinitialized without quitting the application. This is due to the use of static variable which is not reset during shutdown/reinitialization.

This will cause PJSUA-LIB to unable to make new call with SRTP enabled.

When a sender sends packets intensively to a receiver that has packet processing rate lower than the sending rate, the packet will be buffered by PJLIB SSL socket and after sometime the sender will get PJ_ENOMEM error and eventually drop the connection while there are still some pending outgoing packets in PJLIB SSL socket. Application cannot trace which packets have been sent and which packets are still pending (buffered in SSL socket).

After investigation, when sending buffer is full, any sending operation will still write to OpenSSL BIO while it should not, it should simply return error, e.g: PJ_ENOMEM. After sometime, it somehow cause OpenSSL to initiate SSL renegotiation and when renegotiation fails (e.g: due to timeout), SSL connection will be dropped.

Thanks Peter Koletzki for the report.

Reported that timeout setting is not used in the ssl_sock_symbian.cpp.

Certain SSL backend implementation, e.g:OpenSSL has feature to enable/disable protocol used. In case of OpenSSL, using SSLv23_method will enable SSLv2-TLSv1.2. Since SSLv2 and SSLv3 are outdated, it will be useful to disable those. This ticket will enable app to specify the protocol used as a combination of pj_ssl_sock_proto value and eventually force client to use the protocol.

Thanks to Thomas Haremsa for the suggestions.

Objective:

To create a portable SSL/secure socket abstraction in PJLIB and to rewrite the SIP TLS transport in PJSIP.

Specifications:

1. General:
   • supports client and server socket operations (note: Symbian's CSecureSocket only supports client sockets)
2. I/O:
   • asynchronous I/O API similar to PJLIB's ​Active Socket API
   • timeout setting for SSL negotiation
   • buffer size control
3. Options:
   • select SSL version to use (SSLv23, TLSv1, etc)
   • select ciphersuite to use
   • verify server's certificate (note: not available on Symbian)
   • server require client certificate (note: not available on Symbian)
   • verify client's certificate (note: not available on Symbian)
   • TLS server name extension to support connecting to multihosted TLS server (note: only available on recent OpenSSL versoins)
4. Certificate management (note: not available on Symbian):
   • specify which certificate to use
   • load the certificate, either from file(s) or OS's certificate store.
   • retrieve certificate infos.

Backends:

1. OpenSSL
2. CSecureSocket on Symbian

The padding rule difference for string type attributes (notably SOFTWARE or SERVER-NAME attribute) between RFC 3489 and RFC 5389 causes our request to be rejected by RFC 3489 compliant STUN servers. This will cause requests to time out.

See ticket #960 for more info

When ICE session is active, STUN keep-alive packet will cause error similar to this:

icstr00C885A8 STUN keep-alive request failed: STUN transaction has
timed out (PJNATH_ESTUNTIMEDOUT)

When STUN transaction completes with timed out, memory leaks occurs because the request message is not freed in STUN session.

pjsua_core::resolve_stun_server                                             .... Ignoring STUN resolution failure (by setting)
  pjsua_core::pjsua_resolve_stun_servers
    pjsua_core::resolve_stun_entry                                          .... Trying STUN server IPv4 (1 of 1)
      stun_sock::pj_stun_sock_create
      stun_sock::pj_stun_sock_start
        srv_resolver::pj_dns_srv_resolve                                     .... Starting async DNS A query_job 
              resolver::pj_dns_resolver_start_query                              .... Picked up DNS A record from cache, ttl=616663478
                stun_sock::dns_srv_resolver_cb /* called sync. since DNS record is cached*/
              stun_sock::get_mapped_addr
                    stun_session::pj_stun_session_create_req
                    stun_session::pj_stun_session_send_msg                        .... Error sending STUN request: Network is unreachable
                      stun_transaction::pj_stun_client_tsx_create                 .... STUN client transaction created
                          stun_transaction::pj_stun_client_tsx_send_msg               .... STUN sending message (transmit count=1)
                            stun_transaction::tsx_transmit_msg                        .... STUN error sending message: Network is unreachable
                          stun_session::pj_stun_msg_destroy_tdata
                            stun_session::destroy_tdata                               .... tdata 0x1030f24a8 destroy request, force=0, tsx=0x1030f2630
                              stun_transaction::pj_stun_client_tsx_schedule_destroy   .... STUN transaction  0x1030f2630 schedule destroy
                    stun_sock::sess_fail                                          .... Session failed because STUN Binding request failed: Network is unreachable
                      pjsua_core::test_stun_on_status                             .... STUN resolution failed: Network is unreachable

/* pjsua_resolve_stun_servers Loops for 64 sec before Timeout */
 stun_sock::pj_stun_sock_destroy                                                  .... STUN sock 0x103022e28 request, ref_cnt=3
   stun_session::pj_stun_session_destroy                                   .... STUN session 0x102918228 destroy request, ref_cnt=3

The issue is caused when DNS resolution (pj_dns_srv_resolve() ) in pj_stun_sock_start() returns synchronously and the DNS resolution callback has been called. However, there is currently no mechanism to propagate the error from inside the callback to stun_sock, thus pj_stun_sock_start() will always return PJ_SUCCESS. This causes pjsua STUN server resolution to continue waiting until it times out.

(Note that this issue first appears because of ticket #1962, which directly returns without setting any error status after synchronous failure, to prevent double destruction.)

Thanks to Imad Khazali for the report and analysis.

The bug causes the string attribute to have zero length. This was introduced by changeset r4615

Create SWIG specification to create JNI wrapper for the new high-level object oriented API.

Create SWIG interface for creating Java, Python, C#, etc bindings for PJSUA-LIB.

Sample exception message:

Swig::DirectorException: No enum class org.pjsip.pjsua2.pjsip_tsx_state_e
                         with value 377750600

SWIG requires C++ enum data to have a valid value so it can be correctly mapped to Java enum object. Unfortunately some PJSUA2 C++ objects do not initialize basic type data member (including enum) in its constructor and such uninitialized data member may have an invalid value, so when SWIG needs to map an invalid C++ enum value to Java, exception occurs.

Kazuhiko Yoneda for the report and the patch.

This is a continuation of #2121.

There has been a report which is suspected to be similar issue as described in the above ticket. So we decided to initialize any enum fields in PJSUA2 objects (except ones for callbacks which should be initialized by the callbacks).

When --null-audio option is given to pjsua (equal to calling pjsua_set_null_snd_dev() PJSUA-LIB API), the second call will fail because PJSUA-LIB is trying to query the sound device.

This only happens when there is no sound device installed in the system.

This is duplicate of ticket #698 for the 1.0 branch.

Not all STUN failure responses can be authenticated, see this link for discussion: ​http://www1.ietf.org/mail-archive/web/behave/current/msg02312.html

When STUN request include MESSAGE-INTEGRITY attribute, the response (success or error) MUST be authenticated, according to RFC 3489bis-06.

Some responses however cannot be authenticated, since by definition they cannot contain MESSAGE-INTEGRITY. This currently is not in RFC 3489-bis, so I decided to disable authentication for the following error codes until the draft is clear about it:

     401 (Unauthorized)
     432 (Missing Username)
     434 (Missing Realm)
     436 (Unknown Username)
     431 (Integrity Check Failure) 

Scenario:

1. A calls B
2. A sends re-INVITE and immediately sends BYE (before receiving final response for the re-INVITE)
3. A receives 200/BYE, call disconnected both sides
4. A receives 200/INVITE and the retransmissions as A doesn't send ACK.

In this case, A should send ACK to complete the re-INVITE transaction, as described in ​rfc5407 appendix-B:

   As is mentioned above, the dialog and the
   transaction behave independently each other.  Therefore, the
   transaction handling has to be continued even though the dialog has
   moved to the Terminated state.

Thanks Itay Bianco for the report.

The RTCP framework should send RTCP RR when it's not transmitting anything.

Currently the transmission of RTCP was driven by transmission of RTP, so when an endpoint is only actively listening (and not sending anything, although stream direction is send-recv), then no RTCP packet is sent.

Send RTCP SDES containing CNAME when stream is created, and RTCP BYE when stream is destroyed.

For UDP, the spec says that server MUST send the response from the same address where the request was received (​RFC 3581 Section 4). However, in case the server is violating this spec, PJSIP would send the UDP keep-alive to the source address of the response instead.

This ticket fixes this behavior so that the keep alive will be sent to the original request address instead.

Thanks Fredrik Hansson for the report.

When pjsip_inv_session sends an ACK, incorrect pjsip_event is emitted, containing the RX data event of the 2xx/OK response instead.

When ACK target is a hostname and it is resolved to multiple IP addresses (in reported scenario, IPv6 and IPv4 addresses), only the first IP address will be used, and it won't retry with other IP addresses when it fails.

This is because stateless_send_transport_cb() function in sip_util.c for some reason will stop retrying next server if there is no sending callback specified. While the ACK sending does not define any callback, note that sending ACK does not use transaction mechanism.

Thanks to Anthony Alba for the report and the analysis.

Reported that there is a case that sending REGISTER will always fail because regc->has_tsx value is always equal to PJ_TRUE and it is never changed, here is the detail:

1. when sending SIP REGISTER message, pjsip_regc_send() will first set regc->has_tsx to PJ_TRUE then invoke pjsip_endpt_send_request().
2. pjsip_tsx_create_uac() fails and callback specified in pjsip_endpt_send_request() param, i.e: regc_tsx_callback(), is not called.
3. Unfortunately, the callback is the only place where regc->has_tsx will be resetted to PJ_FALSE.
4. Any future calls to pjsip_regc_send() will return PJ_EBUSY as it thinks there is an outstanding transaction (represented by regc->has_tsx == PJ_TRUE).

Thanks Fredrik Hansson for the report and the fix.

App needs to be able to use on_call_tsx_state callback to monitor the on going re-INVITE and send immediate re-INVITE.

Add PJSIP API to send raw data using PJSIP transport.

Some UAs may send video RTP packet with size > PJMEDIA_MAX_MTU, this will cause the packet get discarded. A simple solution will be increasing PJMEDIA_MAX_MTU, however this will cause our outgoing RTP packet size will get increased too, which will introduce another issue, e.g: when sending video to other UAs that expects 'normal' MTU. So outgoing and incoming packet size settings should be separated.

Thanks Arkadiusz Wronski for the report.

This ticket implements support for integrating third party media stack into PJSUA-LIB. By following these steps below, application can use third party media stack to perform audio and video functionality while still making use of the full SIP, NAT, and security (including SRTP) features provided by PJSUA-LIB API.

By disabling PJMEDIA, the following features will not be available in PJSUA-LIB (unless the equivalent implementation is provided by the third party media library):

• sound device management
• echo cancellation
• codecs
• jitter buffer
• RTP and RTCP
• WAV playback and recording
• conference bridge
• DTMF with RFC 2833
• and so on, except explicitly mentioned below

The following features will still be available:

• all SIP features, including SIP registration, etc.
• SDP and SDP negotiation
• NAT traversal features (including ICE)
• security features including TLS and SRTP
• media transports

Follow these steps to integrate third party media library with PJSUA-LIB:

1. Declare this in pjlib/include/pj/config_site.h:

   #define PJSUA_MEDIA_HAS_PJMEDIA    0
   

   to exclude PJMEDIA specific implementation from PJSUA-LIB library. Understandably you will loose all media features in PJSUA-LIB (this will be handled by your third party media stack).
2. Also copy suggested settings from pjsip-apps/src/3rdparty_media_sample/config_site.h into pjlib/include/pj/config_site.h. These settings are mostly used to exclude unneeded media components from the link process.
3. Build the libraries, but this time using

   $ make lib
   

   instead of just make or make all. This is because most samples will no longer build due to missing media in PJSUA-LIB, hence normal make will fail on these apps. The make lib command only builds the libraries and unit tests for the libraries.
4. Go to directory pjsip-apps/src/3rdparty_media_sample. This is a sample application with hook points to integrate third party media library. Fill in the media implementation in the alt_pjsua_xxx.c files, following the "TODO" notes. Run make to build the application. Once it's built, run alt_pjsua just as you run the usual pjsua application (it's essentially the same app!).

Known issues:

1. Session Timer should be more tolerant when receiving 'bad' 2xx response: with SE less than Min-SE (currently, Session Timer will hang up the call). The complete report (and log file showing the case) can be found in ​mailing list thread.
2. Processing response 200/INVITE in mod_inv_on_rx_response() may cause problems when there is forking.

From rfc4028: At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE [3] request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.

At the moment, the BYE message is only sent when refresher's UPDATE response is 408/481.

This ticket will add support to set video codec param using PJSUA2 API.

Example of use:

  /* MyApp.ep is the Endpoint instance */
  VidCodecParam codecParam = MyApp.ep.getVideoCodecParam("H264");    		
  MediaFormatVideo newFormat = codecParam.getEncFmt();
  newFormat.setFpsNum(30);
  newFormat.setFpsDenum(1);
  codecParam.setEncFmt(newFormat);
  MyApp.ep.setVideoCodecParam("H264", codecParam);

Unless thread priority of master port is set to a high priority, media flow controlled by master port is easily disturbed, for example when one switch the focus to other application window.

So with this ticket, master port worker thread priority is set to highest value by default. If this is not desired, application can specify PJMEDIA_CLOCK_NO_HIGHEST_PRIO flag when creating the master port (or the clock object).

The original report can be found ​here.

Issues reported:

• codec description pool in codec manager is released before the new setting is copied, this causes problem when the new setting contains data (e.g: fmtp strings) that is allocated using that pool,
• dec_fmtp is copied twice, one of them should be enc_fmtp instead.

Setting to control the port range which the HTTP client should bind to. Useful for traversing strict firewall rule.

As reported by Igor Kravets in the ​mailing list, there has been sharing and assertion problems with the native ALSA support in pjsip. The assertion looks like something like this:

../src/pjmedia/conference.c:1795: get_frame: Assertion `frame->size
 == conf->samples_per_frame * conf->bits_per_sample / 8' failed.

Thank you Dan Arrhenius for the fix.

Currently the sound device is kept open in PJSUA-LIB even when nothing is flowing in the bridge. This is not too friendly for other applications since they may not be able to use the sound device when pjsua is running, but also it drains up battery power in mobile devices.

PJMEDIA object will be given object signature. This is needed for the event framework so that application can at least distinguish the sender of the event.

Silence detector seems to switch a lot when level is close to maximum silence level.

A simple DNS server class with DNS A and SRV records support, mostly to be used by various internal test units.

Develop a really simple GUI app as proof of concept that the video API works

A simple HTTP client implementation will make way for XCAP client implementation.

Specifications

Assorted specifications:

• Supported HTTP method(s):
  • GET
  • PUT
  • DELETE
• Asynchronous:
  • application create/build the HTTP request
  • the request is submitted
  • application will be notified when the request is complete and complete response has been received.
• Application may cancel the request once it has been submitted
• Options:
  • request timeout support
  • ability to add custom headers
  • HTTPS (optional)

If account is enabling NAT64 in its config, trying IPv4 STUN resolution is not necessary and may cause unwanted delay.

Note: the fix in this ticket doesn't affect STUN resolution that is not initiated by an account or a call.

Modifications below to make the API more usable:

• add account ID to on_pager2() callback
• add account ID to on_pager_status2() callback
• add new callback on_typing2() with additional arguments

Currently the PTIME for L16 codecs are set to either 10 or 20 ms. There are few problems with this:

1. packet may be too large for the MTU
2. we will not be able to receive incoming frames with size smaller than our PTIME. This can happen because theoretically one L16 frame can consist of as few as 1 sample.

Some changes that can be done to fix this:

1. Give the ability for the application to specify PTIME on per L16 codec basis.
2. Add buffering in the codec. So while the PTIME settings is mandatory in pjmedia framework and it will be used to control the size of outgoing packet, the codec should be able to receive frames with less than PTIME samples. And it does this by buffering the incoming frame if it has less than PTIME samples.

Always re-initializing the media on call refresh can be annoying, especially for a call with video as video re-init may take several seconds.

Thanks Matynka Bartosz for the feedback.

Add socket constants abstractions for socket TOS options so that application can set TOS in portable manner.

Thanks Roman Puls.

A soft deadlock will occur in the following scenario:

The corresponding ticket for 1.0.x branch is ticket #875.

This is a duplicate of ticket #874 for 1.0.x branch.

Reported by some users, e.g: ​here and ​there.

Currently the 100rel module (sip-100rel.c) does not handle forking. This caused problem such as no PRACK is sent because the second reliable provisional response contains RSeq not matching previous RSeq.

The sound device is opened when call is initiated. When the call fails to connect, the sound device is not closed by the library.

AMR negotiation requires to have these params exactly matched: octet-align, crc, robust-sorting, interleaving, and channels.

It was hardcoded to 320 bytes (160 samples) regardless what mode the speex operated (NB, WB, UWB). This worked well since the get_frame() of stream did't modify the frame size (to the returned frame size from speex decoder). But, the new jitter buffer, which does the decoding, suffers from this wrong decoded size.

Upgrade Speex to latest version (may require large modification due to new Speex library organization). Probably we should have autoconf option to allow using external speex library as well.

Re multiple frames: PJMEDIA can receive and decode multiple audio frames in one RTP packet, the sending side currently seems to be broken. It can send multiple G.711 frames okay, but from last testing, sending/receiving multiple Speex frames doesn't work.

Reduce the stack usage since it caused stack overflow on Symbian phone with default stack size (8KB).

Also reduce the pool usage (avoid to use 4000 bytes blocks) and make the pool size configurable.

Currently when UDP media transport is created and attached, read operation is started immediately. Unfortunately, when remote starts sending RTP packet in the beginning of a call (especially when local is the SDP offerer), local stream may not be ready yet, so some initial inbound RTP packets will be read by the transport but then simply discarded as no stream is attached to the transport yet.

This ticket will change the behavior so read operation is started when pjmedia_transport_media_start() is called. So any incoming packet will be buffered by OS until read operation is started. This should be able to reduce missing video keyframe packets (or generally any initial RTP packets) as pjmedia_transport_media_start(), which starts read operation, is called after stream is instantiated.

When sending initial INVITE fails due to network failure (for example, setting iPhone iOS to AirPlane mode, or network is down), the on_call_state() callback will be called twice: first with PJSIP_INV_STATE_DISCONNECTED, then followed by PJSIP_INV_STATE_NULL.

This may cause unexpected state transition in the application. With pjsua for example, it causes the call to be set as active call when there is no other call.

Thanks Kees van der Bent for the report.

Sample cases:

• Session timer is recommended to use UPDATE to update session.
• Prefer to send UPDATE upon receiving SDP answer with multiple codecs/formats.

When TCP/TLS transport is being destroyed, they cancel all pending transmissions on the transport. This cancellation may in turn cause pjsip_transport_dec_ref() to be called, which may register an (stray) idle timer for the transport. Since the transport pool will be released right after that, the timer entry pointer will be invalid and it will crash the program if the timer heap is trying to access the entry.

This scenario could only happen during program shutdown sequence, as the (hard) destroy routine must not be called on normal situation (the graceful shutdown must be called instead), and this only matters in Symbian since only Symbian timer heap has stray timer cleanup routine, and only if ticket #1035 is not applied.

We have three options here:

1)
    SetActive();
    RSocket.Recv();

2)
    RSocket.Recv();
    SetActive();

3)
    RSocket.Recv();
    if (iStatus == KRequestPending)
      SetActive();

The correct option seems to be no 2.

The report can be found ​here.

Tested on Windows.

To reduce the number of SUBSCRIBE's sent to network (to refresh buddy's subscription when previous SUBSCRIBE failed), PJSUA-LIB will now initiate outgoing presence subscription when it receives incoming SUBSCRIBE from the buddy.

When subscription is established by call transfer (or REFER), the authentication challenge is handled by invite module, so when evsub module tries to process the challenge (again), it will fail and subscription will be terminated.

Similar issue was reported in #2164, however the patch does not work if the subscription is established by call transfer.

Thanks to Mikhail Morozov for the report.

Based on the ​RFC 3265:

A NOTIFY request is considered failed if the response times out, or a non-200 class response code is received which has no "Retry-After" header and no implied further action which can be taken to retry the request (e.g., "401 Authorization Required".)

However, our current implementation terminates the subscription for ALL non-200 with no retry-after, even for 401/407, which shouldn't be the case.

The registration and SUBSCRIBE refresh interval is calculated differently in IMS. According to 3GPP TS 24.229 specification:

The section 5.1.1.4 says: "Unless either the user or the application within the UE has determined that a continued registration is not required the UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less"

We can adjust audio device volume using ALSA mixer, such as shown ​here.

However, more study is needed before it's implemented:

• are the required components/APIs always available and supported by default?
• make sure to find the correct sound card name and id, if not using the default master sound card

DTLS-SRTP is an SRTP keying method that uses media channel for SRTP key negotiation which is secured using TLS. As SRTP key negotiation is done in media channel, confidentiality in SIP signaling is not required, but it needs SIP message integrity for authentication. Peer authentication is done by matching TLS certificate fingerprint (sent via SIP signaling) to actual TLS certificate received in DTLS-SRTP handshake (sent via media channel), so SIP message integrity will guarantee that the TLS certificate fingerprint is not altered from end to end.

DTLS handshake in DTLS-SRTP is basically very similar to TLS handshake, it is just done on UDP socket so it has retransmission mechanism and using a TLS extension for attaching SRTP keying materials (e.g: SRTP crypto profile and key).

Specification

• SDES (the only SRTP keying mechanism currently available in PJMEDIA) and DTLS-SRTP may coexist, any of them may be disabled (at run-time or compile-time).
• As currently best effort media encryption via SDP capability negotiation is not supported yet, it should be configurable which SRTP keying method to be used in generating offer. And for generating answer, it should detect and use the keying method used by the offer.
• Support DTLS-SRTP handshake before SDP answer is sent/received.

How to build

Requirement

1. OpenSSL version 1.1.0 or newer. DTLS with SRTP extension seems to be available since OpenSSL 1.0.1, but we haven't tried it ourselves.

Build

1. Set macro PJMEDIA_SRTP_HAS_DTLS to 1 in config_site.h:

   #define PJMEDIA_SRTP_HAS_DTLS 1
   

   To disable DTLS-SRTP, just set macro PJMEDIA_SRTP_HAS_DTLS to 0 (by default it is currently disabled). To disable SDES, set macro PJMEDIA_SRTP_HAS_SDES to 0 (by default it is currently enabled).

1. Build PJSIP with TLS enabled using OpenSSL backend.

Sample code for PJSUA app

Update: sample codes below have been deprecated in 2.8, please check #2100 for more info.

In generating SDP answer, SRTP will automatically detect and match the keying method to the SDP offer's, e.g: if remote sends offer using DTLS-SRTP, we will start DTLS nego immediately and answer using DTLS-SRTP too. However, in generating SDP offer, SRTP will use SDES by default. So to generate SDP offer using DTLS-SRTP, application needs to implement PJSUA callback on_create_media_transport_srtp and sets the priority of DTLS-SRTP higher than SDES from that callback, e.g:

void on_create_media_transport_srtp(pjsua_call_id call_id,
                                    unsigned media_idx,
                                    pjmedia_srtp_setting *srtp_opt)
{
    srtp_opt->keying_count = 2;
    srtp_opt->keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP;
    srtp_opt->keying[1] = PJMEDIA_SRTP_KEYING_SDES;
}

To enable only one keying method at run-time, just set keying_count to 1 and keying[0] to the preferred keying method from the same PJSUA callback, e.g:

void on_create_media_transport_srtp(pjsua_call_id call_id,
                                    unsigned media_idx,
                                    pjmedia_srtp_setting *srtp_opt)
{
    srtp_opt->keying_count = 1;
    srtp_opt->keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP; /* enable only DTLS-SRTP */
}

Limitation

This ticket will only implement the core part of DTLS-SRTP, i.e: SRTP key negotiation via DTLS, while DTLS-SRTP itself also depends on other features that we haven't supported yet:

1. SIP signaling integrity protection, this may be provided by any of these extensions:
   1. SIP Identity, specified by ​RFC4474 and ​RFC4916, only Authentication Service is needed.
   2. S/MIME, specified by ​RFC3261 section 23.
   3. SIPS, actually we already support this, but as SIPS can't guarantee that all proxies are trusted, the security provided by SIPS is considered weaker.
2. Best effort media encryption via SDP capability negotiation, to offer media channel with multiple configurations (e.g: offering SRTP but also accept plain RTP), this seems to be a ​MUST.

Behavior change

1. Media transport UDP can now be attached multiple times, any old attachment will be silently replaced by the latest. This change is done because DTLS nego needs to access the real transport (UDP/ICE) before stream is created (or SDP nego is completed). After SDP nego is completed, stream will invoke media transport attach() again.
2. Media transport UDP & ICE is equipped with auto-switching RTP/RTCP target address to the address it receives RTP/RTCP from, and there is probation period (i.e: 10 packets) before switching to the new target address, during this probation period all packets from the candidate target address will be discarded. Now those packets will be no longer discarded as long as we have not received any packet from the current known source address (if any). Without this change, any incoming 'TLS hello' will be discarded until probation period is reached or SDP answer is received (which tell us about remote RTP address).

Reference

• DTLS-SRTP framework: ​https://tools.ietf.org/html/rfc5763
• DTLS extension for SRTP: ​https://tools.ietf.org/html/rfc5764

Although there seem to be no standard that describes the feature specification clearly, it seems to be widely used. Having it implemented in the library should be practical, especially for PJSUA2 apps (note that there is already an implementation in pjsua sample app using PJSUA API). Thanks to David Wichter for the suggestion.

Considering that this is a proprietary feature (see ​here) and it may not be desirable on some system, e.g: SIP INFO message burst may introduce congestion on the network and may cause load spike on SIP server, the feature should be configurable and by default it is disabled.

This ticket will introduce pjsua_dtmf_method to specify the DTMF sending method.

PJSUA API
To send DTMF as SIP INFO:
Set pjsua_call_send_dtmf_param.method to PJSUA_DTMF_METHOD_SIP_INFO when calling pjsua_call_send_dtmf().

To get the notification of incoming DTMF:
Use on_dtmf_digit2() callback.

PJSUA2 API
To send DTMF as SIP INFO:
Set CallSendDtmfParam::method to PJSUA_DTMF_METHOD_SIP_INFO when calling Call::sendDtmf().

To get the notification of incoming DTMF:
Use Call::onDtmfDigit() callback.

This ticket will add support to FFmpeg 2.8 with these general modifications:

• Change FFmpeg const using 'AV' previx. e.g: PIX_FMT_NONE -> AV_PIX_FMT_NONE
• Change deprecated method avcodec_get_frame_defaults() -> av_frame_unref()

Application may keep using older FFmpeg version, i.e: the versions that are already supported before the changes in this ticket, by defining macro PJMEDIA_USE_OLD_FFMPEG in the build, e.g: adding this line in config_site.h:

#define PJMEDIA_USE_OLD_FFMPEG

Note: configure script (of GNU autoconf build system) will automatically add this macro when it detects that older FFmpeg version is being used.