Jump to content

BLF Presence Specification for FreeSWITCH


FASTDEVICE

Recommended Posts

I'm working with several offshore IP phone manufactures to widen our selection of compatible phones w/ 2600hz's network. However, they are all having the same difficulty in implementing BLF presence messaging for FreeSWITCH. 

Can anyone point me to a definitive and well documented whitepaper on BLF presence for FreeSWITCH and any addendum that may be required for how 2600hz may affect that implementation?  
Link to comment
Share on other sites

  • Administrators
This line of questioning is a bit suspect. Are you asking for a definitive way the packets work?

The problem here is in RFCs in general, specifically because of RFC 2119:

The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST
NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].

The word "MAY" is the root of all evil. In fact, the FreeSWITCH team has a running joke about it when advertising their conference, ClueCon - you SHOULD attend, you MAY learn something. ;-) Or something like that.

Anyway the joke is pretty simple. Because the word MAY is used in the RFC in various spots that are really ambiguous, different vendors end up implementing whatever they interpret that word to mean. Thus, you end up with different implementations. The word MAY exists in the RFC for the goal of ensuring people can use the specification in differing ways, but it ends up serving as something that creates issue when two people trying to implement the same functionality do it in different ways. Thus, a mess.

Thus SIP :-)

So, if you're asking "what packets exactly can be transmitted", the answer is read Luis's specified RFCs . EVERYONE - including Broadsoft and Asterisk - MUST be following them. But not everyone MAY agree on exactly how the RFC reads, thus, the implementations can take a while to get right on each platform.

Trial & error FTW
Link to comment
Share on other sites

×
×
  • Create New...