[SR-Users] Issue Bug in SEMS (transparent SBC profile)

Mojtaba mespio at gmail.com
Mon Dec 20 10:47:52 CET 2021


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 at 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
>


-- 
--Mojtaba Esfandiari.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20211220/669028ae/attachment.htm>


More information about the sr-users mailing list