Peter Cai wrote:
> Hi all,
>
> I'm testing PJSIP with TCP transport, with windows mesenger.
>
> The environment is like this
>
>
> PJ <-----TCP-----> PROXY <---------TCP-----------> Windows Messenger. (WM)
>
> I used the example "simple_pjsua.c" from PJ's web site:
>
> file:///E:/Software/Sites/pjsip_pjsip_docs_html/www.pjsip.org/pjsip/docs/html/page_pjsip_sample_simple_pjsuaua_c.htm
>
>
> Modified 2 lines to use TCP.
>
> << status = pjsua_transport_create(PJSIP_TRANSPORT_UDP, &cfg, NULL);
>
>>> status = pjsua_transport_create(PJSIP_TRANSPORT_TCP, &cfg, NULL);
>
> << cfg.reg_uri = pj_str("sip:" SIP_DOMAIN ";transport=tcp");
>
>>> cfg.reg_uri = pj_str("sip:" SIP_DOMAIN ";transport=tcp");
>
>
> According to the packages I captured, the process is:
>
> 1. PJ register with port 5060
> 2. PJ changed to register with a random selected port, 39122 e.g.,
> and un-register port 5060
> 3. PJ answer INVITE with 200 OK, with port 39122 in CONTACT header.
> 4. WM tries to connect to port 39122, but failed. So ACK could not be sent!
>
> PJ is not listening on 39122, but wrongly using it in CONTACT header of 200 OK.
It is difficult to find out what should be announced in the Contact
header. IIRC previously pjsip has put port 5060 into the Contact header.
This caused problems when pjsip was behind NAT - the proxy tried to
contact the client at 5060 but as the client was behind NAT it is
impossible. Then pjsip changed to the current behavior. This way, the
proxy finds out that it already has a TCP connection to this port (the
one openend by pjsip during registration) and thus is able to send
messages to the client.
Thus, fpr the typical scenario (client behind NAT, proxy is performing
record routing) this is the best solution.
Of course for other setups (proxy without record routing, no NATs) the
behavior is wrong.
regards
klaus
> If further information needed. I can provide captured packages.
