BLA Line Seize Race Condition

[Anonymous]

According to the BLA draft https://tools.ietf.org/html/draft-anil-sipping-bla-03#section-6.2, when a phone attempts to seize a bridged line appearance (e.g. NOTIFY with state=trying) and another user has just seized the line, a 500 with Retry-After header should be returned to the requester. The phone should then wait the amount of time in the header before retrying another trying NOTIFY. However, what I'm seeing in practice is very different. I have a scenario where a 500 is returned with Retry-After=2, and the phone does not respect the header and immediately sends a NOTIFY with state=terminated for the same line-id, before attempting to seize another line appearance (e.g. x-line-id=1). This diverges from the spec entirely. Any ideas why?

The BLA phone config:

  <entry reg.1.callsPerLineKey="1"/>
  <entry reg.1.lineKeys="1"/>
  <entry reg.1.strictLineSeize="1"/>

Firmware 5.6.0 

[SteffenBaierUK]

Hello @Employee#1,

welcome to the Polycom Community.

UC Software 5.6.0 is no longer a valid and supported software so please upgrade to UC Software 5.7.2 and re-test.

If this still produces the same result please open a ticket.

In order to raise a support ticket you need to work with your Polycom reseller as they need to do this for you.

End Customers are unable to open a ticket directly with Polycom support.

If this is some sort of an Internet discounter please post either your phone's MAC address or your Polycom devices serial so I can look up who would be able to support you. This may not be who you purchased the Polycom device from.

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services