I'm trying to make a SIP request to a SIP server, using pjsua, a SIP client by pjsip (version 2.10, 2020-02-14). Starting the client this way:
pjsua-x86_64-apple-darwin19.4.0 --id sip:addreessee#sever_host_name:5061;transport=tcp --no-udp
Using the "S" command to send an arbitrary REQUEST, typing a SIP method (I tried with MESSAGE and others) to use in the request and than adding as destination URI "sip:sever_host_name:5061"
The result is:
Destination URI: sip:addreessee#sever_host_name:5061
13:48:02.121 pjsua_core.c .TX 342 bytes Request msg MESSAGE/cseq=53264 (tdta0x7f96c501cca8) to UDP sever_host_name:5061:
MESSAGE sip:addresse#sever_host_name:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.15:5060;rport;branch=z9hG4bKPjI-s3KUBrnruOqLAKEtCOLnJ.jJPKmoDe
Max-Forwards: 70
From: <sip:addreessee#server_host_name>;tag=1lsf1PY19Qc4fk-8IhoqTV9plx3kX0yC
To: <sip:addreessee#server_host_name>
Call-ID: -X2iZRlerEaevvVvOZlAX5STQnBaGuN2
CSeq: 53264 MESSAGE
Content-Length: 0
So the request is sent over UDP transport layer, not TCP. Can anyone tell me what am I doing wrong?
You should add ;transport=tcp to your request URI each time.
You can read more here (link)
Related
I keep running into this error after setting up the webphone using ringcentral-call-js.
The webphone will work for a few phone calls but eventually run into this. I have no idea what could be causing it and I don't find any information online about it.
SIP/2.0 603 Too Many Contacts
Via: SIP/2.0/WSS femcvfqh8p1f.invalid;branch=z9hG4bK6653901;received=24.108.116.162
To: <sip:1##########*101#sip.devtest.ringcentral.com>;tag=7BvYdcd7fcr
From: <sip:1##########*101#sip.devtest.ringcentral.com>;tag=vbdr8qojhl
Call-ID: 8frudde185qca0cgkkbrg1
CSeq: 3632 REGISTER
Content-Length: 0
I have a scenario where my terminal receives re-invite from server and my terminal first responds with 100 trying and then sends 200 Ok and waits for ACK from server. But after sending 200 Ok ,my terminal receives this re-invite again .
So my question is what should be the response by my terminal .It should re-transmit the same 200 Ok or it should send 491 request pending.
You should be re-transmitting the same 200 OK response for any duplicate INVITE requests.
See the SIP RFC 17.1.1.1 Overview of INVITE Transaction for teh details.
During application sharing with Microsoft Lync Client (Mac OS X), TCP ACK with RST flag is sent from my application end to Lync end against TCP Zero Window packets and call gets dropped.
FYI:
My Application End: 172.16.6.106:55848
Lync End (Remote): 172.16.14.58:18627
Environment:
My Application End: Centos/Linux
Lync End: Mac OSX
Shared Over Wifi.
EDIT
Wireshark TCP Dump
Lync BYE message to my Application:
BYE sip:172.16.6.106:48038;transport=tls;ms-opaque=28c9d310c1;ms-received-cid=BEED00;grid SIP/2.0
ms-user-logon-data: RemoteUser
Via: SIP/2.0/TLS 172.16.6.252:5061;branch=z9hG4bKB5634D63.2E095CFF28141DF6;branched=FALSE;ms-internal-info="agIDti2ZsTK4cWfhAGG1qbj2usseveww7YKemPpN3Jvhv_XAkuuCofIQAA"
Max-Forwards: 67
Via: SIP/2.0/TLS 192.168.2.3:51217;branch=z9hG4bK77E14D58.4A2E43E7B13911D2;branched=FALSE;ms-received-port=51217;ms-received-cid=BEE600
Authentication-Info: NTLM qop="auth", opaque="4207B105", srand="D2C8703A", snum="21", rspauth="010000008bc2daa4dc3b08b864000000", targetname="Lync-FE.LTN2013-Dev.local", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 192.168.2.4:50740;branch=z9hG4bKFF62C04C.B8AD61CF28131DF6;branched=FALSE;ms-received-port=50740;ms-received-cid=1117700
Via: SIP/2.0/TLS 172.16.14.58:30689;received=172.16.14.58;ms-received-port=57719;ms-received-cid=BEE400
From: "" <sip:test1#ltn2013-dev.net>;epid=48777ee2e9;tag=dd8ced12ab
To: <sip:ilanaroom#ltn2013-dev.net>;tag=1442263920;epid=14422639
Call-ID: RkdVRZrTUlhKLke0Et9MiVaJTOJd5UMJKljncCC1
CSeq: 1 BYE
User-Agent: UCCAPI/4.0.7323.0 MC/14.0.5093.11 (Microsoft Lync for Mac 2011)
ms-client-diagnostics: 34; reason="Call terminated on a mid-call media failure where both endpoints are remote";MediaDebug="Diag:LastError:time out,time:3651253182890;LastRTP Seq:30662,SeqDelta:1,time:3651253152751;LastRTCP time:3651253151390;Last transport receive error:0x0,time:0;Last transport send error:0x0,time:0;"
Content-Length: 0
The capture excerpt shown indicates that Lync is sending data to your Ap Ok but, for whatever reason, is unwilling to accept any data from your Ap (since the advertised window from 172.16.14.58 is 0).
One possibilityfor the RST from your Ap: your Ap has data to send to Lync but can't (since the win = 0) and eventually gives up.
Obviously, this doesn't help much other than to suggest that there's a problem with the Lync end. It's possible that examining a complete capture would provide more information.
For example: was the Ap previously able to send data ? What was the history of the window advertised by Lync ? and so on.
Update:
*Examining the capture you've posted a link to:
It looks quite normal (other than the zero-window stuff at the end).
Starting at about the 91 sec point, the Lync server stops accepting data (win=0), sends some short messages back to your client and then your client sends an RST to the server 30 secs after the server stops accepting data.
So: there's not really any info in the capture which indicates anything much about what's going on with the Lync server.
I do note that just before the win=0 from the server, the windows advertised by the server are smaller than the range advertised previously. (Note: I expect that the actual window size is larger than that seemingly advertised because there's a "window size scale factor" greater than 1 involved. Wireshark doesn't know the scale factor since the original TCP connection establishment handshake is not part of the capture).
I have a problem with TCP socket when using HTTP tunneling over proxy.
Client (C++) opens a TCP socket to a server (JAVA). I added support for HTTP proxy. Everything worked good, client sends "HTTP connect" request like this and continues to plain TCP connection after:
CONNECT servername:5555 HTTP/1.1
Host: servername:5555
Proxy-Connection: Keep-Alive
HTTP/1.1 200
However, if idle timeout is configured in proxy and there is no actual data sent, connection is terminated though client sends TCP keep alive packets every 60 seconds. Idle timeout is configured to 10 minutes.
TCP keep alive is configured as following:
WSAIoctl(socket, SIO_KEEPALIVE_VALS, &alive, sizeof(alive), NULL, 0, &dwBytesRet, NULL, NULL)
client IP - 192.168.91.xxx
Proxy IP - 192.168.92.yyy
244 47.133017000 192.168.91.xxx 192.168.92.yyy TCP 55 [TCP Keep-Alive] 64351 > 808 [ACK] Seq=4336 Ack=13084 Win=65700 Len=1
245 47.133336000 192.168.92.yyy 192.168.91.xxx TCP 66 [TCP Keep-Alive ACK] 808 > 64351 [ACK] Seq=13084 Ack=4337 Win=65536 Len=0 SLE=4336 SRE=4337
Any ideas how to keep connection alive?
I tried to add "Connection: Keep-Alive" header though HTTP1.1 should do it automatically. It didn't help anyway.
This is a timeout at the application layer, e.g. the connection is idle because no application data are sent. What you've tried will not work because:
Connection: keep-alive is for having multiple HTTP requests over a single connection. This does not apply here because from the view of the proxy there is only a single request (CONNECT).
TCP keep-alive is to notice if the peer is not reachable any longer (died without closing connection or connection broke somewhere in the middle). It does not apply for cases, where the TCP connection is still alive, but it is idle (no application data).
Having a idle timeout for the proxy makes sense. The idea of HTTP is, that the client sends a request and the server sends a response. If it is idle while receiving the request or the response usually something is broken (or you have a reaaaaaly slow connection). If it is idle after request and response finished it is perfectly valid to close the connection, even if the client asked for Connection: keep-alive, because keep-alive is not a requirement on the server but only a suggestion to keep the connection open for more requests if the server has enough resources to do so.
I am using Xlite at one end for sending INVITE.
If i use Kamailio 4.0.1 as outbound proxy,in the call flow it adds lr=on as mentioned below WIRESHARK trace :
Record-Route:
Via: SIP/2.0/UDP 10.44.104.149;branch=z9hG4bK0ecf.1bd4c266.0
Via: SIP/2.0/UDP 10.44.104.160:5998;branch=z9hG4bK-d8754z-829f7d43eed09018-1---d8754z-;rport=5998
and after that the pbx sends 503 response for the INVITE.
but as per RFC 3665 for the call flow ,the lr should be blank as :
Record-Route:
is there any configuration change needed in the Kamailio to meet REcord Route as per RFC 3665 ie lr without On value.
You have to set parameter enable_full_lr for rr module to 0, see:
http://kamailio.org/docs/modules/stable/modules/rr.html#idp21848