[OpenSIPS-Users] BLF with parallel forking on OpenSIPS 3.1.1
Gregory Massel
greg at switchtel.co.za
Mon Dec 28 00:27:41 EST 2020
Seasons greetings!
I've implemented BLF using presence, presence_dialoginfo and
pua_dialoginfo and, provided there is only one dialed branch, it works
as expected.
However, I do allow multiple registrations and, as soon as I have two or
more contacts registered and parallel forking of calls, BLF does not
work correctly in respect of the called party.
I'm running OpenSIPS *3.1.1* and what I'm seeing, when parallel forking
takes place, is as follows:
_1. NOTIFY messages are issued for both branches with unique dialog id's:_
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="18" entity="sip:swt37 at vpbx2.switchtel.co.za" state="partial"><dialog id="d474b07f-8b7f-4d7a-ac0a-232d2eae250b.1" call-id="d474b07f-8b7
4d7a-ac0a-232d2eae250b" local-tag="e3p0t2anp8" remote-tag="a0d7dc85-c814-4941-95a5-d97038eb9314" direction="recipient"><state>early</state><remote><identity>sip:11 at vpbx2.switchtel.co.za</identity><target uri=
ip:11 at vpbx2.switchtel.co.za"/></remote><local><identity>sip:swt37 at vpbx2.switchtel.co.za</identity><target uri="sip:swt37 at vpbx2.switchtel.co.za"/></local></dialog></dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="19" entity="sip:swt37 at vpbx2.switchtel.co.za" state="partial"><dialog id="d474b07f-8b7f-4d7a-ac0a-232d2eae250b.0" call-id="d474b07f-8b7
4d7a-ac0a-232d2eae250b" local-tag="1196739183" remote-tag="a0d7dc85-c814-4941-95a5-d97038eb9314" direction="recipient"><state>early</state><remote><identity>sip:11 at vpbx2.switchtel.co.za</identity><target uri=
ip:11 at vpbx2.switchtel.co.za"/></remote><local><identity>sip:swt37 at vpbx2.switchtel.co.za</identity><target uri="sip:swt37 at vpbx2.switchtel.co.za"/></local></dialog></dialog-info>
At this stage, BLF is behaving as one would expect, and the light
indicates that the extension is ringing.
Then I answer the call.
_2. NOTIFY messages are issued for both branches, one "confirmed" and
one "terminated""_
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="20" entity="sip:swt37 at vpbx2.switchtel.co.za" state="partial"><dialog id="d474b07f-8b7f-4d7a-ac0a-232d2eae250b.0" call-id="d474b07f-8b7
4d7a-ac0a-232d2eae250b" local-tag="1196739183" remote-tag="a0d7dc85-c814-4941-95a5-d97038eb9314" direction="recipient"><state>confirmed</state><remote><identity>sip:11 at vpbx2.switchtel.co.za</identity><target
i="sip:11 at vpbx2.switchtel.co.za"/></remote><local><identity>sip:swt37 at vpbx2.switchtel.co.za</identity><target uri="sip:swt37 at vpbx2.switchtel.co.za"/></local></dialog></dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="21" entity="sip:swt37 at vpbx2.switchtel.co.za" state="partial"><dialog id="d474b07f-8b7f-4d7a-ac0a-232d2eae250b.1" call-id="d474b07f-8b7
4d7a-ac0a-232d2eae250b" local-tag="e3p0t2anp8" remote-tag="a0d7dc85-c814-4941-95a5-d97038eb9314" direction="recipient"><state>terminated</state><remote><identity>sip:11 at vpbx2.switchtel.co.za</identity><target
ri="sip:11 at vpbx2.switchtel.co.za"/></remote><local><identity>sip:swt37 at vpbx2.switchtel.co.za</identity><target uri="sip:swt37 at vpbx2.switchtel.co.za"/></local></dialog></dialog-info>
The above behavior is as one would expect; it has correctly notified
that one branch was answered and the other terminated.
However, what follows is where the problem comes in.
_3. NOTIFY message is immediately issued with "full" state:_
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="22" state="full" entity="sip:swt37 at vpbx2.switchtel.co.za"/>
After this, the BLF light goes from flashing (indicating that it was in
the ringing state) to indicating that the extension is available again,
despite the fact that it is on an active call.
When one then hangs up the call, no PUBLISH message is generated
internally by OpenSIPS nor is any NOTIFY message sent.
It appears that the presence server thinks that the call terminated as
soon as one of the branches terminated and is unaware that the other
branch confirmed.
I'm at a loss as to what I've done wrong or how to correct it.
The moment I deregister the additional contacts (so that only a single
contact remains for the subscriber and no parallel forking takes place),
everything works perfectly again.
Any advice on how I can resolve this would be greatly appreciated.
Regards
Gregory Massel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20201228/453cc820/attachment.html>
More information about the Users
mailing list