[OpenSIPS-Users] About obstacles to implement the matched Id in event header of NOTIFY(REFER)

Li Cai Li.Cai at comtech.com
Mon Aug 15 13:32:41 UTC 2022

Hi Bogdan,

Yes, I'm trying to figure out a way to implement correct Id in event header of NOTIFY for REFER. Can I ask for the suggestion on how to move forward?


From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: August 9, 2022 5:00 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Li Cai <Li.Cai at comtech.com>
Subject: Re: [OpenSIPS-Users] About obstacles to implement the matched Id in event header of NOTIFY(REFER)

WARNING: External Email: Exercise Caution

Hi Li,

If I understand correctly, you try to improve the b2b support in OpenSIPS in order to properly handle that NOTIFY for REFER, right ?


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer


OpenSIPS Summit 27-30 Sept 2022, Athens

On 7/22/22 11:02 PM, Li Cai wrote:
Hi experts,

I'm working on the implementation for '2.4.6 Multiple REFER Requests in a Dialog' of RFC3515 in a B2B SIP Proxy. Right now, I got stuck with two problems in the solution. Please see the paragraph from RFC-

   A REFER creates an implicit subscription sharing the dialog
   identifiers in the REFER request.  If more than one REFER is issued
   in the same dialog (a second attempt at transferring a call for
   example), the dialog identifiers do not provide enough information to
   associate the resulting NOTIFYs with the proper REFER.

   Thus, for the second and subsequent REFER requests a UA receives in a
   given dialog, it MUST include an id parameter[2] in the Event header
   field of each NOTIFY containing the sequence number (the number from
   the CSeq header field value) of the REFER this NOTIFY is associated
   with.  This id parameter MAY be included in NOTIFYs to the first
   REFER a UA receives in a given dialog.  A SUBSCRIBE sent to refresh
   or terminate this subscription MUST contain this id parameter.

Different from the definition in RFC, the NOTIFY forwarded by the proxy contains the same Id in Event header as the other side. Please see the below chart -
                <- REFER 2 (Cseq=2) |                  <-REFER 1  (Cseq=1003)
                             . . .                  |          . . .
->NOTIFY 1 (event:id=2)          |  ->NOTIFY 2 (event:id=2)

The current problem is, the above NOTIFY on the right side should include 'id=1003' instead of 'id=2'.

The solution I'm trying is as in the following flow -
      1.         get CSeq 1 of REFER 1 in route[b2b_request]{}  ->
      2.         get CSeq 2 of REFER 2 in local_route{},  then save the pair(key=CSeq2, value=CSeq1) in a map set->
      3.         get Id  from NOTIFY 1 event in route[b2b_request]{}  ->
      4.         use Id  as key then get matched CSeq1 from the map set, use remove_hf() and append_hf() to modify the event header in local_route{}

My two questions are:

  1.  To transfer Cseq 1 from step1 to step2, I tried a variable in the AVP type but it didn't work. The script variable can work but it doesn't fit because the processing is based on per request.  Can I ask if you have any suggest on how to transfer the value from route[b2b_request]{} to local_route{}?
  2.  In the step2, I tried to create and operate a JSON map set to save the CSeq pairs. But the JSON data didn't work for me.

            My source :

                                    $json(csList) = "";       # Initialize the data set, not sure if it's correct

                                    $json(csList/"$cs") = "$avp(csNum)";

            The error I got:

                                    ERROR:core:do_assign: setting PV failed

                                    ERROR:core:do_assign: error at /usr/local//et/opensips/opensips.cfg:531

Thank you very much for the help! Any your suggests are very welcomed.


NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and / or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.


Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220815/4776432a/attachment-0001.html>

More information about the Users mailing list