|
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
