30 Jun
2020
30 Jun
'20
12:21 a.m.
Hi
During the testing with Kamailio IMS, we found that SUBSCRIBE and
NOTIFY message flow between UE and P-CSCF is shown below.
SUBSCRIBE and its response: 192.168.1.102:9101 (port-c) ->
192.168.2.66:6101 (port-s)
NOTIFY: 192.168.2.66:5101 (port-c) -> 192.168.1.102:9100 (port-s)
based on the sip security, is it the expected behavior that they are
using port-c and port-s?
The reason why we asked is because we found that the NOTIFY did not
properly propagate to the UE due to different port addresses.
Does anyone have this experience? and how we can resolve it?
- RBK
7 Jul
7 Jul
8:37 a.m.
Hello,
On 30.06.20 00:21, BALL SUN wrote:
Hi
During the testing with Kamailio IMS, we found that SUBSCRIBE and
NOTIFY message flow between UE and P-CSCF is shown below.
SUBSCRIBE and its response: 192.168.1.102:9101 (port-c) ->
192.168.2.66:6101 (port-s)
NOTIFY: 192.168.2.66:5101 (port-c) -> 192.168.1.102:9100 (port-s)
based on the sip security, is it the expected behavior that they are
using port-c and port-s?
The reason why we asked is because we found that the NOTIFY did not
properly propagate to the UE due to different port addresses.
Does anyone have this experience? and how we can resolve it?
Not sure what you refer with port-c and port-s, but in kamailio you have
the option to enforce the local socket for sending the sip messages out.
See the force_send_socket(), set_send_socket() or $fs variable.
Usually, the NOTIFY should be sent from the socket where the SUBSCRIBE
was received.
However, not that in case of TCP/TLS, the connections may use ephemeral
ports, being different that the socket Kamailio is listening on.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
20 Jul
20 Jul
6:54 a.m.
sorry for my late reply.
What I am referring to is the SIP OPTIONS that P-CSCF (Kamailio IMS)
send to UE after REGISTRATION is completed.
Our question is why P-CSCF send SIP OPTIONS to UE using normal TCP
connection, not using IPSEC/ESP connection?
Below is the sample extracted from
https://www.sharetechnote.com/html/IMS_SIP_Procedure_Reg_Auth_IPSec.html
After the "401 Unauthorized" sendt from PCSCF to UE, the UE sends 2nd
REGISTER to PCSCF through the IPSEC/ESP tunnel. The SUBSCRIBE and
NOTIFY are all going through IPSEC/ESP connection. But, we observed
that P_CSCF sends SIP OPTIONS healthcheck to UE using unprotected
port. ie. <P-CSCF IP>:5060 -> <UE IP>:port-c, where port-c is a port
defined in the Security-Client on SIP REGISTER from UE.
[truncated]Security-Client: ipsec-3gpp; alg=hmac-md5-96;
ealg=des-ede3-cbc; spi-c=3384516058; spi-s=2766124529; port-c=8001;
port-s=8901,ipsec-3gpp; alg=hmac-md5-96; ealg=aes-cbc;
spi-c=3384516058; spi-s=2766124529; port-c=8001; port-s=8
[Security-mechanism]: ipsec-3gpp
alg: hmac-md5-96
ealg: des-ede3-cbc
spi-c: 3384516058 (0xc9bb9dda)
spi-s: 2766124529 (0xa4dfb5f1)
port-c: 8001
port-s: 8901
[Security-mechanism]: ipsec-3gpp
alg: hmac-md5-96
ealg: aes-cbc
spi-c: 3384516058 (0xc9bb9dda)
spi-s: 2766124529 (0xa4dfb5f1)
port-c: 8001
port-s: 8901
Below is the packet flows between UE (192.168.1.57) and P-CSCF (168.168168.66)
No. Time Source SrcPort
Destination DstPort Protocol Length DSCP Info
6 2020-07-20 04:17:05.030865 192.168.1.57 32100
168.168.168.66 5060 SIP 662 CS0 Request:
REGISTER sip:ims.mnc006.mcc454.3gppnetwork.org (1 binding) |
8 2020-07-20 04:17:05.031415 168.168.168.66 5060
192.168.1.57 32100 SIP 397 4 Status: 100
Trying |
12 2020-07-20 04:17:05.157922 168.168.168.66 5060
192.168.1.57 32100 SIP 927 4 Status: 401
Unauthorized - Challenging the UE |
*** BELOW is through IPSEC/ESP ***
26 2020-07-20 04:17:06.606762 192.168.1.57 8001
168.168.168.66 6106 SIP 86 CS0 Request:
REGISTER sip:ims.mnc006.mcc454.3gppnetwork.org (1 binding) |
28 2020-07-20 04:17:06.607409 168.168.168.66 6106
192.168.1.57 8001 SIP 422 4 Status: 100
Trying |
34 2020-07-20 04:17:06.741601 168.168.168.66 6106
192.168.1.57 8001 SIP 910 4 Status: 200 OK
(9 bindings) |
39 2020-07-20 04:17:07.182961 192.168.1.57 8001
168.168.168.66 6106 SIP 950 CS0 Request:
SUBSCRIBE sip:454061110000038@ims.mnc006.mcc454.3gppnetwork.org |
40 2020-07-20 04:17:07.186154 168.168.168.66 6106
192.168.1.57 8001 SIP 622 4 Status: 200
Subscription to REG saved |
49 2020-07-20 04:17:07.195560 168.168.168.66 5106
192.168.1.57 8901 SIP/XML 1058 4 Request: NOTIFY
sip:192.168.1.57:8901;alias=192.168.1.57~8001~1 |
50 2020-07-20 04:17:09.175092 192.168.1.57 8001
168.168.168.66 6106 SIP 950 CS0 Request:
SUBSCRIBE sip:99999999@ims.mnc001.mcc001.3gppnetwork.org |
51 2020-07-20 04:17:13.167390 192.168.1.57 8001
168.168.168.66 6106 SIP 950 CS0 Request:
SUBSCRIBE sip:99999999@ims.mnc001.mcc001.3gppnetwork.org |
52 2020-07-20 04:17:13.170202 168.168.168.66 6106
192.168.1.57 8001 SIP 622 4 Status: 200
Subscription to REG saved |
61 2020-07-20 04:17:13.179940 168.168.168.66 5106
192.168.1.57 8901 SIP/XML 1058 4 Request: NOTIFY
sip:192.168.1.57:8901;alias=192.168.1.57~8001~1 |
70 2020-07-20 04:17:13.659133 168.168.168.66 5106
192.168.1.57 8901 SIP/XML 1058 4 Request: NOTIFY
sip:192.168.1.57:8901;alias=192.168.1.57~8001~1 |
*** P-CSCF uses port 5060 as source port to send SIP OPTIONS to UE
tunnel port 8001, it is not going through ESP/IPSEC tunnel, why? This
causes UE did not response SIP OPTIONS properly.
71 2020-07-20 04:17:18.432320 168.168.168.66 5060
192.168.1.57 8001 SIP 441 4 Request: OPTIONS
sip:192.168.1.57:8901 |
72 2020-07-20 04:17:18.908989 168.168.168.66 5060
192.168.1.57 8001 SIP 441 4 Request: OPTIONS
sip:192.168.1.57:8901 |
73 2020-07-20 04:17:19.909063 168.168.168.66 5060
192.168.1.57 8001 SIP 441 4 Request: OPTIONS
sip:192.168.1.57:8901 |
On Tue, Jul 7, 2020 at 2:37 PM Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
On 30.06.20 00:21, BALL SUN wrote:
Hi
During the testing with Kamailio IMS, we found that SUBSCRIBE and
NOTIFY message flow between UE and P-CSCF is shown below.
SUBSCRIBE and its response: 192.168.1.102:9101 (port-c) ->
192.168.2.66:6101 (port-s)
NOTIFY: 192.168.2.66:5101 (port-c) -> 192.168.1.102:9100 (port-s)
based on the sip security, is it the expected behavior that they are
using port-c and port-s?
The reason why we asked is because we found that the NOTIFY did not
properly propagate to the UE due to different port addresses.
Does anyone have this experience? and how we can resolve it?
Not sure what you refer with port-c and port-s, but in kamailio you have
the option to enforce the local socket for sending the sip messages out.
See the force_send_socket(), set_send_socket() or $fs variable.
Usually, the NOTIFY should be sent from the socket where the SUBSCRIBE
was received.
However, not that in case of TCP/TLS, the connections may use ephemeral
ports, being different that the socket Kamailio is listening on.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
1373
days inactive
1394
days old
2 comments
2 participants
participants (2)
-
BALL SUN -
Daniel-Constantin Mierla