|
OK, I was able to get down to the bottom of 'the issue'.
@Nenad, thanks for your feedback and hinting that RFC 3581 may do something with the observed behavior. However, that was not the case since the server I work with does not use a 'rport'.
Apparently, everything will work fine and here is why. My assumption was that PJSIP client will open at most 2 TCP connections towards the server: one on configured local SIP port (in my case it is 5060) and the one on the ephemeral port which is used to send transactions on. The fact is that PJSIP client will open at least 3 (if not more) TCP connections towards the server: 1) one on configured local SIP port (5060) 2) one it sends transactions on (this is given in a Via header and pretty much lasts until the transaction is complete and 20-30 seconds after it). Every new SIP request will cause another TCP connection to be opened towards the server. 3) one on the ephemeral port which it then advertises in Contact header. This connection stays around all the time while PJSIP stack is running. The client does not send any transactions on this connection. Its purpose is to make a route through a NAT and accepts any SIP messages it may come on it. And messages from the server will come on it cause that's what was advertised under the Contact header.
In my original example, 38668 port was used in Via cause REGISTER transactions happened over connection 2) and Contact port was saying 34143 cause that's what connection 3) was made on. That way things will go through NAT without any difficulties.
Now we now
Regards, Zarko From: pjsip <pjsip-bounces@xxxxxxxxxxxxxxx> on behalf of Nenad Milidrag <nmilidrag@xxxxxxxxxx>
Sent: February 28, 2017 3:23:06 PM To: pjsip list Subject: Re: [pjsip] PJSIP 2.4.5 when using TCP and TLS references different ports in Via and Contact headers - why? Hi Zarko, Do you have rport enabled, see RFC
3581. Looks like you do. If I remember correctly some clients will even register-unregister and register again to update port in contact header when rport is used. First
register would be used to learn port seen from outside of the NAT and second register will have learned port in contact header. This way registrar will save correct contact information so that when incoming call comes in message is not send to 5060 which
is not visible behind the NAT. Regards, Nenad
From: pjsip [mailto:pjsip-bounces@xxxxxxxxxxxxxxx]
On Behalf Of Žarko Coklin 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> 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
