[Home]

Summary:ASTERISK-00646: [request] implement SIP "PUBLISH" and "SUBSCRIBE"
Reporter:ulexus (ulexus)Labels:
Date Opened:2003-12-09 22:08:23.000-0600Date Closed:2004-09-25 02:04:39
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) draft-ietf-sip-publish-03.txt
( 1) publish.txt
Description:The PUBLISH-SUBSCRIBE SIP methods allow the function of the status LEDs on SIP phones such as the SNOM 200 to monitor other extensions, etc.



****** ADDITIONAL INFORMATION ******

Draft source:
http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-01.txt
Comments:By: Olle Johansson (oej) 2003-12-13 16:36:23.000-0600

Interesting. Could you please describe the expected behaviour, how this should be implemented?

By: ulexus (ulexus) 2003-12-15 12:24:13.000-0600

SNOM 200 sets have five LED-enabled soft keys.  These can be programmed to a number of things, but the most interesting to me (and my client) is to have extension status attached.  That is, the LEDs should show when the monitored extension is ringing, in use, or idle.  You should, subsequently, be able to optionally press the soft key if you see it blinking "ringing" and answer it (this would be a programming thing, not a PUBLISH/SUBSCRIBE thing).  This is most useful for an attendant or secretary, or possibly a boss monitoring or covering a secretary...  Anyway, it is a much-needed, standard PBX phone capability.

Basically, the PUBLISH and SUBSCRIBE SIP extensions are supposed to allow for this.

A phone can "PUBLISH" and update its state to a SIP proxy/gateway/whatever, and another extension can "SUBSCRIBE" to those published updates.  An example message and state flow is given in the ietf draft, and it looks pretty straight-forward.

Asterisk already keeps track of the channels states (I have heard IAX already has state communication), so I imagine it would just take implementing the protocol and translating it in chan_sip to whatever Asterisk-native functions show the status.

A simple setup is, you have a boss who wants to talk to the receptionist.  He looks at his phone and immediately sees that she is on the phone, because her LED is lit and red.  He glances at his phone again and sees the LED is off, so he punches the button and connects to the receptionist.

This could also be used, potentially for line/trunk status, so that you could make a system behave like a key system instead of a PBX.  This would be VERY useful for small offices which have just a few lines and a few people.

By: Olle Johansson (oej) 2003-12-15 13:23:28.000-0600

Ok, I see now. I'll download the draft an read it. Asterisk needs a general solution for notification, and today it's the manager interface. However, the manager API doesn't work that well with checking status of SIP channels as far as I know. Thinking freely this could either be integrated in Asterisk or developed as a stand alone software that checks status by using the Asterisk manager API and support PUBLISH/NOTIFY to the client. I have a SNOM 200 ordered, so I'm interested as well :-)

By: atacomm (atacomm) 2003-12-15 21:12:56.000-0600

I agree, I would love to have this ability.  The Snom 220 coming out in late February has the 5 buttons, plus three 20 button addon panels that can be daisy chained, allowing you to monitor upto 65 extensions on a receptionist phone.

In addition, the Snom has the ability to program those buttons for call park and intercom.  I'm not sure what SIP commands these use, but we should look at supporting them.

By: atacomm (atacomm) 2003-12-15 21:18:07.000-0600

As a note, I seem to remember these using NOTIFY as well.... SUBSCRIBE tells the server you want to monitor it, PUBLISH tells the server an event has occured, and NOTIFY is sent to the phones that have subscribed.  I was just looking through my SIP book on these, unfortunately it only lists them as proposed and not final.

By: Olle Johansson (oej) 2003-12-16 00:28:04.000-0600

It's still far from being a standard, it's only an IETF draft that can change a lot.

By: atacomm (atacomm) 2003-12-16 00:31:28.000-0600

Over half of SIP is a draft.  You can't get anywhere by not supporting the drafts, you will be 2 years behind the competition....not to mention lacking features that lots of people want and can get elsewhere.

By: maik (maik) 2003-12-29 21:16:54.000-0600

I would also love to have this feature. I also thought about implementing it as stand-alone app which uses the manager interface. But this can of course only be an interim solution. It should be integrated into the sip channel-driver.

The problem with the stand-alone app is that it won't receive the SUBSCRIBE messages because those are sent to *. You will have to send the NOTIFY messages to preconfigured IPs and I don't know if the phones will accept those messages.

Another thing is configuration. Of course not every phone should be able to see the status of every other phone. I think the best way to configure this would be to use the same system as pickup (callgroup and pickupgroup) with other variables of course :) .

By: Olle Johansson (oej) 2003-12-30 02:57:39.000-0600

There is some support for SUBSCRIBE already in the SIP channel. I can't figure out what it does, so please check this and comment here. See if this can be used as a base, before starting something new.

By: ulexus (ulexus) 2004-01-15 22:31:23.000-0600

It looks like that is the same type of communication protocol, yes.  It just has a different payload.

Right now, it looks like it is used for registration and voice mail notification, but it does not look very modularly accessible to my non-programmer's eyes.

By: theo (theo) 2004-01-24 12:10:38.000-0600

The Cisco 7914 expansion module (the side one with all the buttons on) allows for this also - however, only in SCCP, and i'm still pondering how best to get around it.  I think some sort of API is certianly needed in asterisk so we can monitor devices from other modules.  The following 'status' are used on the 7914 currently:

- Line available
- Line in use by you; you may also transfer the call
- Line in use by someone else
- Line ringing
- You have the call on hold
- Someone else has the call on hold

I'm going to try and get the 7914 working, so will have a play with an API to access/announce extension state changes, and see what i come up with.

By: Brian West (bkw918) 2004-01-24 12:17:47.000-0600

7914's will work at some point since chan_skinny and chan_sccp are going to merge and its going to get alot of love.

bkw

By: ulexus (ulexus) 2004-01-25 11:22:46.000-0600

So, in the SCCP driver, what structure/method is used to know which phones are registered to receive which phone's status information?

Also, is this done by the phone or by Asterisk?

Since it seems that Asterisk would have to keep track of the who's and the what's and the when's for the SIP implemenation, is there a storage structure and event structure already used for SCCP or IAX  which works in this manner?

By: atacomm (atacomm) 2004-02-20 12:41:25.000-0600

Are we anywhere with this request yet?  I'm tired of waiting, who wants to jump into coding this with me?

By: ulexus (ulexus) 2004-02-20 12:59:36.000-0600

I have heard of no progress.  I've been watching chan_sip2, but I have seen nothing over there, either.  IANAC, but it looks like people take a look at the SUBSCRIBE which is already there and either:
a) get scared off because it hard coded to specific tasks (i.e., voicemail notification).
b) presume that there exist already SUBSCRIBE and NOTIFY, so someone is working on it...

From a purely non-asterisk perspective, it doesn't look like there is that much to do.  The protocol is pretty clear and simple.  All we need is a place to store what goes where, who can request it (I don't care about security because all of mine are closed systems, but I'm someone does...), and the main thing for me, how to work with the call structures to check the statii of the subscribed channels in a non-invasive, lightweight manner (Although I'm sure to someone closely familiar with Asterisk, this is the most straight-forward item...).

By: atacomm (atacomm) 2004-02-20 14:43:46.000-0600

There are several things I'd like to see.  One, we need a uniform way of monitoring the status of phones... not just SIP.  Since Asterisk does protocol conversion, we should make sure there is a Subscribe/Publish event system at the core of Asterisk and a defined way to interact with each protocol layer.  This would let JerJer's SCCP implimentation and our SIP implimentation to work together.  It would be neat to monitor SCCP phones on a SIP phone, and it only makes sense.

Second, if you are on a multiple server system, it would be nice to be able to monitor the status of phones on each of the servers.  The Subscribe/Publish event system should be able to peer into peered servers to make that distinction.  For example, we are setting up * in an enviroment to act as as a SIP->IAX bridge, SIP on the LAN, IAX on the WAN.  The phones would connect to that server.  The problem is, you can't monitor the phones at your other facility then.  That is why I think there should be a way to peer across servers.

I think we should setup a small group just to study what needs to be done, and then do it, instead of kicking it around and letting every protocol do it its own way.

By: ulexus (ulexus) 2004-02-20 15:22:37.000-0600

Right you are.  That is exactly what should be done.  I guess part of the problem is that Asterisk completely separates the "extension" from the "equipment number", a higly useful feature, but it does make very esoteric the standard PBX's easy busy lamp field = equipment-in-use field.

That is, the extension number is what the user knows and is looking for, but the equipment number is what Asterisk knows and watches for.  They are completely divorced from each other.  An "extension" is never busy or idle, but the user has (and should have) no concept of the equipment number.

Basically, then, we need the equivalent of a reverse DNS on the equipment number, or a canonical name for the equipment number which can correspond to an "extension" label.  They should certainly be completely orthogonal, as they are now with DNS.  That is:
extension 101 may ring equipment numbers Zap/20 and SIP/tester, the extension label 101 must correspond to one and only one particular equipment number (like Zap/21 or a SIP host and line registration)

Is this a reasonable limitation?  Is there another setup that makes sense?
Does this hold true for call queues, etc.?

True that this is just the tip of the iceberg of a proper implementation, and I think you are definitely right that this should be much more a central feature with channel implementations that I had originally thought.

By: Olle Johansson (oej) 2004-02-20 16:30:21.000-0600

We have a problem in Asterisk here. The SUBSCRIBE currently subscribes/notifies on Asterisk extensions, not SIP accounts. It checks the dial plan for the subscriber after authentication and checks if the extension is available. In my case, this meant that everything in the whole world was available, since I matched every SIP address out there. My solution was to add a subscribecontext= to sip.conf that limited the scope to local extensions only (see chan_sip2.c in separate bug#).

So do you want to monitor other SIP users or Asterisk extensions or both? An extension doesn't really tell you if someone is talking or not. It is more general though, you could monitor any user in any channel this way.

So how do I enable this in my SNOM phone? I want to test.

By: Olle Johansson (oej) 2004-02-20 16:46:04.000-0600

As atacomm said, there's research do be done here. First, check the SUBSCRIBE that exists and see how to get it better. To do that, we need to investigate extension states (AST_STATE_*) in the core and see what happens with other channels.

Secondary, we need to see if we need to go below extensions, check states of users of *any* channel  (devices), maybe even on other Asterisk servers (over IAX2). For SIP, I would like to know if a user is registred or not, a status that is not available on an extension level. For dynamic hosts with qualification, we have a status 'UNREACHABLE" that is also interesting a state information - the device left the network.

--------------------
As a starting point, here's the states from channel.h:

/* Bits 0-15 of state are reserved for the state (up/down) of the line */
/*! Channel is down and available */
#define AST_STATE_DOWN          0
/*! Channel is down, but reserved */
#define AST_STATE_RESERVED      1
/*! Channel is off hook */  
#define AST_STATE_OFFHOOK       2
/*! Digits (or equivalent) have been dialed */
#define AST_STATE_DIALING       3
/*! Line is ringing */
#define AST_STATE_RING          4
/*! Remote end is ringing */
#define AST_STATE_RINGING       5
/*! Line is up */
#define AST_STATE_UP            6
/*! Line is busy */
#define AST_STATE_BUSY          7
/*! Digits (or equivalent) have been dialed while offhook */
#define AST_STATE_DIALING_OFFHOOK       8

THere's also device states:
/*! Device is valid but channel didn't know state */
#define AST_DEVICE_UNKNOWN      0
/*! Device is not used */
#define AST_DEVICE_NOT_INUSE    1
/*! Device is in use */
#define AST_DEVICE_INUSE        2
/*! Device is busy */
#define AST_DEVICE_BUSY         3
/*! Device is invalid */
#define AST_DEVICE_INVALID      4
/*! Device is unavailable */
#define AST_DEVICE_UNAVAILABLE  5

-------------------------------------
Device states that are notified in the manager interface are handled by channel.c.

By: atacomm (atacomm) 2004-02-20 16:50:25.000-0600

On the Snom 200 you go to the keymapping screen, and set the buttons to I beleive it is called Extension mode, or something like that.  Anyways, what it then asks for is the SIP url for that extension to monitor.

In this way, we maybe be able to do  IAX/username@server, and SIP/username@server.  However / is not a character recognized by the SIP specs....

By: atacomm (atacomm) 2004-02-20 16:56:15.000-0600

Overall this could lead to a few other changes as well.  For example in the dial plan, if you dial a phone that has multiple lines, and you are already on one call, it will ring, timeout, and return unavailable.  We need to correct the state to say to asterisk's sip stack, hey dummy, this user is on the phone.  Chances are its busy and not being ignored.  Otherwise it does no good to have a "Thank you for calling, I am currently on the phone" message in the voicemail when you have a multi-line phone!  That is one state issue that maybe having a centralized state management system would fix.

By: Olle Johansson (oej) 2004-02-20 17:08:56.000-0600

The routing of subscribe sip:username@domain is normally handled by a SIP proxy. However, Asterisk is weak in this regard. (Long story)...

For SIP, the extension is available until the outgoinglimit is exceeded. Many devices handle multiple connections. SUBSCRIBES for devices should really be handled by the device itself. And how do you handle authentication for that?

And then we have interoperability. SNOM usually follows standards (or drafts) quite well. Microsoft (Windows Messenger) doesn't. Anyone know how Cisco handles this?

Back to my question? Focus on extension, device or both? SIP SUBSCRIBE is watching extensions today.

By: atacomm (atacomm) 2004-02-20 17:16:58.000-0600

Device makes the most sense.  An extension could actually be setup to dial 10 different phones, and you don't need to know if the whole call center is on the phone.  You want to know if an individual is.

Thats where the state ability has to change for sure:
It does no good to monitor using Subscribe/Notify if the phone you are monitoring has 6 lines, if your phone doesn't light up for them being on the phone until all 6 lines are in use.  Thats a REALLY bad design.  

What I see is 2 states were combined that shouldn't have been, and maybe this can be a core change as well, which needs fixing in all protocol stacks.

A call state object should have two boolean values in my option (or something similar).

->bIsInUse
->bIsAvailable

Subscribe/Notify would always light up if bIsInUse==true.
This would also fix my voicemail issue, if bIsInUse==true, and bIsAvailable==true, it should still act busy.... but give you a chance to pick it up as call waiting.... so still dial, then on timeout decide why it timed out.

I think this is a core change, but a nessecary core change.  State monitoring needs some improvement.  I know other SIP session state data is currently not being stored, try showing a SIP channel's details, alot of it is hard coded to 0.

By: Olle Johansson (oej) 2004-02-20 18:23:23.000-0600

SIP is not really built for central control. You can't do this without a subscription to the actual device - someone else may place a call to the SIP device without bypassing the PBX...

So far, the ast_device_state is what we can control. A hack would be to implement a name space, like device_name@hostname for SIP peer 'name' and keep the name@hostname for SIP extension 'name'. I admit it's ugly.

By: Olle Johansson (oej) 2004-02-20 18:25:10.000-0600

...added 'sip show subscriptions' to chan_sip2.c

By: Olle Johansson (oej) 2004-02-22 16:11:51.000-0600

Been doing some research, not fully understood everything here yet. Seems like SUBSCRIBE/NOTIFY defines a framework where various applications can run, like SIMPLE presence. Asterisk supports an old - out of date - proposal that defines application/xpidf+xml and some newer stuff from an "dialog" event package.

The dialog event package isn't defined with IANA, propably a proposal somewhere.
Found it:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-04.txt

edited on: 02-22-04 15:24

By: atacomm (atacomm) 2004-02-26 20:34:32.000-0600

oej & bkw: I am at the point where I would like to start developing a centralized event system that the SIP Subscribe/Notify would work off of.  After talking with others, it needs to support the following:

1) Non-protocol specific API for relaying events "on-hook, off-hook, voicemail, etc) to protocols for delivery.

2) Support for relaying events between servers.  (Such as a central voicemail server)

3) The ability for protocols to subscribe to events from other protocols (For example, a SIP phone monitoring to see when an H323 phone goes off hook).

Is there an existing place that this support can be branched from, or is it best to start from scratch?  Last I checked things like VM notification are actually hard coded into the protocols instead of using a centralized event-driven architecture.

Once a good solid centralized framework is in place, adding a good implimentation of SUBSCRIBE/NOTIFY would be easy.

By: Rob Gagnon (rgagnon) 2004-02-27 17:16:10.000-0600

just a note:
The link for v.01 of the draft (in additional info above) is dead now, so I uploaded the latest version which expires Aug. 13, 2004

By: zoa (zoa) 2004-03-12 11:15:43.000-0600

Mar 12 16:55:36 NOTICE[4101]: chan_sip.c:5430 handle_request: Unknown SIP command 'PUBLISH' from '192.168.1.58'

By: Olle Johansson (oej) 2004-03-12 12:23:03.000-0600

zoa - what device sends a PUBLISH to Asterisk? We are not indicating that we support it and as far as I know, Asterisk doesn't subscribe to anything outbound.

atacomm: It seems to me that bullet 1 and 3 is already existent within asterisk, however not very well documented.  SIP could be the transport for 2 between servers, and even better if all servers are asterisk, IAX2 - but I don't know if IAX2 is able to relay events.

Actual VM notification is driven by each channel, but they get it from a central function. THe SIP channel is able to subscribe to notification on a ZAP channel today, even though I haven't got it working - but that's propably a client problem, not Asterisk.

By: zoa (zoa) 2004-03-12 12:29:50.000-0600

well i just saw this notice on an asterisk, coming from a snom 200, googled around, didnt find too much and wanted to be sure that notice could be found with the mantis search too :)

By: Olle Johansson (oej) 2004-03-12 12:34:04.000-0600

zoa: Is it possible to catch the whole packet and publish here? I'm a bit curious.

By: geertn (geertn) 2004-03-13 05:36:23.000-0600

oej, you can activate this in your snom.
In Settings :: SIP :: Stack: Publish Presence -> ON.

Running latest firmware: snom200-SIP 2.04g

I attached the PUBLISH packet in publish.txt

By: Brian West (bkw918) 2004-05-06 19:49:04

We have subscribe now dont we?

By: Mark Spencer (markster) 2004-05-25 01:14:17

We support subscribe/notify but we don't use PUBLISH (actually it makes sense, again, since Asterisk is a PBX and not a Proxy) so I think this is basically finished.

By: jamieg (jamieg) 2004-09-15 21:29:49

Reminder sent to atacomm

I landed on this Bug due to falling into the PUBLISH error coming from a SNOM phone.  I have had great interest in this issue for Asterisk as I feel its one that keeps it from really competing with the top end of the PBX market.

Centralised signaling is the way to go.  Imagine the capabilites.  Imagine if you could monitor all your Friends Personal/Business Lines, like looking an an Instant Messanger..

In any case, this Bugnote is RESOLVED, but I do not see any real plan or movement here to implement this.  The last note is from 4 months ago.

What and where is this issue going in Asterisk.  I have been building up my Asterisk implementation Skills over the last 6 months (Different from development skills I suppose)  And a feature of a fully featured receptionist HARD panel is really needed from my experence.

What are the options, and is this project enhancing the possibilities.

Thanks Guys.