Well, it is not really a bug. If the softphone in question does proper port and connection managment, all is fine. for p2p and 'one hop communication' it is ok, since the destination has an established tcp connection which could be reused, as long as it will do that (like Joshua indicated). the softphone of course has to use a listener port in contact headers for requests that are expected to be proxied, like invites. so for a register where the registrar is the direct receipient, the src port of the tcp connection could be reused, as long as the registrar will not try to set up a new connection but reuse the existing one. regarding pjsip.conf, i take it that is asterisk and i really have no insights in how its pjsip res works Regards, Harry Von meinem iPad gesendet > Am 20.03.2015 um 05:06 schrieb Anatoli <me at anatoli.ws>: > > 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" <jcolp at digium.com> > An: "pjsip list" <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: www.digium.com & www.asterisk.org > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at 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/20150321/5eab788d/attachment.html>
