Publisher: event state publication (RFC 3903, PUBLISH)

[neutrino38]

Why

JsSIP can SUBSCRIBE to an event package and NOTIFY one, but it cannot PUBLISH its own state (RFC 3903) to a presence server. Today an application has to build the PUBLISH request on the SIPMessage and RequestSender internals and handle the entity-tag cycle itself.

What

ua.publish(target, eventName, contentType, options) returns a Publisher, built like Subscriber:

const publisher = ua.publish('sip:alice@example.com', 'presence', 'application/pidf+xml');

publisher.on('published', response => {});        // every 2xx
publisher.on('terminated', (code, response) => {}); // final

publisher.publish(pidf);   // initial publication, or a modification
publisher.terminate();     // removal (Expires: 0)

• Lifecycle. Each 2xx carries a SIP-ETag, and later requests send it back in SIP-If-Match. Before expiry, the publication is refreshed with no body. The refresh is scheduled the same way as in Subscriber. terminate() sends nothing if nothing was published.
• One request in flight. A body given while a PUBLISH is pending is sent once the response arrives, so the entity-tag always names the last publication the server accepted.
• 412 (the server lost the entity-tag): the body is published again from scratch, once. 423: the PUBLISH is sent again with the given Min-Expires. Any other failure terminates the Publisher. terminated carries the response, so that 489, 405 or 501 can be told apart.
• Same Call-ID for every PUBLISH, increasing CSeq, as Registrator does for REGISTER.
• UA.stop() removes every publication before the un-REGISTER, so that watchers don't see a stale state until it expires.

Typings are in Publisher.d.ts and UA.d.ts, and C.PUBLISH is added.