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
Related
I'm trying to place an outbound call with RingCentral's web phone but am getting a "subscriber not found" message after a few seconds. Incoming calls work fine.
I doublechecked the auth and only get green checkmarks there.
The ringcentral dashboard even shows me the call was successful but there is no indication on the frontend that it ever worked.
I am in Sandbox mode on Ringcentral
Any ideas on what could be the culprit?
https://github.com/ringcentral/ringcentral-web-phone
SIP/2.0 404 Not Found
Via: SIP/2.0/WSS bgnnpnllhaei.invalid;branch=z9hG4bK2664025;received=184.66.244.45
To: <sip:+1###########sip.devtest.ringcentral.com>;tag=10.28.20.49-5070-c12bed41-9dc6-45ca-
From: <sip:1##########*101#sip.devtest.ringcentral.com>;tag=vr1es6q3l5
Call-ID: c1fjtb48lnq8e8h84tl6
CSeq: 7146 INVITE
Contact: <sip:+1###########104.245.63.102:8083;transport=wss>
p-rc-api-ids: party-id=p-a1c1431292a17z1862d48bf09z5beaf0000-1;session-id=s-a1c1431292a17z1862d48bf09z5beaf0000
Allow: SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO
Reason: SIP;cause=404;text="Subscriber not found"
Content-Length: 0
Why does regular expression ! doesn't work?
In my header_checks file I got
!/^Subject:.*NotBot.*/ REJECT fuck off
In my master.cf I use the cleanup daemon for checking
cleanup unix n - n - 0 cleanup
-o header_checks=pcre:/etc/postfix/header_checks
when I connect to stmpd via telnet to test (Good Subject) I get this
220 test.com ESMTP Postfix
HELO www.test.com
MAIL From: <test#test.com>
RCPT To: <test#test.com>
DATA
From: <tester#hahaha.com>
Subject: NotBot123
test250 test.com
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
.
550 5.7.1 fuck off
But Bad Subject's also work
220 example.com ESMTP Postfix
HELO www.example.com
MAIL From: <test#test.com>
RCPT To: <test#test.com>
DATA
From: <tester#hahaha.com>
Subject: hahaha
test250 test.com
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
.
550 5.7.1 fuck off
Fixed it! was pretty easy..
the check_headers is checked for every information in the mail.. so you need to use if/endif to check only Subject: field.
if /^Subject:/
!/^Subject:.*NotBot.*/ REJECT fuck off
endif
Dumb spammers suspended my email account due to abusing my open stmp port.
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)
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 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