Bug: port in contact header not evaluated/set correctly for TLS?

TS
Tobias Schneider
Mon, Feb 3, 2020 10:19 AM

Hello,

we used PJSUA application for testing TLS functionality in PJSUA lib. As we need to add a custom contact header from calling endpoint we just added --id="sip:111@192.168.13.62" and custom contact header  --contact="sip:111@192.168.13.62:12345;transport=TLS" as parameter. We used random port 12345 within contact header as there is no separate configuration option to set a port the be used. When
using those options, making an outgoing call will work, but it won't use port 12345, instead it will dynamically create a new TLS port (here 37195) for communication:

   09:20:16.209          tlsc0x1dbced8  ....TLS transport 192.168.13.62:37195 is connecting to 192.168.13.62:5076...
   09:20:16.209           pjsua_core.c  ....TX 1496 bytes Request msg INVITE/cseq=84 (tdta0x1db7d68) to TLS 192.168.13.62:5076: 
   INVITE sip:192.168.13.62:5076;transport=TLS SIP/2.0
   Via: SIP/2.0/TLS 192.168.13.62:37195;rport;branch=z9hG4bKPjAH-olL-uvPIfgGRq7R2LOCxcljwLKLkx;alias
   Max-Forwards: 70
   From: sip:111@192.168.13.62;tag=XVuDjOu-p7QUQVPojfeOmdFTtPwfBbDp
   To: sip:192.168.13.62
   Contact: sip:111@192.168.13.62:12345;transport=TLS
   Call-ID: E1bJSm9Tq5a92-Yekre57oFzOJyGfBmt
   CSeq: 84 INVITE
   Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
   Supported: replaces, 100rel, timer, norefersub
   Session-Expires: 1800
   Min-SE: 90
   User-Agent: PJSUA v2.9 Linux-4.12.14/x86_64/glibc-2.26
   Content-Type: application/sdp
   Content-Length:   830

This invite will initiate a working call due to correct Via-Tag, but due to Contact being set to the given value (especially port), any request from other party (like a bye from remote) will not be received at caller:

   09:20:23.624          tlsc0x17ec868  ....TLS transport 192.168.13.62:35141 is connecting to 192.168.13.62:12345...
   09:20:23.624           pjsua_core.c  ....TX 440 bytes Request msg BYE/cseq=26574 (tdta0x184be68) to TLS 192.168.13.62:12345:
   BYE sip:111@192.168.13.62:12345;transport=TLS SIP/2.0
   Via: SIP/2.0/TLS 192.168.13.62:34937;rport;branch=z9hG4bKPjReRIhcmUrRXCJabWfJQevTVVrJlNKQTC;alias
   Max-Forwards: 70
   From: sip:192.168.13.62;tag=c8EPCtRyXtgIwkPlydxTc2vW.CfqCin2
   To: sip:111@192.168.13.62;tag=XVuDjOu-p7QUQVPojfeOmdFTtPwfBbDp
   Call-ID: E1bJSm9Tq5a92-Yekre57oFzOJyGfBmt
   CSeq: 26574 BYE
   User-Agent: PJSUA v2.9 Linux-4.12.14/x86_64/glibc-2.26
   Content-Length:  0

We assume this is a bug in handling custom contact headers, especially the port being set in there. Is there any configuration to set connect port like in contact header?

The following configuration has been used at caller side:

pjsua SIP client config file

--app-log-level=6
--id sip:111@192.168.13.62
--contact sip:111@192.168.13.62:12345;transport=TLS
--no-udp
--local-port=5065
--use-tls
--tls-ca-file data/test_ca.crt
--tls-cert-file data/test_host.crt
--tls-privkey-file data/test_host.key
--use-srtp=1
--srtp-secure=1
--log-file=c_pjsua.logs

Please let us know how to handle this and if this is a bug.

Best regards,

Tobias Schneider

Hello, we used PJSUA application for testing TLS functionality in PJSUA lib. As we need to add a custom contact header from calling endpoint we just added --id="sip:111@192.168.13.62" and custom contact header  --contact="<sip:111@192.168.13.62:12345;transport=TLS>" as parameter. We used random port 12345 within contact header as there is no separate configuration option to set a port the be used. When using those options, making an outgoing call will work, but it won't use port 12345, instead it will dynamically create a new TLS port (here 37195) for communication:    09:20:16.209          tlsc0x1dbced8  ....TLS transport 192.168.13.62:37195 is connecting to 192.168.13.62:5076...    09:20:16.209           pjsua_core.c  ....TX 1496 bytes Request msg INVITE/cseq=84 (tdta0x1db7d68) to TLS 192.168.13.62:5076:     INVITE sip:192.168.13.62:5076;transport=TLS SIP/2.0    Via: SIP/2.0/TLS 192.168.13.62:37195;rport;branch=z9hG4bKPjAH-olL-uvPIfgGRq7R2LOCxcljwLKLkx;alias    Max-Forwards: 70    From: sip:111@192.168.13.62;tag=XVuDjOu-p7QUQVPojfeOmdFTtPwfBbDp    To: sip:192.168.13.62    Contact: <sip:111@192.168.13.62:12345;transport=TLS>    Call-ID: E1bJSm9Tq5a92-Yekre57oFzOJyGfBmt    CSeq: 84 INVITE    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS    Supported: replaces, 100rel, timer, norefersub    Session-Expires: 1800    Min-SE: 90    User-Agent: PJSUA v2.9 Linux-4.12.14/x86_64/glibc-2.26    Content-Type: application/sdp    Content-Length:   830 This invite will initiate a working call due to correct Via-Tag, but due to Contact being set to the given value (especially port), any request from other party (like a bye from remote) will not be received at caller:    09:20:23.624          tlsc0x17ec868  ....TLS transport 192.168.13.62:35141 is connecting to 192.168.13.62:12345...    09:20:23.624           pjsua_core.c  ....TX 440 bytes Request msg BYE/cseq=26574 (tdta0x184be68) to TLS 192.168.13.62:12345:    BYE sip:111@192.168.13.62:12345;transport=TLS SIP/2.0    Via: SIP/2.0/TLS 192.168.13.62:34937;rport;branch=z9hG4bKPjReRIhcmUrRXCJabWfJQevTVVrJlNKQTC;alias    Max-Forwards: 70    From: <sip:192.168.13.62>;tag=c8EPCtRyXtgIwkPlydxTc2vW.CfqCin2    To: <sip:111@192.168.13.62>;tag=XVuDjOu-p7QUQVPojfeOmdFTtPwfBbDp    Call-ID: E1bJSm9Tq5a92-Yekre57oFzOJyGfBmt    CSeq: 26574 BYE    User-Agent: PJSUA v2.9 Linux-4.12.14/x86_64/glibc-2.26    Content-Length:  0 We assume this is a bug in handling custom contact headers, especially the port being set in there. Is there any configuration to set connect port like in contact header? The following configuration has been used at caller side: # pjsua SIP client config file --app-log-level=6 --id sip:111@192.168.13.62 --contact <sip:111@192.168.13.62:12345;transport=TLS> --no-udp --local-port=5065 --use-tls --tls-ca-file data/test_ca.crt --tls-cert-file data/test_host.crt --tls-privkey-file data/test_host.key --use-srtp=1 --srtp-secure=1 --log-file=c_pjsua.logs Please let us know how to handle this and if this is a bug. Best regards, Tobias Schneider