|
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
