BLF shows only when extension places an outbound call, not receives inbound

[jpyle]

Hello,

I'm on FusionPBX master (just upgraded) with FreeSWITCH 1.8.7 (also just upgraded). I have a Polycom VVX and a few Cisco SPA phones generally working well on the system. Both a SPA and the VVX have BLFs configured to watch other extensions on the platform. When the target extension is busy the BLFs correctly show it, but only if the target extension made the call. They don't show ringing or busy if the target extension receives an inbound call; they just continue idle.

I've watched the traffic and I don't see any NOTIFYs coming from FreeSWITCH to any of the phones in the inbound case. I'm not finding anything out there for this issue, so I fear I've done something stupid and don't realize it. Are there any thoughts what might cause this? Regular placing and receiving calls from all the phones work just fine.

Previous to today's upgrades I was on FusionPBX master from a few months ago, and FreeSWITCH 1.8.4. The upgrades were to try to deal with this issue and, well, to stay current. This system isn't production (yet).


- Jeff

 

[Adrian Fretwell]

Interesting that you don't see and NOTIFYs from FS on inbound. Are you certain that FS is not generating them? Where were you watching the traffic? Was it on the FS box itself? The reason I ask is because, if you are solely using UDP for SIP, a NOTIFY message can very easily exceed your MTU if a large number of phones are in a inbound ring group, and a given device wants notifying when they all start ringing.

Yealink phones are very good at handling truncated or malformed packets, I have seen a Yealink activate only half of its BLFs because the rest of the NOTIFY message body has gone missing. Other phones will just ignore a truncated packet and non of the BLFs operate.

Your issue may not be related to message truncation at all, but I thought it was worth mentioning.

-Adrian.

 

[jpyle]

Adrian,

An interesting thought. I was watching it on the NAT edge between the LAN where the phone lives and the public IP. The FS server is upstream on the internet.

This was over UDP. I hadn't considered this because in my experience UDP fragmentation is a suitable substitute for TCP fragmentation in most cases, but conveniently without the TCP overhead. I've worked with Polycom VVXs with full sidecars of BLFs and SCAs running UDP back to Broadsoft switches over the internet with no issues. The only place I've seen UDP fragments not pass is over mobile LTE connections.

Even so, I switched all my phones' regs to TCP. No change.

I've attached 204-NOTIFY.txt to this post. I captured this on the FPBX/FS box, and I've changed the IPs and hostnames to protect the innocent. The file shows the NOFITYs as sent to x204, as x201 calls x203. x204 showed only its BLF for 201 change state, not the one for 203. The only mention of 203 in here is in the remote identity of the initial state change, around line 44. I don't have presence-privacy=true so I guess that makes sense. Otherwise...I'm not sure.

I'm going to take a look at the FreeSWITCH v1.8 tree vanilla sofia internal config. I'm going to set the internal profile's variables in FusionPBX to mimic these just to see if something shakes loose, in which case I'll backtrack to see what I had broken before.



- Jeff

 

[Adrian Fretwell]

Jeff, looking at your attachment, I only see the xml for direction="initiator". This is the notification of the invite from 201 to FS. When FS sends the invite to 203 you should also be seeing NOTIFYs with direction="recipient" for the other leg of the call.
- Adrian.

 

[jpyle]

Adrian,

This makes sense! ...but I'm not, and that's the issue. I wouldn't know how to configure FS for this behavior if I wanted it, so I'm stumped how to un-configure it, so to speak.

Any ideas?

It's a relatively stock installation. I've modified the install script only to add a few more HD codecs (siren, etc). I only seriously started investigating the Sofia profiles when I noticed this issue. The fact I'm not finding anything in Google about it leads me to believe it's probably not a direct configuration issue, but rather something else in my environment. DB, some seemingly unrelated config file somewhere, etc.

I'm also not sure what I should be debugging/tracing in FS itself. I'm relatively new to presence on FS. I've tried some high trace and log levels for Sofia but there's a lot of data in there so the potentially relevant bits are still hidden to me.


- Jeff

 

[Adrian Fretwell]

Sorry to ask the obvious. Are you sure 204 is subscribing to 203 correctly? Also what NOTIFYs do you get if you try the call the other way round, from 203 to 201?

 

[jpyle]

Obvious or not, I'll take any questions that might work through this!

Let me describe the scenario more completely. I have four test phones on this system, 201-204. 201 and 204 are Cisco SPA phones with attendant consoles watching all four users 201-204. 202 is a Polycom VVX watching only 201. 203 is another SPA phone not watching anything. Regardless of who calls whom, all phones with BLFs show only the originator in use, not the recipient.

So, let's say 201 calls 203 as in the example from my last post. The attendant consoles on 201 and 204 show 201 in use on the appropriate BLF button, as does the line appearance on 202. Nothing shows 203 in use because, as you've seen, the NOTIFYs don't get sent. If I reverse the flow, have 203 call 201, it's exactly the same situation except everyone shows 203 in use this time. With this I think the subscriptions are okay.

Most of my testing is extension to extension, all within the 'internal' profile. I have done limited testing on inbound PSTN calls, where the call would bridge from 'external' to 'internal'. In these cases I believe I may not have this problem; I think here the BLFs for the recipient user may change state unlike the all-internal case. I need to do more testing to confirm, but even so, I don't know why internal-to-internal calls would show only the originator.


- Jeff

 

[Adrian Fretwell]

This is a tricky one. A complete packet trace of a call may be needed to diagnose further, including the register and subscribe requests. The Record-Route process does have an affect how NOTIFY messages are constructed. You may have to dissect this a chunk at a time. Have you considered putting together a test rig with FreeSwitch and the phones all in the same subnet and see if you can replicate the problem there?

 

[jpyle]

Dissecting chunk at a time... yes. This makes sense, although I can't shake the feeling that if a NOTIFY can make it back to a particular device for a particular BLF, why can't they all? Grr. This still smells like something switch-side to me.

I'm operating under the assumption whatever ugliness is happening here is local to this particular configuration, and if I were to lab it, I wouldn't be able to reproduce it. Even so a local test rig isn't out of the question. I think what I'm going to try first is to remove NAT between the switch and the network where the phones are with a new Sofia profile listening on a new private IP on the switch routable directly to the phones across a VPN. If nothing else this will make it easier to dissect one chunk at a time. Updates to follow...

 

[jpyle]

The approach to create a NATless profile flopped. FS is behind NAT, too, and I couldn't keep its public IP completely out of the signaling, even with setting sip/rtp-ip and ext-sip/rtp-ip to the internal one reachable in the VPN. Oh well.

Yeah, I'm at a loss here. I've watched all the SUBSCRIBEs and they look fine, subscribing to "application/dialog-info+xml" for each extension. I've watched the output of "sofia global debug presence" and I don't see anything horribly wrong. FS even doesn't try to send any NOTIFYs with direction="recipient", as if it doesn't realize anyone cares.

I think I'm going to plead my case on the FS user list.

 

[jpyle]

I figured it out. I had to export the presence_id variable in the local_extension part of the dialplan. I did that, and I get callee BLF status now.

 

[Adrian Fretwell]

I figured it out. I had to export the presence_id variable in the local_extension part of the dialplan. I did that, and I get callee BLF status now.

Glad you got it working. There must be more to this, I have just checked my local_extension and I do not export the presence_id variable but my BLFs work fine. Looking at my CDR records, the presence_id always seems to be set, but there is no indication as to when or where it gets set. Curious...

 

[jpyle]

I was close. Using it as an export, the BLF for the originating device didn't get cleared when it hung up some of the time. Running it in the bridge statement I'm having more success. Still strange, though. I wonder what's different here. I searched the fusionpbx github repo for "presence_id" and I didn't see anything obvious.