Support for SIP SUBSCRIBE/NOTIFY in SIP plugin

[lminiero]

This pull request is part of a series of efforts aimed at improving the current state of the SIP plugin. In the next few weeks we'll publish more, as they're currently still in a testing phase and sharing them now would probably cause more noise than help. These new developments have been sponsored by a Colombian Company with 21 years of experience on developing Telecommunication Solutions.

As the title says, this branch implements support for SIP SUBSCRIBE, and the management of related SIP NOTIFY events. The syntax is relatively simple, and looks like this:

{
	"request" : "subscribe",
	"event" : "<the event to subscribe to, e.g., 'message-summary'>",
	"accept" : "<what should be put in the Accept header>",
	"to" : "<who should be the SUBSCRIBE addressed to>"
}

The only mandatory property is the event to subscribe to; what to put in the Accept header is optional, and if you don't specify a to we'll send the SUBSCRIBE to the user's identity (default behaviour).

The plugin doesn't care about the specific nature of the events, so the feature can be used for everything that works with SUBSCRIBE and NOTIFY. Here's a snippet of how that works with MWI:

Request:

{
	"request": "subscribe",
	"event": "message-summary",
	"accept": "application/simple-message-summary"
}

Events:

{
	"event": "subscribing"
}

{
	"event": "subscribe_succeeded",
	"code": 200,
	"reason": "OK"
}

{
	"sip": "event",
	"result": {
		"event": "notify",
		"notify": "message-summary",
		"substate": "active",
		"content-type": "application/simple-message-summary",
		"content": "Messages-Waiting: no\r\nMessage-Account: sip:asterisk@192.168.1.80\r\nVoice-Message: 0/0 (0/0)\r\n"
	}
}

Basically, when you subscribe you'll first get an event telling you we're going to send the SUBSCRIBE; then an event telling you if the SUBSCRIBE indeed succeeded; events after that will include the content of the NOTIFY messages (in this case, I didn't have any messages
waiting in my Asterisk setup).

Unsubscribing is just as easy:

{
	"request: "unsubscribe",
	"event": "message-summary"
}

Events:

{
	"event": "unsubscribing"
}

{
	"event": "subscribe_succeeded",
	"code": 200,
	"reason": "OK"
}

After that, no events for that package will be handled anymore.

As I was saying, the mechanism is flexible, so it can be used for different kind of subscriptions as well. This is how you'd subscribe to events from the conferencing package, for instance:

{
	"request": "subscribe",
	"to": "sip:88812345678@192.168.1.65",
	"event": "conference",
	"accept": "application/conference-info+xml"
}

To facilitate the integration with the conferencing package, we now detect the "isfocus" attribute as well, when available in the Contact header of an incoming INVITE or 200 OK. When it's there, we add an isfocus:true attribute in the call-related event: this way, you can use that as a trigger to, e.g., subscribe to the conference-info events when isfocus is there. Anyway, I never tested this so you may want to confirm it works as expected.

This should be all. From a few tests this seems to be working as expected, but I didn't test extensively, mostly because I don't have a complete SIP setup to play with. Please test and provide feedback.

[lminiero]

Merging.