Recognizing and Modifying NOTIFY Message

JRayfield · Post by **JRayfield** » Wed Jan 22, 2020 3:58 pm

1. Brekeke Product Name and Version:
3.9.4.3/517-1

2. Java version:
1.8.0_231

3. OS type and the version:
Windows Server 2016

4. UA (phone), gateway or other hardware/software involved:
3CX and Yealink Phones

5. Your problem:

I'm attempting to interface a 3CX IP PBX server and a Microsoft Exchange UM 2016 system, in order to use the voice-enabled auto attendant in the Exchange system.

In order to get this to work correctly, I need to 'recognize' a NOTIFY message that is sent from the 3CX server to the Exchange server and modify the "Subscription-State" line.

I looked at $request, but it doesn't appear to work with NOTIFY.

Is there any way to set up a Matching Pattern that would recognize a NOTIFY message where the Subscription-State line is "init;expires=60"? I need to modify that line to "terminated;reason=noresource".

Is this possible with BSS?

John
We have the interface working, except for one problem.

When the Exchange server sends a REFER back to 3CX server,

Harold · Post by **Harold** » Thu Jan 23, 2020 12:33 pm

> I looked at $request, but it doesn't appear to work with NOTIFY.

This is because that NOTIFY was sent within the same dialog what INVITE generated.

To catch NOTIFY, add the line below in the Deploy Pattern of current DialPlan rule which caches the INVITE.
&net.sip.outside.dialog.pattern = ^NOTIFY

If so, you can catch "NOTIFY" with $request=^NOTIFY by another rule.

If the above solution doesn't work... (because REFER is also sent within the INVITE's dialog), try &net.sip.outside.dialog.pattern=^REFER in the current rule and reject REFER by new rule.

JRayfield · Post by **JRayfield** » Thu Jan 23, 2020 8:01 pm

I'm not sure that I understand.

Here's a Matching Pattern and Deploy pattern that I use in another BSS system, for an IP PBX to connect to another server. This is for inbound calls, routing them from the VoIP service provider's server to the IP PBX server. (Obviously, I've changed the IP addresses, registration 'user', etc).

Matching Pattern:

$request=^INVITE
$registered("1234567890")=true
$addr=123.456.789.012
To=sip:(9001)@

Deploy Pattern:

$auth=false
$rtp=false
$b2bua=false
To=sip:%1@987.654.321.098

Now, would I add "&net.sip.outside.dialog.pattern = ^NOTIFY", such as:

Deploy Pattern:

$auth=false
$rtp=false
$b2bua=false
To=sip:%1@987.654.321.098
&net.sip.outside.dialog.pattern = ^NOTIFY

Is this correct?

Then, I could have another Matching Pattern like this?:

$request=^NOTIFY
$registered("1234567890")=true
$addr=123.456.789.012

Is this correct?

Once I've matched the NOTIFY message, then I need to make sure that it's the correct NOTIFY message. So I also need to match the Subscription-State line in the NOTIFY message, by looking for "Subscription-State: init;expires=60" and change that to "Subscription-State: terminated;reason=noresource". How do I do that?

Then, once I know that I have the correct NOTIFY message, how do I change the "Subscription-State" line?

I've still got a LOT to learn about how to set up dial plans in BSS. So I REALLY appreciate any and all help to learn this.

John

Harold · Post by **Harold** » Mon Jan 27, 2020 3:30 pm

> Is this correct?

Yes if it is the rule for matching an INVITE which causes NOTIFY.

> So I also need to match the Subscription-State line in the NOTIFY message...

How about this?
[Matching Patterns]
$request=^NOTIFY
$registered("1234567890")=true
$addr=123.456.789.012
Subscription-State = init

[Deploy Patterns]
Subscription-State = terminated;reason=noresource

As I mentioned in my previous post, using NOTIFY rule may NOT meet the requirement if NOTIFY is sent for REFER. (because call transfer is triggered by REFER)
If so, catch the REFER by DialPlan and reject it.

JRayfield · Post by **JRayfield** » Mon Jan 27, 2020 3:52 pm

How would the dialplan be written to reject the REFER?

John

JRayfield · Post by **JRayfield** » Mon Jan 27, 2020 4:35 pm

If the NOTIFY was sent for REFER, would the CSeq section reference REFER? In this particular NOTIFY, CSeq only references NOTIFY.

John

Harold · Post by **Harold** » Tue Jan 28, 2020 5:30 pm

> How would the dialplan be written to reject the REFER?

Put the line below in the rule for INVITE.
&net.sip.outside.dialog.pattern = ^REFER

And add the rule like this for REFER. This rule rejects REFER with the "603 Decline".
[Matching Patterns]
$request = ^REFER

[Deploy Patterns]
$response = 603

> If the NOTIFY was sent for REFER, would the CSeq section reference REFER?

No.. This is because REFER is sent from UAS but NOTIFY is sent from UAC.

> In this particular NOTIFY, CSeq only references NOTIFY.

Right.
Why do you want to compare CSeq?

JRayfield · Post by **JRayfield** » Wed Jan 29, 2020 5:56 am

I don't think it would work to reject the REFER. The REFER needs to be passed through to the 3CX server to initiate the transfer.

John

Tata · Post by **Tata** » Wed Jan 29, 2020 8:40 am

is it ok to allow the transfer?

JRayfield · Post by **JRayfield** » Wed Jan 29, 2020 8:54 am

I think I misunderstood something.

When the REFER is sent to the 3CX server, it initiates the transfer. That is good.

3CX then responds with a NOTIFY in which the Subscription-State is "init;expires=60". And the sipfrag portions is "100 TRYING".

It's at this point that I need to be able to change this NOTIFY message (change the Subscription-State line to "terminated;reason=noresource" and the sipfrag portion "BYE") and send it on to the Exchange server. This should cause the Exchange server to send a BYE back that will be forwarded to the 3CX server.

The above is exactly what needs to happen (obviously various acknowledgments of the 'primary' messages aren't included in the above description).

John

Tata · Post by **Tata** » Wed Jan 29, 2020 12:21 pm

Is there no BYE sent from the Exchange server currently?

Are you sure that "terminated" in Subscription-State line triggers BYE?

Do you want to close the original INVITE session just after the transfer happens?

JRayfield · Post by **JRayfield** » Wed Jan 29, 2020 12:29 pm

Yes, when Exchange receives the NOTIFY with the "terminated" in it, Exchange then sends a BYE to close the incoming connection to the Exchange server from the PBX. This is how the current Mitel PBX system is working with Exchange. I want to mimic that operation with the 3CX/Exchange system.

Yes, the original INVITE needs to be closed after the REFER is sent and the transfer has happened.

John

Tata · Post by **Tata** » Wed Jan 29, 2020 5:31 pm

so currently how do you close the original INVITE session? Do you need to send a BYE from 3CX?

Regards to the modifying NOTIFY, it might be possible to replace "Subscription-State" line to have the "terminated" but it is impossible to replace the sipfrag portion.

Does the Exchange send BYE even if the sipfrag portions is "100 TRYING"
within the NOTIFY with the "terminated" ?

JRayfield · Post by **JRayfield** » Wed Jan 29, 2020 5:40 pm

Currently, when the transfer target (the extension to which the call will be transferred) answers, 3CX sends the NOTIFY with "terminate". When the Exchange server gets this, it sends a BYE back to 3CX to terminate that connection (the connection that has been up between 3CX and the Exchange server, during the time that the target extension has been ringing).

I don't know if the Exchange server will send a BYE if the sipfrag portion is "100 TRYING", or not. I would just have to try it. But I suspect that it won't work correctly.

Tata · Post by **Tata** » Thu Jan 30, 2020 12:33 pm

Another idea is to write a plugin code to send BYE from SIP server to both UAC and UAS when NOTIFY request is received.

JRayfield · Post by **JRayfield** » Thu Jan 30, 2020 12:36 pm

That would probably work. I don't know enough C, C# (yet) or Java to know how to write the plugin, but that is a good idea.

John

mitu · Post by **mitu** » Thu Jan 30, 2020 1:54 pm

I will send you the source code over TSC.

JRayfield · Post by **JRayfield** » Fri Jan 31, 2020 6:12 am

What is TSC?

mitu · Post by **mitu** » Fri Jan 31, 2020 9:00 am

> What is TSC?

It is Technical Support Contract you already applied.