|
Sorry to bug everyone again. I did not get a single response. Here is what's happening. SIP client uses PJSIP and TCP to send a REGISTER request out. Why the port values under Contact and Via differ if transport is TCP or TLS? The client uses an ephemeral port. This would be wrong since the server tends to use IP:port under Contact to reach the client. If the client is behind a firewall, this connection will not work. At the same time, the client will keep TCP connection given under Via header open all the time. If Contact had the same IP:port, as mentioned under Via, the server will reuse existing TCP connection and will have no problems reaching the client. Can anyone shed some light on this, please? Refer below to my previous email in which I provide example of PJSIP wrong doings (in my opinion).
Regards, Zarko From: Žarko Coklin <zcoklin@xxxxxxxxxxx>
Sent: February 1, 2017 4:55 PM To: pjsip@xxxxxxxxxxxxxxx Subject: PJSIP 2.4.5 when using TCP and TLS references different ports in Via and Contact headers - why? Hello,
when using PJSIP over TCP and TLS I noticed a strange discrepancy in ports found under Via and Contact headers. Source port from which the request is physically sent out matches exactly the value found in a Via header. Where does the PJSIP get the port that it puts in a Contact header value? And why is that different than what found in a Via header value?
See the example given below for the outgoing REGISTER request. It physically comes out of port 38668 and that is exactly what is found in a Via header. Apparently, the PJSIP stack then goes on and according to some weird rules it updates a Contact header value (log is marked in yellow) and decides to put a bogus port 34143 in a Contact header!??
It really does not make sense to me. Is this a bug? Or, is this something that can be configured to force the PJSIP stack so that a port in Contact header matches a port in a Via header, and they match a real physical port used to send the message out?
Regards, Zarko
14:48:33.931 /tmp/pjsip/pjs Starting
14:48:33.931 tcptp:6060 SIP TCP listener ready for incoming connections at 192.168.1.154:6060
14:48:33.931 pjsua_acc.c Adding account: id=sip:155@192.168.1.58:60050;transport=TCP
14:48:33.931 pjsua_acc.c .Account sip:155@192.168.1.58:60050;transport=TCP added with id 2
14:48:33.931 pjsua_acc.c .Acc 2: setting registration..
14:48:33.931 tcpc0x1a246c8 ..TCP client transport created
14:48:33.931 tcpc0x1a246c8 ..TCP transport 192.168.1.154:34143 is connecting to 192.168.1.58:60050...
14:48:33.932 pjsua_acc.c ..Contact for acc 2 updated for SIP outbound: <sip:155@192.168.1.154:34143;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000a3fe1a18>"
14:48:33.932 endpoint ..Request msg REGISTER/cseq=62802 (tdta0x1a27110) created.
14:48:33.932 tcpc0x1a290f8 ..TCP client transport created
14:48:33.932 tcpc0x1a290f8 ..TCP transport 192.168.1.154:48137 is connecting to 192.168.1.58:60050...
14:48:33.932 tsx0x1a2ab98 ...Transaction created for Request msg REGISTER/cseq=62803 (tdta0x1a27110)
14:48:33.932 tsx0x1a2ab98 ..Sending Request msg REGISTER/cseq=62803 (tdta0x1a27110) in state Null
14:48:33.932 sip_resolve.c ...Target '192.168.1.58:60050' type=TCP resolved to '192.168.1.58:60050' type=TCP (TCP transport)
14:48:33.932 tcpc0x1a2b958 ...TCP client transport created
14:48:33.932 tcpc0x1a2b958 ...TCP transport 192.168.1.154:38668 is connecting to 192.168.1.58:60050...
14:48:33.932 pjsua_core.c ...TX 723 bytes Request msg REGISTER/cseq=62803 (tdta0x1a27110) to TCP 192.168.1.58:60050:
REGISTER sip:155@192.168.1.58:60050;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 192.168.1.154:38668;rport;branch=z9hG4bKPj709b61ee-dca4-41bf-9a60-76a7ac945d91;alias
Route: <sip:155@192.168.1.58:60050;transport=TCP;lr>
Max-Forwards: 70
From: <sip:155@192.168.1.58>;tag=ac156726-f559-4e58-a9b1-ba5d094fb026
To: <sip:155@192.168.1.58>
Call-ID: c6aa8cd4-4cbb-4b8a-aae0-2602d5cfd2e6
CSeq: 62803 REGISTER
User-Agent: Fortivoice-Zarko
Supported: outbound, path
Contact: <sip:155@192.168.1.154:34143;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000a3fe1a18>"
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
|
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
