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

[Vlad Patrascu]

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

Regards,

-- 
Vlad Patrascu
OpenSIPS Core Developer
http://www.opensips-solutions.com

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>