Browsed by
Tag: message

Keep-alive

Keep-alive

In the field of SIP communication, there are two types of keep-alive mechanisms: device-level keep-alive and session (dialog) keep-alive.

Device-level keep-alive currently has mature and unified solutions that comply with RFC 3261, namely detection using the OPTIONS method. If the peer device returns a 200 OK response, the device is considered alive. Terminals can also detect device-level keep-alive using REGISTER requests.

Manufacturers have never had a unified solution for session keep-alive. Although RFC 4028 defines reINVITE and UPDATE for session keep-alive detection, these two operations are too complex for such purpose. They can trigger media renegotiation, which impairs call quality.

At present, manufacturers share basically the same idea: since normal reINVITE and UPDATE operations will trigger new media negotiation, can we use them without SDP directly for session keep-alive? Of course, reINVITE is an exception: reINVITE without SDP has already been used in the 3PCC procedure, so it can no longer be used for session keep-alive.

Based on our experience in interconnecting with equipment from various manufacturers over the years, we summarize the following operations for session keep-alive:

  • UPDATE without SDP
  • INFO without SDP
  • MESSAGE without SDP

Default behavior of the latest version of miniSIPServer:

If the above three types of SIP messages are received during a session, the server will enter the session keep-alive processing flow. If the session exists, a 200 OK response will be returned.

UPDATE and INFO can only be transmitted within a session by nature, so they inherently meet the requirements of keep-alive. We recommend using INFO first, as it is explicitly defined in RFC3261 and will definitely be supported by all manufacturers’ equipment. In contrast, the UPDATE method is defined in a supplementary specification. Some manufacturers’ equipment may not support UPDATE, let alone UPDATE without SDP.

MESSAGE can be transmitted both within a session and outside a session, and is used to deliver instant messages. We restrict MESSAGE without SDP to be transmitted only within a session and reserve it for the session keep-alive process.

Send or receive instant messages

Send or receive instant messages

The latest version of miniSIPPhone is released today to support two key features: (1) Contact, and (2) Instant messages.

It has a new window to create and manage contact list like belowing:

miniSIPServer contact list

In the contact window, you can select the target user and double click it to make a call out, or you can press ‘C’ key or click ‘Call’ button to do that.

If you want to send instant messages, you can select the target user and press ‘M’ key or click the ‘Message’ button, then you will get instant messages’ windows:

Instant message window on Windows system
Instant message window on Linux system

One instant message window is used for one user. Each window has three areas: (1) Display area. It displays both incoming messages and outgoing messages. (2) Input area. You can input the instant message content here, and press ‘Ctrl+Enter’ keys to send the message out. (3) ‘Send’ button. Click it to send the message out.

At this time, miniSIPPhone uses SIP-MESSAGE to send and receive instant messages, and can only support plain text messages, so you cannot insert images, files, audios and videos into the messages.

Of course, miniSIPPhone can run on Windows system and Linux system (including AMD64 and ARM64). In fact, the users in above figure run miniSIPPhone on different systems.

Hope you can enjoy it. 🙂

Why I cannot receive voice mail?

Why I cannot receive voice mail?

When some customers use miniSipServer cloud ( for local minisipserver, the same) to process their voice mail, but they are often confused why cannot receive voice mail in their email box.

In fact, we have an online document to describe how to use voice mail feature. Please refer to:

http://www.myvoipapp.com/docs/mss_services/voice_mail/index.html

For MSS cloud, there is a little difference. First, MSS cloud doesn’t support MWI (message waiting indication), so it can only send voice messages to your email address. Sometimes, customers often forget to configure SMTP server information which is necessary for MSS cloud to send your voice mail, or they often forget to cofigure email address of specific extensions.

So let’s describe more details about these. Before this, I assume that you have signin into your MSS cloud account. If not, please sign-up one.

Step 1: configure SMTP server information

smtp configuration in mss cloud system

Please look at the figure. You need click “system information” linker, then fill your SMTP information there. By the way, for Gmail accounts, they are always required to configure secure connection.

If SMTP information are all right, MSS will use it to send voice mail.

Step 2: configure email address of extension

configure email address of extension

Please click “local users” linker and select or add one extension to edit. For voice mail feature, you must configure “eMail address” to make MSS cloud know where the voice mail should be sent to.

Of course, you also need configure “voice mail” service right to this local user / extension.

So after that, for no-answer incoming calls, MSS will prompt the caller party to leave messages and save/mail them to the user’s email address.