Direct connectivity issue (due to SIP "Contact")
RonR:
Quote from: obi-support2 on May 21, 2011, 12:31:17 am
You have this issue because you do not REGISTER on your SP1/2 main service.
Have you tried to enable X_KeepAliveEnable and set X_KeepAliveMsgType = stun,
(also set X_KeepAliveServer and X_KeepAliveServerPort to point to a valid stun server)?
Take a look at the NAT Traversal section in OBi Admin Guide. These options should
help with your particular situation.
FWIW, I have equal success with no registration. There needs to be a ProxyServer specified (127.0.0.1 works fine), but X_RegisterEnable can be disabled and X_KeepAliveServer and X_KeepAliveServerPort can be left blank. I tested this before making the post about using DID's with the OBi.
oleg:
RonR,
I am talking about the following part (from your log):
sendto 409a2996:5060(701)
SIP/2.0 200 OK
Call-ID: 4badf5336d2f1bcb11aa38807942a7ec@64.154.41.150
CSeq: 102 INVITE
Content-Length: 231
From: "2341234567" <sip:2341234567@64.154.41.150:5060>;tag=as1700e7ce
To: <sip:ipcomms@xxxxxxxx.dyndns.org>;tag=SP25d7da5ec7f09888c
Via: SIP/2.0/UDP 64.154.41.150:5060;branch=z9hG4bK0e1ed3b5;received=64.154.41.150;rport=5060
Server: OBIHAI/OBi110-1.2.1.2309
Contact: "RonR" <sip:u1234500000@192.168.1.140:5060>
Content-Type: application/sdp
v=0
o=- 6495 1 IN IP4 123.123.123.123
s=-
c=IN IP4 123.123.123.123
t=0 0
m=audio 16800 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian
RxFrom:409a2996:5060
ACK sip:u1234500000@192.168.1.140:5060 SIP/2.0
Via: SIP/2.0/UDP 64.154.41.150:5060;branch=z9hG4bK1fa4cd3b;rport
Max-Forwards: 70
From: "2341234567" <sip:2341234567@64.154.41.150:5060>;tag=as1700e7ce
To: <sip:ipcomms@xxxxxxxx.dyndns.org>;tag=SP25d7da5ec7f09888c
Contact: <sip:2341234567@64.154.41.150:5060>
Call-ID: 4badf5336d2f1bcb11aa38807942a7ec@64.154.41.150
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.2.13
Content-Length: 0
Note highlighted "Contact" - it contains your Obi local IP address. ipcomms server is smart enough to recognize mistake and it sends ACK to correct endpoint. Linksys device does not.
I am curious to see log with ipKall - could you please show?
And yes, I have port forwarded.
And I had tcpdump on WAN side of my router when I was troubleshooting ipKall first time - ACK did not come to my router. Later I noticed the same with Linksys and checked the log on Linksys side - that revealed the mystery - ACK sent to wrong address.
obi-support2,
as I said before and above ACK is being sent to undeliverable destination - how it may be related to NAT???
RonR:
Give me a couple minutes and I'll post a Syslog for IPKall...
RonR:
Sorry for the long delay - lots of distractions here today.
Here's the Syslog for an incoming call from IPKall.
oleg:
RonR,
attached is my very recent test with ipKall. Comparing logs I've noticed a few minor differences
- previously I used different local port. I've changed to 5060 (default) and re-tested - nothing changed.
- in your log user in "INVITE" is not the same as in "Contact"
INVITE sip:ipkall@xxxxxxxx.dyndns.org SIP/2.0
Contact: "RonR" <sip:u1234500000@192.168.1.140:5060>
unless it was result of obfuscation - can you point where do you specify them? may be it does the trick?
- you have never OBi software (OBIHAI/OBi110-1.2.1.2309)...
Navigation
[0] Message Index
[#] Next page
[*] Previous page