Discussion re: EPM Extension Mapping and PJSIP devices


(Lorne Gaetz) #1

In the good ol’ days, with chan_sip extensions, the FreePBX admin could browse to EPM Extension mapping and see a list of configured devices which also showed the device IP address. A quick glance shows if the device is registered and from which IP, with the added bonus that you could click the IP address to immediately browse to the device GUI. Now with PJSIP, it’s possible to have multiple devices configured for the same extension, and possible to have multiple registrations from devices that are not configured in EPM. It is not possible to correlate the registered IPs reported from Asterisk with the individual configurations generated by EPM nor even if the registered device is actually configured with EPM. This has presented a dilemma on how or what to display for information in the status column of EPM Extension Mapping for PJSIP devices.

As we’ve we’ve been cleaning up some of the EPM ticket backlog, the solution we ended up on for this is to provide a button in Extension Mapping for each PJSIP configured device, which looks like this:

when you click the “Show AOR” button, it brings up all currently registered IPs to that specific extension with their status, so for above it looks like:

I recognize that this is not ideal, you no longer get a status/IP at a glance for all extensions on the Ext Mapping page but you get more verbosity than previously which might be helpful. This is the only reasonable way I can see this working, but I’m opening this thread to solicit opinions and ideas from others.

How do you envision having PJSIP extension status displayed in EPM, keeping in mind that there can be multiple EPM configurations and/or multiple registrations with no way to correlate the them?


#2

Here is the presentation which appears to me to be the most useful all things considered. This permits at-a-glance information for extensions/aors with single contacts and a helpful option for those with multiple contacts. (PS. It would be nice to have the units ‘ms’ added after the RTT values. I should have added them in my mockup.)


(Chris Dolese) #3

good stuff @lgaetz ! thank you


(Jared Busch) #4

This is something I have been slowly toying with.

I have not the impetus to do much in my free time, and currently no customer wanting me to work on it so I get paid.

My goal was to eventually have specific reboot/reload buttons that only affect the AOR. But no where close to that yet.

In the “extensions_status” branch of my github:


#5

Polycom UC 5.9 and forward provides a RESTful API. There is a path to request detailed phone info which includes the MAC addy (/api/v1/mgmt/device/info). A simple script to walk through the currently registered contacts by IP could grab this information and match it to MACs which would allow EPM to better manage endpoints.

It appears that Grandstream also has APIs available on its phones. Perhaps other manufacturers do as well.


(Lorne Gaetz) #6

Are you talking about http(s) API on the devices? If so, that would be problematic for phones registering from behind NAT. Not to mention the work involved in implementing different API methods for every manufacturer.


(Jared Busch) #7

An inbound API would be useless as @lgaetz said.

I do not know of any SIP messaging that contains the MAC address off the top of my head.


#8

I forgot about NAT issues.

Polycom also has this: sec.tagserialno

It appears that Grandstream also has a similar setting: Use MAC Header (Shown in multiple phone model admin guides.)

When enabled the phone sends its MAC in HTTP GET and SIP contact headers. That should traverse NAT.


(Jared Busch) #9

Many phones vendors already have that in the HTTP headers by default. I make use of that for writing back manual changes from Yealink phone configs to the PBX

But, again, that is useless from an EPM point of view. Nothing in a web call links back to the AOR.


#10

The real show-stopper appears to be rooted in the fact that EPM blindly sends a SIP notify (check-sync event in the case of Polycom) and then assumes the endpoint will follow through. EPM appears to have no way to receive the SIP status response from the endpoint that receives the notify.

EPM also appears to obtain the current IP of an endpoint from the AOR/Extension. (ie. show aors).

If a phone is configured to add its MAC to SIP headers and if EPM were able to actually receive SIP response from the phone, EPM could look up all IPs registered to a given AOR, query each to discover the MAC, and then send a check-sync (or appropriate event) to the correct phone.

Much of the IP/AOR/Extension logic must already be in place. So… how difficult is it to enable EPM to receive SIP packets?


(Dave Burgess) #11

I’d drop in a Feature Request and let Sangoma handle it from there, since this is commercial code. If it was the OpenSource version, I’d say “Dig in and let us know how it goes.”


(Lorne Gaetz) #12

Feature requests around how phone status is displayed in EPM extension mapping belong in this thread, that’s why I started it.

Using SIP to query and endpoint for the MAC is probably not a workable solution. The only way that I can think of to accomplish this would be by configuring a phone to embed the MAC address in the SIP User Agent string, but I’m not aware of any phone that does this by default, and I only know of one manuf that can actually do it at all.

The most practical solution so far is what @chris_n said a few days ago. Extensions with max_contact set as 1, show the registration IP and all other pjsip devices get the ‘Show AOR’ button to get more info.


(Jared Busch) #13

It could certainly work if the phone added it to the user agent. That data is already there.

But it is a big “if” the phone can do it. Like most brands, Yealink has a setting for that.
account.1.custom_ua = 00156565f22a

At that point, it would be trivial for EPM to then get the information using a similar function to what I did in my github above.


#14

It is actually very doable.

That is exactly what happens. At least for Polycom devices.

Here is a data dump taken when EPM requests a phone to reboot after a configuration rebuild:

My thoughts are that EPM should be able to receive SIP packets in order to verify that the requested reboot did take place. That’s probably a different feature request, but certainly prerequisite to the current one.

I suspect most phones can include their MAC in SIP packets somehow. Polycom and Grandstream can. @sorvani has pointed out that Yealink can. Certainly logic to handle those which cannot is possible and probably trivial.

If it were OSS, I would have already been on it. For someone who works with this code regularly, this should be a very straightforward improvement.


(Jared Busch) #15

Why would EPM need to do anything with a SIP packet? You are not understanding how any of this works.

Specifically, being discussed is adding it to the User Agent. While, this is trivial to do, you then need to make a lot of logic to determine what and where the MAC is in the User Agent string.
Because we are discussing it via EPM, that does mean specific location and format can potentially be determined.

Specifically needing to be known is how each vendor does it.
In the Yealink example, using the field appends the value. But there is no variable built in to the phone, so EPM will have to add the MAC specifically. I my test above, I simply added it to a config file without the colons and in all lower case, and you see how the User Agent was appended. EPM can be modified to add the line to the config file in a controlled manner for the Yealink phones. But that still leaves all of the various brands… It is not a small undertaking.


#16

#Send MAC address in UA. 0-Disable; 1-Enable(00:11:22:33:44:55); 2-Enable(001122334455);

Add this to the basefile.

sip.mac_in_ua = 2


#17

Because as it stands now, EPM blindly assumes the endpoint is doing what it was requested to do by EPM. If the endpoint is halfway around the globe and in a remote location not often visited, then one must run on the assumption that things went as planned.

Okay, you win. I don’t have time to argue the point.

@lgaetz @cynjut

If I’m wasting my time on this, please let me know. I think this could be in reaching distance for vendors with clearly established configurations involving MAC addresses and it would be straightforward to default to the current behavior with those who do not or in cases where it indeterminate.

Thanks for your time.


(Lorne Gaetz) #18

General info in response to everything above:

  1. EPM does not send SIP packets per se, what EPM does is instruct Asterisk to send a NOTIFY packet to the phone to tell it to reprovision/reboot/whatever. The only valid SIP response to a NOTIFY is 200 OK, there is no SIP mechanism to determine if the phone is doing what it was told to do in the NOTIFY. In any case this is off topic to the conversation in this thread.
  2. Whether the phone is capable of sending the MAC in any non-specific SIP header is not relevant. When the device registers, an address of record (AOR) is created in Asterisk, and the only information available to EPM is what is stored in the AOR. EPM would query asterisk for registry info, not the devices.
  3. Configuring devices to append the MAC to the SIP User Agent could potentially work, but I am very sure that every single phone manufacturer will do it differently, meaning whack-a-mole regex hell for engineering.
  4. Since yesterday, I have remembered that the Phone Apps module currently uses the User Agent string in order to determine the appropriate XML format to return the to device when using Phone Apps. Changing the User Agent string format for any phone supported by Phone Apps will break phone apps completely without a rethink about how it all works.

Good conversation here, thanks to all who’ve taken time to think about this.


(Jared Busch) #19

The updated UA info is in that data.

Makes me curious as to why, but all the custom UA info seems to append. So an issue, but not insurmountable.


(Lorne Gaetz) #20

Actually thinking further, Phone Apps may only rely the http User Agent, not the SIP User agent of the device. Still a case to step very lightly when introducing changes of this type for existing devices. I see this more likely being considered for new devices going forward.