11 Dec
2021
11 Dec
'21
1:26 p.m.
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
17 Dec
17 Dec
1:27 p.m.
Any update on this?
On Sat, Dec 11, 2021, 13:56 Mojtaba <mespio(a)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
3:16 p.m.
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(a)gmail.com>om>:
Any update on this?
On Sat, Dec 11, 2021, 13:56 Mojtaba <mespio(a)gmail.com> wrote:
--
BR,
Denys Pozniak
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(a)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
18 Dec
18 Dec
12:05 a.m.
@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(a)tutpro.com> wrote:
Mojtaba writes:
--
--Mojtaba Esfandiari.S
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(a)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
10:45 a.m.
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
5:08 p.m.
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(a)tutpro.com> wrote:
Mojtaba writes:
--
--Mojtaba Esfandiari.S
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(a)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
5:27 p.m.
Mojtaba writes:
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.
As I already quoted, RFC 3261 specifies:
8.1.1.5 CSeq
For non-REGISTER requests outside of a dialog, the sequence number
value is arbitrary.
Section 12.1 tells how dialogs are created:
Dialogs are created through the generation of non-failure responses
to requests with specific methods. Within this specification, only
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog.
401 is a failure response. Thus no dialog is created and in the second
INVITE sems is allowed to use whatever CSeq value.
If Asterisk does not allow that, complain Asterisk about it.
-- Juha
6:17 p.m.
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
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Juha Heinanen
Sent: Saturday, December 18, 2021 3:27 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Issue Bug in SEMS (transparent SBC profile)
Mojtaba writes:
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.
As I already quoted, RFC 3261 specifies:
8.1.1.5 CSeq
For non-REGISTER requests outside of a dialog, the sequence number
value is arbitrary.
Section 12.1 tells how dialogs are created:
Dialogs are created through the generation of non-failure responses
to requests with specific methods. Within this specification, only
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog.
401 is a failure response. Thus no dialog is created and in the second INVITE sems is
allowed to use whatever CSeq value.
If Asterisk does not allow that, complain Asterisk about it.
-- Juha
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)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
6:29 p.m.
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
19 Dec
19 Dec
3:47 p.m.
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(a)tutpro.com> wrote:
Henning Westerholt writes:
--
-With Best Regards
*-- Mojtaba Esfandiari.S*
*-- Ph.D. student and Research Affiliate, *
*-- Technical Manager at IP-PBX Laboratory, Ferdowsi University of Mashhad,
Iran.*
-- Mobile: +98-915-117-6713
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
4:39 p.m.
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
20 Dec
20 Dec
12:47 p.m.
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(a)tutpro.com> wrote:
Mojtaba writes:
--
--Mojtaba Esfandiari.S
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
7:13 p.m.
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
21 Dec
21 Dec
1:05 p.m.
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(a)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(a)tutpro.com> wrote:
Mojtaba writes:
--
--Mojtaba Esfandiari.S
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
1067
days inactive
1077
days old
14 comments
4 participants
participants (4)
-
Denys Pozniak -
Henning Westerholt -
Juha Heinanen -
Mojtaba