[OpenSIPS-Users] B2BUA - REFER- detect 200 OK to send notify

[amel . guesmi]

Hello all,

Sorry for sending this question several times, hope i get some help this time 

We are trying to implement  the « REFER » method in opensips 3.3. we used this 
documentation :
openSIPS | Documentation / 
Tutorials-B2BUA

When we detect a REFER method, we are excuting those functions :

b2b_send_reply(202, "Accepted");
# Example: Send NOTIFY request
$var(destination) = $hdr(Refer-From);
$var(message_body) = "This is the message body of the NOTIFY";
send_request("NOTIFY", $var(destination), $hdr(Refer-To), 
$var(message_body));

# create the client entity corresponding to
# the user specified in the 'Refer-To' header
b2b_client_new("referee", $hdr(Refer-To));
# bridge the referrer's peer with the referee
b2b_bridge("peer", "referee");
#b2b_end_dlg_leg();


With that scenario, we succeeded in transfering a call after the REFER and  we 
are tryning now to implement that process with « Notify » after the REFER (see 
the flow in the following link).

REFER_-_User_docs_2.width-800.png (720×540) 
(twilio.com)


For this, when we open the new client session, we don’t end the session with 
the one sending the REFER and we need to detect when the call is accepted by 
the Callee (200 OK) when we are using that function : b2b_client_new("referee", 
$hdr(Refer-To));

How can we detect the 200 OK in that B2B mode in order to send the NOTIFY 
before ending the session with Alice.


Thank you very much
BR, Amel


Orange Restricted
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Issue with CRL Validation in French STIR/SHAKEN Implementation

[Wadii ELMAJDI | Evenmedia]

Hello

I have run into a problem with the STIR/SHAKEN verification process.
In the French implementation of StirShaken, the CRL of the operator 
certificates is signed with a certificate that is different from the one used 
to sign providers certificates.
and in such case, OpenSSL does not allow in one command to validate the entire 
certification chain.

Also, OPENSIPS stirshaken module's stir_shaken_verify function fails to 
validate providers certificate (with CRL Loaded)

Error : certificate validation failed: unable to get certificate CRL

For now, following the guidelines suggested by the French authority handling 
STIR/SHAKEN, we are planning to implement a two-step approach to check CRL 
before stir_shaken_verify kicks in (w/o CRL loaded)
First, we verify the certification chain of the provider's certificate, plus 
making sure CA's certificates are not revoked. We do this using a command like:

openssl verify -CAfile /etc/opensips/example_certs/ca_list.pem -untrusted 
/etc/opensips/example_certs/example_pa.pem -extended_crl -crl_check_all 
-CRLfile /etc/opensips/example_certs/crl_list.pem 
/etc/opensips/example_certs/ProviderCertificate.cer

Where example_pa.pem is the certificate used to sign CRL of providers 
certificates, and crl_list : the concatenation of both providers and CA's CRLs 
in PEM format.
The second step involves a separate check to verify if the provider's 
certificate is revoked :

openssl crl -in /etc/opensips/example_certs/crl_list.pem -noout -text | grep 
$(openssl x509 -in /etc/opensips/example_certs/ProviderCertificate.cer -noout 
-serial | cut -d '=' -f 2)

This will add an extra processing time due to a double certification validation 
(ran by both by openssl and stir_shaken_verify)  + reading crls from disk.

Given this situation, it would be highly beneficial if Opensips could 
accommodate cases where revocation lists are signed with a different 
certificate. This would not only simplify the verification process but also 
improve compatibility for similar future scenarios (like a complex certificate 
hierarchy)

Suggestion :

Consider adding an exported parameter, such as :
modparam("stir_shaken", "crl_signing_certs", 
"/stir_certs/crl_signing_certs.pem")

This parameter would allow users to specify a list of separate certificates 
used to sign the CRLs, in cases where the CRLs and the provider certificates 
are not signed by the same certificate.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialog contact not updating until answer

[Bogdan-Andrei Iancu]

Hi Callum,

The callee contact is learned only when the call is established (so , at 
200 OK). During the ringing state, a call may have several 
in-progress/ringing branches to different callee end-points, each with 
its own contact. Only when the call is answered you will get ONE of the 
branches actually established , so you will have the final contact from 
the callee end-point.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 8/1/23 4:23 PM, Callum Guy wrote:

Hi All,

I've observed a behaviour (OpenSIPs 3.2.4) where the contact stored
against an active dialog is not populated until the call is answered.

Using opensips-cli dlg_list I see the following:

Ringing - https://gist.github.com/spacetourist/2502f6b76a95bb2f500fda5291e1c93b
Answered - https://gist.github.com/spacetourist/81b9e19de14a04aeff7f1f7b8965e2e5

During ringing we have:
- "state": 2
- CALLEES > "callee_contact": "",

Once answered we have:
- "state": 4
- CALLEES > "callee_contact": "sip:b2o80qss@77.95.114.132:45656;transport=ws",

This is problematic for me as I'm working on a system to prevent
duplicate registrations from an AoR (sip:6190...@sk-1.rtc.sip.net)
whilst preventing other instances from overruling and taking ownership
of the session by blocking registrations from separate contacts when a
call is ongoing.

The exact scenario where I'm currently seeing errors is when an active
contact (i.e. sip:b2o80qss@77.95.114.132:45656;transport=ws) issues a
re-REGISTER during call setup. I use get_dialogs_by_profile() in
OpenSIPs to track sessions against the AoR and loop through any active
dialogs associated whenever a call or registration comes in. Using
this approach has allowed me to block other devices from creating a
second registration however the lookup is currently failing during the
ringing part of the session as the contact cannot be checked.

Is there a reason why callee_contact cannot be updated immediately
when the session begins? Is this to accommodate branching or similar?
I'll review alternative approaches whilst awaiting a reply however it
would be great if there was a path for me to solve this issue with my
current approach!

Thanks,

Callum

P.S. if this makes more sense as a Github issue then please let me
know, I'm not sure where is best to ask!




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users