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

Vlad Patrascu vladp at opensips.org
Tue Aug 16 19:19:10 UTC 2022

Hi Li,

For passing around data between the b2b request route and local_route, 
in the context of an ongoing B2B session, you can use the $b2b_logic.ctx 
variable[1]. That would take care of transferring the Cseq from step 1 
to step 2 and the id from step 3 to step 4.

As for your cseq map, you can use the cachedb_local module, and maybe 
the $b2b_logic.key variable alongside Cseq2 for building a proper key.

[1] https://opensips.org/docs/modules/3.3.x/b2b_logic.html#b2b_logic.key


Vlad Patrascu
OpenSIPS Core Developer

On 22.07.2022 23:02, 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 –
>                    B2BProxy
>                                            |
>                 <- 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.
> Thanks,
> Li
> 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
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220816/8eef3031/attachment.html>

More information about the Users mailing list