Did you check the documentation (core information is relevant)? https://frafosdocs.s3-eu-west-1.amazonaws.com/frafos_abc_sbc_handbook.pdf

пт, 17 дек. 2021 г. в 12:28, Mojtaba mespio@gmail.com:

Any update on this?

On Sat, Dec 11, 2021, 13:56 Mojtaba mespio@gmail.com wrote:

...

Hello, Why in SEMS, some changes (in transparent SBC profile) in sip headers do not apply. For example i want to change CSeq or Contact header like this: # transparent SBC profile # defaults: transparent RURI=$r From=$f To=$t Call-ID=$ci_leg2 CSeq=$H(CSeq) Contact=$H(Contact)

When I run SEMS, CSeq and Contact do not change, while other headers change.

[#7fc688d7b1c0/9379] [onLoad, SBC.cpp:189] INFO: loading SBC call profiles from '/usr/local/etc/sems/etc/' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:418] INFO: SBC: loaded SBC profile 'mo' - MD5: d6a2c29084043edde1357231f6866737 [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:423] INFO: SBC: RURI = '$r' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:424] INFO: SBC: RURI-host = '' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:425] INFO: SBC: From = '$f' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:426] INFO: SBC: To = '$t' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:431] INFO: SBC: Call-ID = '$ci_leg2222' [#7fc688d7b1c0/9379] [readFromConfiguration, SBCCallProfile.cpp:434] INFO: SBC: force outbound proxy: yes This issue caused the Asterisk could not pass the Authentication process in "match_req_to_dialog" function because the CSeq is the same as the dialogs. So the Asterisk thought this message was a LOOP message. Has anybody encountered this issue in SEMS? How did you solve this? I know there are some ways for doing this with Kamailio, But i focused on issues in SEMS

With Best Regards

*-- Mojtaba Esfandiari.S*

*-- PhD student and Research Affiliate, *

*-- Technical Manager at IP-PBX Laboratory, Ferdowsi University of Mashhad, Iran.*

-- Address: IP-PBX Lab., Engineering Faculty, Ferdowsi University Main Campus, Mashhad, Iran.

-- Tel: +98-51-38763635

-- Mobile: +98-915-117-6713

---

Kamailio - Users Mailing List - Non Commercial Discussions

• sr-users@lists.kamailio.org

Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

• https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

@Juha Heinanen: Yes, all other headers are supported. But I don't know why in the Invite message, the value of CSeq is not changed, and all invite messages have 10 INVITE. This caused the asterisk server could not pass the Authentication process.

@ Denys Pozniak: Yes, I had quick look at it, In Section 6.3 (Using Replacement in Rule), does not mention how we can change the CSeq header. I just imaged the value of CSeq should be incremented automatically by Sems during Dialog, But it didn't change and at all times it has the same value (CSeq: 10 INVITE). I need to change it because when the calling moves to Asterisk, it should be authenticated. Thanks

On Fri, Dec 17, 2021 at 7:22 PM Juha Heinanen jh@tutpro.com wrote:

Mojtaba writes:

...

When I run SEMS, CSeq and Contact do not change, while other headers change.

Are you sure that changing other headers than RURI, From, To, and Call-ID is supported?

---

Kamailio - Users Mailing List - Non Commercial Discussions

• sr-users@lists.kamailio.org

Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

• https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Hello, Let' me describe the scenario: <UE>---------><SEMS>-----------><ASTERISK> The UE tries to make calls, The first INVITE message is without an Authentication header. The Asterisk server returns 401 Unauthorized. The UE sends again INVITE messages to the asterisk server. The second INVITE message has an Authentication header. Because both INVITE messages have the same CSeq, the asterisk server thinks this is a LOOP message and sends 401 Unautirozed messages again. In both cases, the Sems set "CSeq: 10 INVITE" header, while the second the INVITE message is not re-invite message and the CSeq should be set incremental.

On Sat, Dec 18, 2021 at 11:15 AM Juha Heinanen jh@tutpro.com wrote:

Mojtaba writes:

...

Yes, all other headers are supported. But I don't know why in the Invite message, the value of CSeq is not changed, and all invite messages have

10

...

INVITE. This caused the asterisk server could not pass the Authentication process.

Are you saying that re-INVITEs have the same CSeq value as the intial INVITE?

In initial INVITEs CSeq can have any value:

8.1.1.5 CSeq

For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary.

-- Juha

---

Kamailio - Users Mailing List - Non Commercial Discussions

• sr-users@lists.kamailio.org

Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

• https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Hello,

I think in this particular case (SIP authentication) this is not correct (RFC 3261, 22.2):

"When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request."

Refer also e.g. to RFC 3665, where it clearly shows the incremented CSEQ for the 401/407 challenges.

Cheers,

Henning

Yes, I agree with you, This is an exception related to 401(Unauthorized) and 407 (Proxy Authentication Required) responses. In these situations, The CSeq header field value should be incremented.

On Sat, Dec 18, 2021 at 7:00 PM Juha Heinanen jh@tutpro.com wrote:

Henning Westerholt writes:

...

I think in this particular case (SIP authentication) this is not correct (RFC 3261, 22.2):

"When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request."

OK then, reference to this exception should have been included in section 8.1.1.5.

-- Juha

In the scenario that I do, I have to use transparent mode, because the authentication is done on Asterisk servers. And for this issue, (using the same CSeq) the authentication process is not successful. So, I have to manage the value of CSeq by Kamailio or have some update in Sems so that at least could relay the Cseq without changing. What do you think?

On Sun, Dec 19, 2021 at 5:09 PM Juha Heinanen jh@tutpro.com wrote:

Mojtaba writes:

...

Yes, I agree with you, This is an exception related to 401(Unauthorized) and 407 (Proxy Authentication Required) responses. In these situations, The CSeq header field value should be incremented.

SEMS SBC does support SIP authentication, but looks like not in transparent mode. From Readme.sbc.txt:

SIP authentication

The SBC can perform SIP digest authentication. To use SIP authentication, the uac_auth module needs to be loaded.

SIP authentication is enabled by the following parameters, separately for both call legs:

# Authentication for B leg (second/callee leg): enable_auth "yes" or "no" auth_user authentication user auth_pwd authentication password # Authentication for A leg (first/caller leg): enable_aleg_auth "yes" or "no" auth_aleg_user authentication user auth_aleg_pwd authentication password

Note: The 'A' leg is always the first leg, the one from the caller. 'B' leg is the one to callee: caller <--- A (first) leg ---> SEMS <--- B (second) leg ---> callee

Example: enable_auth=yes auth_user=$H(P-Auth-B-User) auth_pwd=$H(P-Auth-B-Pwd) enable_aleg_auth=yes auth_aleg_user=$H(P-Auth-A-User) auth_aleg_pwd=$H(P-Auth-A-Pwd)

Perhaps yeti-switch/sems-yeti can do it also in transparent mode.

-- Juha

According to RFC 3261 (section 8.1.1.5), as @Juha Heinanen mentioned, the Cseq value can be arbitrary, It means the CSeq value can start from any number. But according to RFC 3261 (section 22.2), as @Henning Westerholt hw@gilawa.com mentioned, the value of CSeq must increment for 401 (Unauthorized) or 407 (Proxy Authentication Required) responses. Then for those who want to use the Sems project, keep in mind that the Sems does not follow these specifications. With Best Regards

On Mon, Dec 20, 2021 at 7:43 PM Juha Heinanen jh@tutpro.com wrote:

Mojtaba writes:

...

So, I have to manage the value of CSeq by Kamailio or have some update in Sems so that at least could relay the Cseq without changing. What do you think?

If your Kamailio is between SEMS and Asterisk, you could try to increase CSeq value by some constant in all requests from SEMS to Asterisk.

-- Juha