Hi all, Sorry for the delay. Harry, your scheme is correct, that is what I was observing. It looks like there are 2 problems involved in this issue. First one is what Joshua described, that res_pjsip won't reuse TCP connections if for the endpoint in question there is a transport=<transport_name> option specified in pjsip.conf. But, after studying a bit the SIP RFC, it looks like a lot of softphones (and some hardphones as well) don't implement the RFC correctly. On page 12 there is the following sentence: "While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests." This is what I'm observing with Wireshark on a Windows 7 box with the latest Jitsi softphone (both the server and the endpoints are inside a LAN): REGISTER sip:server_ip;transport=tcp SIP/2.0 Call-ID: dd753e83b597b5ca2a2e4f162775375e at 0:0:0:0:0:0:0:0 CSeq: 1 REGISTER From: "Name1" <sip:555@server_ip>;tag=1dde9f02 To: "Name1" <sip:555 at server_ip> Via: SIP/2.0/TCP host_ip:3409;branch=z9hG4bK-313537-071be23f01c7c2ee583675273d44e27d Max-Forwards: 70 User-Agent: Jitsi2.6.5390Windows 7 Expires: 600 Contact: "Name1" <sip:555 at host_ip:3409;transport=tcp;registering_acc=10_101_10_1>;expires=600 Content-Length: 0 OK, here Via says "send the responses to host_ip:3409" and Contact says "send new requests (INVITE, BYE), establishing a new TCP session, to.. the same host_ip:3409". If I understand it correctly, Contact should say host_ip:5060 or omit the port entirely for the default value to be applied. Nevertheless Jitsi listens on all 3 standard SIP ports: tcp/5060, tcp/5061 & udp/5060 on 0.0.0.0 (they are specified in the global SIP configuration section) BUT the 3409 (random) port appears in netstat as ESTABLISHED, *not* LISTENING and it doesn't accept new incoming connections. So, Jitsi expects incoming connections on 5060, but specifies the incoming port as 3409 in Contact field. Similar behavior is observed in Linphone on iPhone (from pjsip logger): <--- Received SIP request (477 bytes) from TCP:host2_ip:59911 ---> REGISTER sip:server_ip SIP/2.0 Via: SIP/2.0/TCP host2_ip:59911;alias;branch=z9hG4bK.3kRQgBAbb;rport From: <sip:777@server_ip>;tag=4Yzj~FqLz To: sip:777 at server_ip CSeq: 20 REGISTER Call-ID: 47V~RpZbNs Max-Forwards: 70 Supported: outbound Contact: <sip:777 at host2_ip:59911;transport=tcp>;+sip.instance="<urn:uuid:1e603d84-0b11-42a7-83cb-7c34f71e0089>" Expires: 600 User-Agent: LinphoneIphone/2.2.4.1-27-ge8ab36a (belle-sip/1.3.3) Content-Length: 0 Joshua, Harry please let me know if you too consider this behavior as a bug. On the other hand I can confirm that if an endpoint doesn't have the transport option specified in pjsip.conf, res_pjsip does reuse the TCP connection and everything works quite fine (the rewrite_contact option doesn't affect anything in this case, I've tested both with and without it). Not to forget or misunderstand, there should be a transport section with something like this: [transport-tcp] type = transport protocol = tcp bind = <server_ip> Otherwise res_pjsip won't listen on the TCP port. It just shouldn't be referenced from endpoint definitions. Regards, Anatoli From: pjsip [mailto:pjsip-bounces@xxxxxxxxxxxxxxx] On Behalf Of Harald Radke Sent: Wednesday, March 18, 2015 09:59 To: pjsip at lists.pjsip.org Subject: Re: Possible bug: stateless behavior when transport=tcp ah ok, I think I get it, focused on the reuse part of your message, not on the rewrite one (: hm...what is that good for? E.g. RFC5626? For the slow ones over here, the problem is, that rewrite_contact is used, which replaces the Method URI to be the contact one of the peer, but PJSIP creates a new TCP connection instead of searching for an existing tcp with that remote EP? Harry Gesendet: Mittwoch, 18. M?rz 2015 um 12:27 Uhr Von: "Joshua Colp" < <mailto:jcolp at digium.com> jcolp at digium.com> An: "pjsip list" < <mailto:pjsip at lists.pjsip.org> pjsip at lists.pjsip.org> Betreff: Re: [pjsip] Possible bug: stateless behavior when transport=tcp Harald Radke wrote: > hm... not sure if that is the issue here...the main prob IMHO that the > Asterisk PJSIP proxy tries to contact the source port of a TCP > connection the endpoint > used to send its REGISTER/INVITE, whatever, instead of using the > "official" EP's listener port for SIP requests (I take it is also 5060). > So if EP1 registered to Asterisk with TCP Connect: <EP_IP>:12345 <-----> > <AST_IP>:5060 > and then EP2 sends an INVITE to EP1 via Asterisk, the proxy tries to > create a TCP connection > <EP_IP>:12345 <-------> <AST_IP>:54321 > which fails, but should be: > <EP_IP>:5060 <---------> <AST_IP>:54321 > (Ports != 5060 are representing randomly drawn ones) If the transport option is specified as is rewrite_contact this is the exact behavior that will occur. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: <http://www.digium.com> www.digium.com & <http://www.asterisk.org> www.asterisk.org _______________________________________________ Visit our blog: <http://blog.pjsip.org> http://blog.pjsip.org pjsip mailing list <mailto:pjsip at lists.pjsip.org> pjsip at lists.pjsip.org <http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150320/f86f5350/attachment.html>
