30 Jul
2013
30 Jul
'13
6:44 p.m.
Hi All,
Sorry for cross-posting this email to PJLIB, but maybe there are some things related.
Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP client
like iPhone using PJSIP as SIP library.
Basically once the iPhone side in close the call (TCP->UDP) I'm getting the error
below. Kamailio is running under a VPS
without
NATed network so it uses a real public address. Furthermore, note that tcp_main is
answering to a 192.168.2.98 ip address
which is the iPhone client. This looks really strange to me since it should answer
directly to the public/port used for
the registration
and not to a such kind of reserved address. The kamilio configuration is basically the
default with a very few changes
like NAT, rtpproxy and postgresql backend.
This problems doesn't happen at all when using UDP->UDP calls. But I cannot use it
because as you certain know UDP
connection under iPhone will not work when the application run in background mode.
Can someone suggest how to solve this issue or maybe suggest a TCP working solution for
iPhone?
Thanks in advance.
Roberto Fichera.
Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command "9483_9 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting session 1 on
ports 15604/17354
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in from callee,
603 in from caller, 957
relayed, 0 dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in from callee, 2
in from caller, 7 relayed, 0
dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports 15604/17354 is
cleaned up
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9483_9 0
Jul 30 16:21:55 proxy rtpproxy[2262]: "
Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command "9496_16 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj
as74e0c388"
Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request failed: session
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9496_16 E8
Jul 30 16:22:14 proxy rtpproxy[2262]: "
13 Aug
13 Aug
12:03 p.m.
Hello,
you should grab the ngrep for such call to understand better what
happens. Also, dumping the location records will be useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive
re-registration. To avoid trying to open connections behind nat, use
set_forward_no_connect() for calls involving nat traversal.
Cheers,
Daniel
On 7/30/13 6:44 PM, Roberto Fichera wrote:
Hi All,
Sorry for cross-posting this email to PJLIB, but maybe there are some things related.
Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP client
like iPhone using PJSIP as SIP library.
Basically once the iPhone side in close the call (TCP->UDP) I'm getting the error
below. Kamailio is running under a VPS
without
NATed network so it uses a real public address. Furthermore, note that tcp_main is
answering to a 192.168.2.98 ip address
which is the iPhone client. This looks really strange to me since it should answer
directly to the public/port used for
the registration
and not to a such kind of reserved address. The kamilio configuration is basically the
default with a very few changes
like NAT, rtpproxy and postgresql backend.
This problems doesn't happen at all when using UDP->UDP calls. But I cannot use it
because as you certain know UDP
connection under iPhone will not work when the application run in background mode.
Can someone suggest how to solve this issue or maybe suggest a TCP working solution for
iPhone?
Thanks in advance.
Roberto Fichera.
Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command "9483_9 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting session 1
on ports 15604/17354
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in from callee,
603 in from caller, 957
relayed, 0 dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in from callee,
2 in from caller, 7 relayed, 0
dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports 15604/17354
is cleaned up
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9483_9 0
Jul 30 16:21:55 proxy rtpproxy[2262]: "
Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command "9496_16 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj
as74e0c388"
Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request failed:
session
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9496_16 E8
Jul 30 16:22:14 proxy rtpproxy[2262]: "
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
1:10 p.m.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
Hello,
you should grab the ngrep for such call to understand better what happens. Also, dumping
the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive re-registration. To
avoid trying to open
connections behind nat, use set_forward_no_connect() for calls involving nat traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm.
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 7/30/13 6:44 PM, Roberto Fichera wrote:
Hi All,
Sorry for cross-posting this email to PJLIB, but maybe there are some things related.
Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP client
like iPhone using PJSIP as SIP
library.
Basically once the iPhone side in close the call (TCP->UDP) I'm getting the error
below. Kamailio is running under a VPS
without
NATed network so it uses a real public address. Furthermore, note that tcp_main is
answering to a 192.168.2.98 ip
address
which is the iPhone client. This looks really strange to me since it should answer
directly to the public/port used for
the registration
and not to a such kind of reserved address. The kamilio configuration is basically the
default with a very few changes
like NAT, rtpproxy and postgresql backend.
This problems doesn't happen at all when using UDP->UDP calls. But I cannot use it
because as you certain know UDP
connection under iPhone will not work when the application run in background mode.
Can someone suggest how to solve this issue or maybe suggest a TCP working solution for
iPhone?
Thanks in advance.
Roberto Fichera.
Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command "9483_9 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting session 1
on ports 15604/17354
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in from callee,
603 in from caller, 957
relayed, 0 dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in from callee,
2 in from caller, 7 relayed, 0
dropped
Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports 15604/17354
is cleaned up
Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9483_9 0
Jul 30 16:21:55 proxy rtpproxy[2262]: "
Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core> [tcp_main.c:4432]:
tcpconn_main_timeout(): connect
192.168.2.98:5060 failed (timeout)
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command "9496_16 D
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj
as74e0c388"
Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request failed:
session
12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9496_16 E8
Jul 30 16:22:14 proxy rtpproxy[2262]: "
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:33 p.m.
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
if received is not set, then means the register was not detected as
coming from behind nat. Is the phone using stun?
Again, put here the ngrep for registration and a call to see if
something is wrong with signaling. There is no help that we can provide
otherwise. The default config works fine for tcp and natted clients, I
use it everywhere for this case without issues.
Cheers,
Daniel
Hello,
you should grab the ngrep for such call to understand better what happens. Also, dumping
the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive re-registration. To
avoid trying to open
connections behind nat, use set_forward_no_connect() for calls involving nat traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm.
Cheers,
Roberto Fichera.
> Cheers,
> Daniel
>
> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>> Hi All,
>>
>> Sorry for cross-posting this email to PJLIB, but maybe there are some things
related.
>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP
client like iPhone using PJSIP as SIP
>> library.
>> Basically once the iPhone side in close the call (TCP->UDP) I'm getting
the error below. Kamailio is running under a VPS
>> without
>> NATed network so it uses a real public address. Furthermore, note that tcp_main
is answering to a 192.168.2.98 ip
>> address
>> which is the iPhone client. This looks really strange to me since it should
answer directly to the public/port used for
>> the registration
>> and not to a such kind of reserved address. The kamilio configuration is
basically the default with a very few changes
>> like NAT, rtpproxy and postgresql backend.
>>
>> This problems doesn't happen at all when using UDP->UDP calls. But I
cannot use it because as you certain know UDP
>> connection under iPhone will not work when the application run in background
mode.
>>
>> Can someone suggest how to solve this issue or maybe suggest a TCP working
solution for iPhone?
>>
>> Thanks in advance.
>> Roberto Fichera.
>>
>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>> 192.168.2.98:5060 failed (timeout)
>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command
"9483_9 D
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting
session 1 on ports 15604/17354
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in from
callee, 603 in from caller, 957
>> relayed, 0 dropped
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in from
callee, 2 in from caller, 7 relayed, 0
>> dropped
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports
15604/17354 is cleaned up
>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9483_9 0
>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>> 192.168.2.98:5060 failed (timeout)
>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command
"9496_16 D
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj
as74e0c388"
>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request failed:
session
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9496_16
E8
>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3:15 p.m.
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
I'm testing with a normal rtpproxy configuration. BTW udp -> udp work perfectly.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
if received is not set, then means the register was not detected as coming from behind
nat. Is the phone using stun? Hello,
you should grab the ngrep for such call to understand better what happens. Also, dumping
the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive re-registration. To
avoid trying to open
connections behind nat, use set_forward_no_connect() for calls involving nat traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm.
Again, put here the ngrep for registration and a call to see if something is wrong with
signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but seems that kamailio
doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
[root@proxy ~]# kamctl ul show 526
Contact::
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
Smartphone 1.0/iPhone>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
1.8.20.1>;reg-id=0
[root@proxy ~]#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
Cheers,
Daniel
Cheers,
Roberto Fichera.
> Cheers,
> Daniel
>
> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>> Hi All,
>>
>> Sorry for cross-posting this email to PJLIB, but maybe there are some things
related.
>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP
client like iPhone using PJSIP as SIP
>> library.
>> Basically once the iPhone side in close the call (TCP->UDP) I'm getting
the error below. Kamailio is running under
>> a VPS
>> without
>> NATed network so it uses a real public address. Furthermore, note that tcp_main
is answering to a 192.168.2.98 ip
>> address
>> which is the iPhone client. This looks really strange to me since it should
answer directly to the public/port used
>> for
>> the registration
>> and not to a such kind of reserved address. The kamilio configuration is
basically the default with a very few changes
>> like NAT, rtpproxy and postgresql backend.
>>
>> This problems doesn't happen at all when using UDP->UDP calls. But I
cannot use it because as you certain know UDP
>> connection under iPhone will not work when the application run in background
mode.
>>
>> Can someone suggest how to solve this issue or maybe suggest a TCP working
solution for iPhone?
>>
>> Thanks in advance.
>> Roberto Fichera.
>>
>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>> 192.168.2.98:5060 failed (timeout)
>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command
"9483_9 D
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting
session 1 on ports 15604/17354
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in from
callee, 603 in from caller, 957
>> relayed, 0 dropped
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in from
callee, 2 in from caller, 7
>> relayed, 0
>> dropped
>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports
15604/17354 is cleaned up
>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9483_9 0
>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>> 192.168.2.98:5060 failed (timeout)
>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command
"9496_16 D
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj
as74e0c388"
>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request failed:
session
>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply "9496_16
E8
>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:22 p.m.
The sip trace is incomplete, I don't see invite with credentials and
then I see an ACK sent via tcp on the right connection. That means a
negative response was received over tcp from the callee.
Daniel
On 8/13/13 3:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
if received
is not set, then means the register was not detected as coming from behind nat. Is the
phone using stun? Hello,
you should grab the ngrep for such call to understand better what happens. Also, dumping
the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive re-registration. To
avoid trying to open
connections behind nat, use set_forward_no_connect() for calls involving nat traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm. Again, put here the ngrep for registration and a
call to see if something is wrong with signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but
seems that kamailio doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
[root@proxy ~]# kamctl ul show 526
Contact::
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
Smartphone 1.0/iPhone>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
1.8.20.1>;reg-id=0
[root@proxy ~]#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
> Cheers,
> Daniel
>> Cheers,
>> Roberto Fichera.
>>
>>> Cheers,
>>> Daniel
>>>
>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>> Hi All,
>>>>
>>>> Sorry for cross-posting this email to PJLIB, but maybe there are some
things related.
>>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit
and TCP client like iPhone using PJSIP as SIP
>>>> library.
>>>> Basically once the iPhone side in close the call (TCP->UDP) I'm
getting the error below. Kamailio is running under
>>>> a VPS
>>>> without
>>>> NATed network so it uses a real public address. Furthermore, note that
tcp_main is answering to a 192.168.2.98 ip
>>>> address
>>>> which is the iPhone client. This looks really strange to me since it
should answer directly to the public/port used
>>>> for
>>>> the registration
>>>> and not to a such kind of reserved address. The kamilio configuration is
basically the default with a very few changes
>>>> like NAT, rtpproxy and postgresql backend.
>>>>
>>>> This problems doesn't happen at all when using UDP->UDP calls. But
I cannot use it because as you certain know UDP
>>>> connection under iPhone will not work when the application run in
background mode.
>>>>
>>>> Can someone suggest how to solve this issue or maybe suggest a TCP
working solution for iPhone?
>>>>
>>>> Thanks in advance.
>>>> Roberto Fichera.
>>>>
>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>> 192.168.2.98:5060 failed (timeout)
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command
"9483_9 D
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully
deleting session 1 on ports 15604/17354
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354
in from callee, 603 in from caller, 957
>>>> relayed, 0 dropped
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5
in from callee, 2 in from caller, 7
>>>> relayed, 0
>>>> dropped
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on
ports 15604/17354 is cleaned up
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>> 192.168.2.98:5060 failed (timeout)
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command
"9496_16 D
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request
failed: session
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:30 p.m.
On 08/13/2013 03:22 PM, Daniel-Constantin Mierla wrote:
The sip trace is incomplete, I don't see invite
with credentials and then I see an ACK sent via tcp on the right
connection. That means a negative response was received over tcp from the callee.
I think I'll restart from the default configuration so I'll removing all testing
code I wrote ;-) !
Daniel
On 8/13/13 3:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
wrote:
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
> Hello,
>
> you should grab the ngrep for such call to understand better what happens. Also,
dumping the location records will be
> useful (kamctl ul show).
>
> Also, be sure that tcp connection lifetime is long enough to survive re-registration.
To avoid trying to open
> connections behind nat, use set_forward_no_connect() for calls involving nat
traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm.
if received
is not set, then means the register was not detected as coming from behind nat. Is the
phone using stun? Again, put here the ngrep for registration and a
call to see if something is wrong with signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but
seems that kamailio doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
[root@proxy ~]# kamctl ul show 526
Contact::
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
Smartphone 1.0/iPhone>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
1.8.20.1>;reg-id=0
[root@proxy ~]#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
> Cheers,
> Daniel
>> Cheers,
>> Roberto Fichera.
>>
>>> Cheers,
>>> Daniel
>>>
>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>> Hi All,
>>>>
>>>> Sorry for cross-posting this email to PJLIB, but maybe there are some
things related.
>>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit
and TCP client like iPhone using PJSIP as SIP
>>>> library.
>>>> Basically once the iPhone side in close the call (TCP->UDP) I'm
getting the error below. Kamailio is running under
>>>> a VPS
>>>> without
>>>> NATed network so it uses a real public address. Furthermore, note that
tcp_main is answering to a 192.168.2.98 ip
>>>> address
>>>> which is the iPhone client. This looks really strange to me since it
should answer directly to the public/port used
>>>> for
>>>> the registration
>>>> and not to a such kind of reserved address. The kamilio configuration is
basically the default with a very few
>>>> changes
>>>> like NAT, rtpproxy and postgresql backend.
>>>>
>>>> This problems doesn't happen at all when using UDP->UDP calls. But
I cannot use it because as you certain know UDP
>>>> connection under iPhone will not work when the application run in
background mode.
>>>>
>>>> Can someone suggest how to solve this issue or maybe suggest a TCP
working solution for iPhone?
>>>>
>>>> Thanks in advance.
>>>> Roberto Fichera.
>>>>
>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>> 192.168.2.98:5060 failed (timeout)
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command
"9483_9 D
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully
deleting session 1 on ports 15604/17354
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354
in from callee, 603 in from caller, 957
>>>> relayed, 0 dropped
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5
in from callee, 2 in from caller, 7
>>>> relayed, 0
>>>> dropped
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on
ports 15604/17354 is cleaned up
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>> 192.168.2.98:5060 failed (timeout)
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command
"9496_16 D
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request
failed: session
>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:23 p.m.
On 08/13/2013 03:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
wrote:
I forgot to say that the received field is now present because I've changed the
route[NATDETECT] in the default configuration as
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
-->>> if (nat_uac_test("19") || proto != UDP) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(FLT_NATS);
}
#!endif
return;
}
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
if received
is not set, then means the register was not detected as coming from behind nat. Is the
phone using stun? Hello,
you should grab the ngrep for such call to understand better what happens. Also, dumping
the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive re-registration. To
avoid trying to open
connections behind nat, use set_forward_no_connect() for calls involving nat traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm. Again, put here the ngrep for registration and a
call to see if something is wrong with signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but
seems that kamailio doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
[root@proxy ~]# kamctl ul show 526
Contact::
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
Smartphone 1.0/iPhone>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
1.8.20.1>;reg-id=0
[root@proxy ~]#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 13:04:30 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=root 1263161426 1263161426 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 10782 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:526@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
Max-Forwards: 16.
From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
To: <sip:526@test.domain:5060>.
Contact: <sip:512@94.94.X.X:1025>.
Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
Cheers,
Daniel
> Cheers,
> Roberto Fichera.
>
>> Cheers,
>> Daniel
>>
>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>> Hi All,
>>>
>>> Sorry for cross-posting this email to PJLIB, but maybe there are some things
related.
>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and
TCP client like iPhone using PJSIP as SIP
>>> library.
>>> Basically once the iPhone side in close the call (TCP->UDP) I'm
getting the error below. Kamailio is running under
>>> a VPS
>>> without
>>> NATed network so it uses a real public address. Furthermore, note that
tcp_main is answering to a 192.168.2.98 ip
>>> address
>>> which is the iPhone client. This looks really strange to me since it should
answer directly to the public/port used
>>> for
>>> the registration
>>> and not to a such kind of reserved address. The kamilio configuration is
basically the default with a very few changes
>>> like NAT, rtpproxy and postgresql backend.
>>>
>>> This problems doesn't happen at all when using UDP->UDP calls. But I
cannot use it because as you certain know UDP
>>> connection under iPhone will not work when the application run in background
mode.
>>>
>>> Can someone suggest how to solve this issue or maybe suggest a TCP working
solution for iPhone?
>>>
>>> Thanks in advance.
>>> Roberto Fichera.
>>>
>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>> 192.168.2.98:5060 failed (timeout)
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received command
"9483_9 D
>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully deleting
session 1 on ports 15604/17354
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats: 354 in
from callee, 603 in from caller, 957
>>> relayed, 0 dropped
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP stats: 5 in
from callee, 2 in from caller, 7
>>> relayed, 0
>>> dropped
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on ports
15604/17354 is cleaned up
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>> 192.168.2.98:5060 failed (timeout)
>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received command
"9496_16 D
>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete request
failed: session
>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:25 p.m.
Can you get a ngrep trace for a registration as well (for the phone
using tcp)?
Daniel
On 8/13/13 3:23 PM, Roberto Fichera wrote:
On 08/13/2013 03:15 PM, Roberto Fichera wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
wrote:
I forgot to say that the received field is now present
because I've changed the
route[NATDETECT] in the default configuration as
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
-->>> if (nat_uac_test("19") || proto != UDP) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(FLT_NATS);
}
#!endif
return;
}
> [root@proxy ~]# kamctl ul show 526
> Contact::
>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
> Smartphone 1.0/iPhone>;reg-id=0
> [root@proxy ~]# kamctl ul show 512
> Contact::
>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
> 1.8.20.1>;reg-id=0
> [root@proxy ~]#
>
>
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> INVITE sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> User-Agent: DICE 1.8.20.1.
> Date: Tue, 13 Aug 2013 13:04:30 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 264.
> .
> v=0.
> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
> s=Asterisk PBX 11.3.0.
> c=IN IP4 94.94.X.X.
> t=0 0.
> m=audio 10782 RTP/AVP 0 110 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:110 speex/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
> #
> U 178.79.x.x:5060 -> 94.94.X.X:1025
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
> Server: kamailio (4.0.2 (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> INVITE sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> User-Agent: DICE 1.8.20.1.
> Date: Tue, 13 Aug 2013 13:04:30 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 264.
> .
> v=0.
> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
> s=Asterisk PBX 11.3.0.
> c=IN IP4 94.94.X.X.
> t=0 0.
> m=audio 10782 RTP/AVP 0 110 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:110 speex/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
> #
> U 178.79.x.x:5060 -> 94.94.X.X:1025
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
> Server: kamailio (4.0.2 (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> ACK sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> ACK sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> Max-Forwards: 16.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:1025>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> Max-Forwards: 16.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:1025>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
>
>> Cheers,
>> Daniel
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>> Hi All,
>>>>>
>>>>> Sorry for cross-posting this email to PJLIB, but maybe there are some
things related.
>>>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18
64bit and TCP client like iPhone using PJSIP as SIP
>>>>> library.
>>>>> Basically once the iPhone side in close the call (TCP->UDP)
I'm getting the error below. Kamailio is running under
>>>>> a VPS
>>>>> without
>>>>> NATed network so it uses a real public address. Furthermore, note
that tcp_main is answering to a 192.168.2.98 ip
>>>>> address
>>>>> which is the iPhone client. This looks really strange to me since it
should answer directly to the public/port used
>>>>> for
>>>>> the registration
>>>>> and not to a such kind of reserved address. The kamilio configuration
is basically the default with a very few changes
>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>
>>>>> This problems doesn't happen at all when using UDP->UDP calls.
But I cannot use it because as you certain know UDP
>>>>> connection under iPhone will not work when the application run in
background mode.
>>>>>
>>>>> Can someone suggest how to solve this issue or maybe suggest a TCP
working solution for iPhone?
>>>>>
>>>>> Thanks in advance.
>>>>> Roberto Fichera.
>>>>>
>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>> 192.168.2.98:5060 failed (timeout)
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received
command "9483_9 D
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully
deleting session 1 on ports 15604/17354
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats:
354 in from callee, 603 in from caller, 957
>>>>> relayed, 0 dropped
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP
stats: 5 in from callee, 2 in from caller, 7
>>>>> relayed, 0
>>>>> dropped
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on
ports 15604/17354 is cleaned up
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>> 192.168.2.98:5060 failed (timeout)
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received
command "9496_16 D
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete
request failed: session
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
>>>>> sr-users(a)lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla
wrote:
> Hello,
>
> you should grab the ngrep for such call to understand better what happens. Also,
dumping the location records will be
> useful (kamctl ul show).
>
> Also, be sure that tcp connection lifetime is long enough to survive re-registration.
To avoid trying to open
> connections behind nat, use set_forward_no_connect() for calls involving nat
traversal.
I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
which doesn't reuse the TCP port used by NATed clients. I've also notice that the
received
field isn't set at all, so this means that the contact will not get aliased at all.
I would really like to have a look to a working cfg file for TCP NATed clients that reuse
the TCP port.
Even better if the configuration is based on the fedora default rpm.
if received
is not set, then means the register was not detected as coming from behind nat. Is the
phone using stun? Again, put here the ngrep for registration and a
call to see if something is wrong with signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but
seems that kamailio doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
3:32 p.m.
On 08/13/2013 03:25 PM, Daniel-Constantin Mierla wrote:
Can you get a ngrep trace for a registration as well
(for the phone using tcp)?
Ok! I'll use pjsua from my local machine connecting in the same way as the
TCP client was doing. The TCP client it's an iPhone using the same pjlib library.
Daniel
On 8/13/13 3:23 PM, Roberto Fichera wrote:
On 08/13/2013 03:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
wrote:
I forgot to say that the received field is now present
because I've changed the
route[NATDETECT] in the default configuration as
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
-->>> if (nat_uac_test("19") || proto != UDP) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(FLT_NATS);
}
#!endif
return;
}
> [root@proxy ~]# kamctl ul show 526
> Contact::
>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>
> Smartphone 1.0/iPhone>;reg-id=0
> [root@proxy ~]# kamctl ul show 512
> Contact::
>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>
> 1.8.20.1>;reg-id=0
> [root@proxy ~]#
>
>
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> INVITE sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> User-Agent: DICE 1.8.20.1.
> Date: Tue, 13 Aug 2013 13:04:30 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 264.
> .
> v=0.
> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
> s=Asterisk PBX 11.3.0.
> c=IN IP4 94.94.X.X.
> t=0 0.
> m=audio 10782 RTP/AVP 0 110 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:110 speex/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
> #
> U 178.79.x.x:5060 -> 94.94.X.X:1025
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
> Server: kamailio (4.0.2 (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> INVITE sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> User-Agent: DICE 1.8.20.1.
> Date: Tue, 13 Aug 2013 13:04:30 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 264.
> .
> v=0.
> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
> s=Asterisk PBX 11.3.0.
> c=IN IP4 94.94.X.X.
> t=0 0.
> m=audio 10782 RTP/AVP 0 110 101.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:110 speex/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
> #
> U 178.79.x.x:5060 -> 94.94.X.X:1025
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 INVITE.
> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
> Server: kamailio (4.0.2 (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> ACK sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> U 94.94.X.X:1025 -> 178.79.x.x:5060
> ACK sip:526@test.domain:5060 SIP/2.0.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
> Max-Forwards: 70.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:5060>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> Max-Forwards: 16.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:1025>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
> #
> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
> Max-Forwards: 16.
> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
> To: <sip:526@test.domain:5060>.
> Contact: <sip:512@94.94.X.X:1025>.
> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
> CSeq: 102 ACK.
> User-Agent: DICE 1.8.20.1.
> Content-Length: 0.
> .
>
>
>> Cheers,
>> Daniel
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>> Hi All,
>>>>>
>>>>> Sorry for cross-posting this email to PJLIB, but maybe there are some
things related.
>>>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18
64bit and TCP client like iPhone using PJSIP as SIP
>>>>> library.
>>>>> Basically once the iPhone side in close the call (TCP->UDP)
I'm getting the error below. Kamailio is running under
>>>>> a VPS
>>>>> without
>>>>> NATed network so it uses a real public address. Furthermore, note
that tcp_main is answering to a 192.168.2.98 ip
>>>>> address
>>>>> which is the iPhone client. This looks really strange to me since it
should answer directly to the public/port used
>>>>> for
>>>>> the registration
>>>>> and not to a such kind of reserved address. The kamilio configuration
is basically the default with a very few
>>>>> changes
>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>
>>>>> This problems doesn't happen at all when using UDP->UDP calls.
But I cannot use it because as you certain know UDP
>>>>> connection under iPhone will not work when the application run in
background mode.
>>>>>
>>>>> Can someone suggest how to solve this issue or maybe suggest a TCP
working solution for iPhone?
>>>>>
>>>>> Thanks in advance.
>>>>> Roberto Fichera.
>>>>>
>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>> 192.168.2.98:5060 failed (timeout)
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received
command "9483_9 D
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete: forcefully
deleting session 1 on ports 15604/17354
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP stats:
354 in from callee, 603 in from caller, 957
>>>>> relayed, 0 dropped
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP
stats: 5 in from callee, 2 in from caller, 7
>>>>> relayed, 0
>>>>> dropped
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: session on
ports 15604/17354 is cleaned up
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR: <core>
[tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>> 192.168.2.98:5060 failed (timeout)
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received
command "9496_16 D
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete
request failed: session
>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
>>>>> sr-users(a)lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> you should grab the ngrep for such call to understand better what happens. Also,
dumping the location records
>> will be
>> useful (kamctl ul show).
>>
>> Also, be sure that tcp connection lifetime is long enough to survive
re-registration. To avoid trying to open
>> connections behind nat, use set_forward_no_connect() for calls involving nat
traversal.
> I'm using the default conf coming from fedora rpm. So, mainly the problem seems
related to kamailio
> which doesn't reuse the TCP port used by NATed clients. I've also notice that
the received
> field isn't set at all, so this means that the contact will not get aliased at
all.
>
> I would really like to have a look to a working cfg file for TCP NATed clients that
reuse the TCP port.
> Even better if the configuration is based on the fedora default rpm.
if received is not set, then means the register was not detected as coming from behind
nat. Is the phone using stun?
I'm testing with a normal rtpproxy configuration.
BTW udp -> udp work perfectly.
Again, put here the ngrep for registration and a
call to see if something is wrong with signaling. There is no help
that we can provide otherwise. The default config works fine for tcp and natted clients,
I use it everywhere for this
case without issues.
I tried the default cfg enabling both NAT and RTPproxy, but
seems that kamailio doesn't reuse TCP ports.
Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT, from
kamailio point of view
4:17 p.m.
On 08/13/2013 03:32 PM, Roberto Fichera wrote:
On 08/13/2013 03:25 PM, Daniel-Constantin Mierla
wrote:
I can confirm that the default cfg for TCP client doesn't work for me. My cfg file is
attached.
The TCP client doesn't receive any package at INVITE. Finally in /var/log/message I
get this log below:
Aug 13 14:05:37 proxy /usr/sbin/kamailio[8401]: ERROR: <core> [tcp_main.c:4247]:
handle_tcpconn_ev(): connect
94.94.X.X:1274 failed
Contact::
<sip:528@94.94.X.X:1274;transport=TCP;ob>;q=;expires=38;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=61;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.X.X:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>
user_agent=<DICE 1.8.20.1>;reg-id=0
[root@proxy ~]# ngrep -W byline -d eth0 port 5060
interface: eth0 (178.79.X.X/255.255.255.0)
filter: (ip or ip6) and ( port 5060 )
#
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9167.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
....
##
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV",
uri="sip:test.domain;transport=tcp;hide",
response="ac1c7311ccb887fc8fb494d8ebf1bd36".
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.5440.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>;expires=300.
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
##
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
------------------ This is the client behind NAT ---------------------------
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Content-Length: 0
--end msg--
15:54:02.580 pjsua_acc.c .Acc 0: Registration sent
Can you get a ngrep trace for a registration as
well (for the phone using tcp)?
Ok! I'll use pjsua from my local machine
connecting in the same way as the
TCP client was doing. The TCP client it's an iPhone using the same pjlib library.
>> 15:54:02.681 tcpc0x1515a08 !TCP transport
192.168.2.90:49519 is connected to 178.79.x.x:5060
15:54:02.681 pjsua_app.c SIP
TCP transport is connected to [178.79.x.x:5060]
15:54:02.785 pjsua_core.c .RX 538 bytes Response msg 401/REGISTER/cseq=30028
(rdata0x1515cf8) from TCP 178.79.x.x:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9663
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF"
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.785 pjsua_core.c ....TX 849 bytes Request msg REGISTER/cseq=30029
(tdta0x1513000) to TCP 178.79.x.x:5060:
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF",
uri="sip:test.domain;transport=tcp;hide",
response="c3dd687602ec35b2403b3eb142b496f5"
Content-Length: 0
--end msg--
15:54:02.890 pjsua_core.c .RX 495 bytes Response msg 200/REGISTER/cseq=30029
(rdata0x1515cf8) from TCP 178.79.x.x:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.189b
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.890 pjsua_acc.c ....SIP outbound status for acc 0 is not active
15:54:02.890 pjsua_acc.c ....sip:528@test.domain;transport=tcp;hide: registration
success, status=200 (OK), will
re-register in 300 seconds
---------------------------------------------------
Daniel
On 8/13/13 3:23 PM, Roberto Fichera wrote:
> On 08/13/2013 03:15 PM, Roberto Fichera wrote:
>> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> you should grab the ngrep for such call to understand better what
happens. Also, dumping the location records
>>>>> will be
>>>>> useful (kamctl ul show).
>>>>>
>>>>> Also, be sure that tcp connection lifetime is long enough to survive
re-registration. To avoid trying to open
>>>>> connections behind nat, use set_forward_no_connect() for calls
involving nat traversal.
>>>> I'm using the default conf coming from fedora rpm. So, mainly the
problem seems related to kamailio
>>>> which doesn't reuse the TCP port used by NATed clients. I've also
notice that the received
>>>> field isn't set at all, so this means that the contact will not get
aliased at all.
>>>>
>>>> I would really like to have a look to a working cfg file for TCP NATed
clients that reuse the TCP port.
>>>> Even better if the configuration is based on the fedora default rpm.
>>> if received is not set, then means the register was not detected as coming
from behind nat. Is the phone using stun?
>> I'm testing with a normal rtpproxy configuration. BTW udp -> udp work
perfectly.
>>
>>> Again, put here the ngrep for registration and a call to see if something is
wrong with signaling. There is no help
>>> that we can provide otherwise. The default config works fine for tcp and
natted clients, I use it everywhere for this
>>> case without issues.
>> I tried the default cfg enabling both NAT and RTPproxy, but seems that kamailio
doesn't reuse TCP ports.
>> Anyway, this is a call from UDP (512) -> TCP (526) both behind the same NAT,
from kamailio point of view
> I forgot to say that the received field is now present because I've changed the
> route[NATDETECT] in the default configuration as
>
> route[NATDETECT] {
> #!ifdef WITH_NAT
> force_rport();
>
> -->>> if (nat_uac_test("19") || proto != UDP) {
> if (is_method("REGISTER")) {
> fix_nated_register();
> } else {
> fix_nated_contact();
> }
> setflag(FLT_NATS);
> }
> #!endif
> return;
> }
>
>
>> [root@proxy ~]# kamctl ul show 526
>> Contact::
>>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>>
>> Smartphone 1.0/iPhone>;reg-id=0
>> [root@proxy ~]# kamctl ul show 512
>> Contact::
>>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>>
>> 1.8.20.1>;reg-id=0
>> [root@proxy ~]#
>>
>>
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:526@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 264.
>> .
>> v=0.
>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 10782 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:526@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 264.
>> .
>> v=0.
>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 10782 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:526@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:526@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>> Max-Forwards: 16.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:1025>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>> Max-Forwards: 16.
>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>> To: <sip:526@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:1025>.
>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>>
>>> Cheers,
>>> Daniel
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Sorry for cross-posting this email to PJLIB, but maybe there are
some things related.
>>>>>> Anyhow! I'm having problems on kamailio v4.0.2 under Fedora
18 64bit and TCP client like iPhone using PJSIP as SIP
>>>>>> library.
>>>>>> Basically once the iPhone side in close the call (TCP->UDP)
I'm getting the error below. Kamailio is running under
>>>>>> a VPS
>>>>>> without
>>>>>> NATed network so it uses a real public address. Furthermore, note
that tcp_main is answering to a 192.168.2.98 ip
>>>>>> address
>>>>>> which is the iPhone client. This looks really strange to me since
it should answer directly to the public/port used
>>>>>> for
>>>>>> the registration
>>>>>> and not to a such kind of reserved address. The kamilio
configuration is basically the default with a very few
>>>>>> changes
>>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>>
>>>>>> This problems doesn't happen at all when using UDP->UDP
calls. But I cannot use it because as you certain know UDP
>>>>>> connection under iPhone will not work when the application run in
background mode.
>>>>>>
>>>>>> Can someone suggest how to solve this issue or maybe suggest a
TCP working solution for iPhone?
>>>>>>
>>>>>> Thanks in advance.
>>>>>> Roberto Fichera.
>>>>>>
>>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command: received
command "9483_9 D
>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060 as74e0c388
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete:
forcefully deleting session 1 on ports 15604/17354
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTP
stats: 354 in from callee, 603 in from caller, 957
>>>>>> relayed, 0 dropped
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session: RTCP
stats: 5 in from callee, 2 in from caller, 7
>>>>>> relayed, 0
>>>>>> dropped
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:remove_session:
session on ports 15604/17354 is cleaned up
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9483_9 0
>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command: received
command "9496_16 D
>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: INFO:handle_command: delete
request failed: session
>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply: sending reply
"9496_16 E8
>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>>> sr-users(a)lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
14 Aug
14 Aug
10:19 a.m.
Hello,
as you can see in the REGISTER, the phone give a public IP where it can
be contacted and kamailio tries to deliver to that address
sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
You should disable stun in the client and let the server care of nat
traversal.
Or you can try to add flag 128 to nat test:
- http://kamailio.org/docs/modules/stable/modules/nathelper.html#idp15376536
Also, you can try to add an alias for contact port:
- http://www.kamailio.org/wiki/cookbooks/4.0.x/core#force_tcp_alias
Cheers,
Daniel
On 8/13/13 4:17 PM, Roberto Fichera wrote:
On 08/13/2013 03:32 PM, Roberto Fichera wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 08/13/2013 03:25 PM, Daniel-Constantin Mierla
wrote:
I can confirm that the default cfg for TCP client doesn't work for me. My cfg
file is attached.
The TCP client doesn't receive any package at INVITE. Finally in /var/log/message I
get this log below:
Aug 13 14:05:37 proxy /usr/sbin/kamailio[8401]: ERROR: <core> [tcp_main.c:4247]:
handle_tcpconn_ev(): connect
94.94.X.X:1274 failed
Contact::
<sip:528@94.94.X.X:1274;transport=TCP;ob>;q=;expires=38;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=61;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.X.X:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>
user_agent=<DICE 1.8.20.1>;reg-id=0
[root@proxy ~]# ngrep -W byline -d eth0 port 5060
interface: eth0 (178.79.X.X/255.255.255.0)
filter: (ip or ip6) and ( port 5060 )
#
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9167.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
....
##
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV",
uri="sip:test.domain;transport=tcp;hide",
response="ac1c7311ccb887fc8fb494d8ebf1bd36".
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.5440.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>;expires=300.
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
##
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
------------------ This is the client behind NAT ---------------------------
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Content-Length: 0
--end msg--
15:54:02.580 pjsua_acc.c .Acc 0: Registration sent
Can you get a ngrep trace for a registration as
well (for the phone using tcp)?
Ok! I'll use pjsua from my local machine
connecting in the same way as the
TCP client was doing. The TCP client it's an iPhone using the same pjlib library.
>> 15:54:02.681 tcpc0x1515a08 !TCP
transport 192.168.2.90:49519 is connected to 178.79.x.x:5060
15:54:02.681
pjsua_app.c SIP TCP transport is connected to [178.79.x.x:5060]
15:54:02.785 pjsua_core.c .RX 538 bytes Response msg 401/REGISTER/cseq=30028
(rdata0x1515cf8) from TCP 178.79.x.x:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9663
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF"
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.785 pjsua_core.c ....TX 849 bytes Request msg REGISTER/cseq=30029
(tdta0x1513000) to TCP 178.79.x.x:5060:
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF",
uri="sip:test.domain;transport=tcp;hide",
response="c3dd687602ec35b2403b3eb142b496f5"
Content-Length: 0
--end msg--
15:54:02.890 pjsua_core.c .RX 495 bytes Response msg 200/REGISTER/cseq=30029
(rdata0x1515cf8) from TCP 178.79.x.x:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.189b
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.890 pjsua_acc.c ....SIP outbound status for acc 0 is not active
15:54:02.890 pjsua_acc.c ....sip:528@test.domain;transport=tcp;hide: registration
success, status=200 (OK), will
re-register in 300 seconds
---------------------------------------------------
>> Daniel
>>
>> On 8/13/13 3:23 PM, Roberto Fichera wrote:
>>> On 08/13/2013 03:15 PM, Roberto Fichera wrote:
>>>> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>>>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> you should grab the ngrep for such call to understand better
what happens. Also, dumping the location records
>>>>>>> will be
>>>>>>> useful (kamctl ul show).
>>>>>>>
>>>>>>> Also, be sure that tcp connection lifetime is long enough to
survive re-registration. To avoid trying to open
>>>>>>> connections behind nat, use set_forward_no_connect() for
calls involving nat traversal.
>>>>>> I'm using the default conf coming from fedora rpm. So, mainly
the problem seems related to kamailio
>>>>>> which doesn't reuse the TCP port used by NATed clients.
I've also notice that the received
>>>>>> field isn't set at all, so this means that the contact will
not get aliased at all.
>>>>>>
>>>>>> I would really like to have a look to a working cfg file for TCP
NATed clients that reuse the TCP port.
>>>>>> Even better if the configuration is based on the fedora default
rpm.
>>>>> if received is not set, then means the register was not detected as
coming from behind nat. Is the phone using stun?
>>>> I'm testing with a normal rtpproxy configuration. BTW udp -> udp
work perfectly.
>>>>
>>>>> Again, put here the ngrep for registration and a call to see if
something is wrong with signaling. There is no help
>>>>> that we can provide otherwise. The default config works fine for tcp
and natted clients, I use it everywhere for this
>>>>> case without issues.
>>>> I tried the default cfg enabling both NAT and RTPproxy, but seems that
kamailio doesn't reuse TCP ports.
>>>> Anyway, this is a call from UDP (512) -> TCP (526) both behind the
same NAT, from kamailio point of view
>>> I forgot to say that the received field is now present because I've
changed the
>>> route[NATDETECT] in the default configuration as
>>>
>>> route[NATDETECT] {
>>> #!ifdef WITH_NAT
>>> force_rport();
>>>
>>> -->>> if (nat_uac_test("19") || proto != UDP) {
>>> if (is_method("REGISTER")) {
>>> fix_nated_register();
>>> } else {
>>> fix_nated_contact();
>>> }
>>> setflag(FLT_NATS);
>>> }
>>> #!endif
>>> return;
>>> }
>>>
>>>
>>>> [root@proxy ~]# kamctl ul show 526
>>>> Contact::
>>>>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>>>>
>>>> Smartphone 1.0/iPhone>;reg-id=0
>>>> [root@proxy ~]# kamctl ul show 512
>>>> Contact::
>>>>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>>>>
>>>> 1.8.20.1>;reg-id=0
>>>> [root@proxy ~]#
>>>>
>>>>
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>>>> Supported: replaces, timer.
>>>> Content-Type: application/sdp.
>>>> Content-Length: 264.
>>>> .
>>>> v=0.
>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>> s=Asterisk PBX 11.3.0.
>>>> c=IN IP4 94.94.X.X.
>>>> t=0 0.
>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>> a=rtpmap:0 PCMU/8000.
>>>> a=rtpmap:110 speex/8000.
>>>> a=rtpmap:101 telephone-event/8000.
>>>> a=fmtp:101 0-16.
>>>> a=ptime:20.
>>>> a=sendrecv.
>>>>
>>>> #
>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>> SIP/2.0 407 Proxy Authentication Required.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>>>> Supported: replaces, timer.
>>>> Content-Type: application/sdp.
>>>> Content-Length: 264.
>>>> .
>>>> v=0.
>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>> s=Asterisk PBX 11.3.0.
>>>> c=IN IP4 94.94.X.X.
>>>> t=0 0.
>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>> a=rtpmap:0 PCMU/8000.
>>>> a=rtpmap:110 speex/8000.
>>>> a=rtpmap:101 telephone-event/8000.
>>>> a=fmtp:101 0-16.
>>>> a=ptime:20.
>>>> a=sendrecv.
>>>>
>>>> #
>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>> SIP/2.0 407 Proxy Authentication Required.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> Max-Forwards: 16.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> Max-Forwards: 16.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>> Cheers,
>>>>>> Roberto Fichera.
>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Sorry for cross-posting this email to PJLIB, but maybe
there are some things related.
>>>>>>>> Anyhow! I'm having problems on kamailio v4.0.2 under
Fedora 18 64bit and TCP client like iPhone using PJSIP as SIP
>>>>>>>> library.
>>>>>>>> Basically once the iPhone side in close the call
(TCP->UDP) I'm getting the error below. Kamailio is running under
>>>>>>>> a VPS
>>>>>>>> without
>>>>>>>> NATed network so it uses a real public address.
Furthermore, note that tcp_main is answering to a 192.168.2.98 ip
>>>>>>>> address
>>>>>>>> which is the iPhone client. This looks really strange to
me since it should answer directly to the public/port used
>>>>>>>> for
>>>>>>>> the registration
>>>>>>>> and not to a such kind of reserved address. The kamilio
configuration is basically the default with a very few
>>>>>>>> changes
>>>>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>>>>
>>>>>>>> This problems doesn't happen at all when using
UDP->UDP calls. But I cannot use it because as you certain know UDP
>>>>>>>> connection under iPhone will not work when the
application run in background mode.
>>>>>>>>
>>>>>>>> Can someone suggest how to solve this issue or maybe
suggest a TCP working solution for iPhone?
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command:
received command "9483_9 D
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
as74e0c388 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete:
forcefully deleting session 1 on ports 15604/17354
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTP stats: 354 in from callee, 603 in from caller, 957
>>>>>>>> relayed, 0 dropped
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTCP stats: 5 in from callee, 2 in from caller, 7
>>>>>>>> relayed, 0
>>>>>>>> dropped
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: session on ports 15604/17354 is cleaned up
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply:
sending reply "9483_9 0
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command:
received command "9496_16 D
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
INFO:handle_command: delete request failed: session
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply:
sending reply "9496_16 E8
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
>>>>>>>> sr-users(a)lists.sip-router.org
>>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
11:16 a.m.
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
as you can see in the REGISTER, the phone give a public IP where it can be contacted and
kamailio tries to deliver to
that address sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
Yep! That's the problem
You should disable stun in the client and let the
server care of nat traversal.
As already said all client doesn't use any stun-
Or you can try to add flag 128 to nat test:
- http://kamailio.org/docs/modules/stable/modules/nathelper.html#idp15376536
Also, you can try to add an alias for contact port:
- http://www.kamailio.org/wiki/cookbooks/4.0.x/core#force_tcp_alias
Ok! I'll try both!
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 8/13/13 4:17 PM, Roberto Fichera wrote:
On 08/13/2013 03:32 PM, Roberto Fichera wrote:
On 08/13/2013 03:25 PM, Daniel-Constantin Mierla
wrote:
I can confirm that the default cfg for TCP client doesn't work for me. My cfg
file is attached.
The TCP client doesn't receive any package at INVITE. Finally in /var/log/message I
get this log below:
Aug 13 14:05:37 proxy /usr/sbin/kamailio[8401]: ERROR: <core> [tcp_main.c:4247]:
handle_tcpconn_ev(): connect
94.94.X.X:1274 failed
Contact::
<sip:528@94.94.X.X:1274;transport=TCP;ob>;q=;expires=38;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
[root@proxy ~]# kamctl ul show 512
Contact::
<sip:512@94.94.X.X:5060>;q=;expires=61;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.X.X:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>
user_agent=<DICE 1.8.20.1>;reg-id=0
[root@proxy ~]# ngrep -W byline -d eth0 port 5060
interface: eth0 (178.79.X.X/255.255.255.0)
filter: (ip or ip6) and ( port 5060 )
#
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9167.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30034 REGISTER.
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
....
##
T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
Max-Forwards: 70.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV",
uri="sip:test.domain;transport=tcp;hide",
response="ac1c7311ccb887fc8fb494d8ebf1bd36".
Content-Length: 0.
.
#
T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.5440.
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
CSeq: 30035 REGISTER.
Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>;expires=300.
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
##
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
INVITE sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
User-Agent: DICE 1.8.20.1.
Date: Tue, 13 Aug 2013 14:04:11 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 883039875 883039875 IN IP4 94.94.X.X.
s=Asterisk PBX 11.3.0.
c=IN IP4 94.94.X.X.
t=0 0.
m=audio 18120 RTP/AVP 0 110 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:110 speex/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
#
U 178.79.x.x:5060 -> 94.94.X.X:1025
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 INVITE.
Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
Server: kamailio (4.0.2 (x86_64/linux)).
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
#
U 94.94.X.X:1025 -> 178.79.x.x:5060
ACK sip:528@test.domain:5060 SIP/2.0.
Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
Max-Forwards: 70.
From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
To: <sip:528@test.domain:5060>.
Contact: <sip:512@94.94.X.X:5060>.
Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
CSeq: 102 ACK.
User-Agent: DICE 1.8.20.1.
Content-Length: 0.
.
------------------ This is the client behind NAT ---------------------------
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Content-Length: 0
--end msg--
15:54:02.580 pjsua_acc.c .Acc 0: Registration sent
Can you get a ngrep trace for a registration as
well (for the phone using tcp)?
Ok! I'll use pjsua from my local machine
connecting in the same way as the
TCP client was doing. The TCP client it's an iPhone using the same pjlib library.
>> 15:54:02.681 tcpc0x1515a08 !TCP
transport 192.168.2.90:49519 is connected to 178.79.x.x:5060
15:54:02.681
pjsua_app.c SIP TCP transport is connected to [178.79.x.x:5060]
15:54:02.785 pjsua_core.c .RX 538 bytes Response msg 401/REGISTER/cseq=30028
(rdata0x1515cf8) from TCP
178.79.x.x:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9663
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30028 REGISTER
WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF"
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.785 pjsua_core.c ....TX 849 bytes Request msg REGISTER/cseq=30029
(tdta0x1513000) to TCP 178.79.x.x:5060:
REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
Max-Forwards: 70
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS
Authorization: Digest username="528", realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF",
uri="sip:test.domain;transport=tcp;hide",
response="c3dd687602ec35b2403b3eb142b496f5"
Content-Length: 0
--end msg--
15:54:02.890 pjsua_core.c .RX 495 bytes Response msg 200/REGISTER/cseq=30029
(rdata0x1515cf8) from TCP
178.79.x.x:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.189b
Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
CSeq: 30029 REGISTER
Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300
Server: kamailio (4.0.2 (x86_64/linux))
Content-Length: 0
--end msg--
15:54:02.890 pjsua_acc.c ....SIP outbound status for acc 0 is not active
15:54:02.890 pjsua_acc.c ....sip:528@test.domain;transport=tcp;hide: registration
success, status=200 (OK), will
re-register in 300 seconds
---------------------------------------------------
>> Daniel
>>
>> On 8/13/13 3:23 PM, Roberto Fichera wrote:
>>> On 08/13/2013 03:15 PM, Roberto Fichera wrote:
>>>> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>>>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> you should grab the ngrep for such call to understand better
what happens. Also, dumping the location records
>>>>>>> will be
>>>>>>> useful (kamctl ul show).
>>>>>>>
>>>>>>> Also, be sure that tcp connection lifetime is long enough to
survive re-registration. To avoid trying to open
>>>>>>> connections behind nat, use set_forward_no_connect() for
calls involving nat traversal.
>>>>>> I'm using the default conf coming from fedora rpm. So, mainly
the problem seems related to kamailio
>>>>>> which doesn't reuse the TCP port used by NATed clients.
I've also notice that the received
>>>>>> field isn't set at all, so this means that the contact will
not get aliased at all.
>>>>>>
>>>>>> I would really like to have a look to a working cfg file for TCP
NATed clients that reuse the TCP port.
>>>>>> Even better if the configuration is based on the fedora default
rpm.
>>>>> if received is not set, then means the register was not detected as
coming from behind nat. Is the phone using
>>>>> stun?
>>>> I'm testing with a normal rtpproxy configuration. BTW udp -> udp
work perfectly.
>>>>
>>>>> Again, put here the ngrep for registration and a call to see if
something is wrong with signaling. There is no help
>>>>> that we can provide otherwise. The default config works fine for tcp
and natted clients, I use it everywhere for
>>>>> this
>>>>> case without issues.
>>>> I tried the default cfg enabling both NAT and RTPproxy, but seems that
kamailio doesn't reuse TCP ports.
>>>> Anyway, this is a call from UDP (512) -> TCP (526) both behind the
same NAT, from kamailio point of view
>>> I forgot to say that the received field is now present because I've
changed the
>>> route[NATDETECT] in the default configuration as
>>>
>>> route[NATDETECT] {
>>> #!ifdef WITH_NAT
>>> force_rport();
>>>
>>> -->>> if (nat_uac_test("19") || proto != UDP) {
>>> if (is_method("REGISTER")) {
>>> fix_nated_register();
>>> } else {
>>> fix_nated_contact();
>>> }
>>> setflag(FLT_NATS);
>>> }
>>> #!endif
>>> return;
>>> }
>>>
>>>
>>>> [root@proxy ~]# kamctl ul show 526
>>>> Contact::
>>>>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>>>>
>>>>
>>>> Smartphone 1.0/iPhone>;reg-id=0
>>>> [root@proxy ~]# kamctl ul show 512
>>>> Contact::
>>>>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>>>>
>>>>
>>>> 1.8.20.1>;reg-id=0
>>>> [root@proxy ~]#
>>>>
>>>>
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>>>> Supported: replaces, timer.
>>>> Content-Type: application/sdp.
>>>> Content-Length: 264.
>>>> .
>>>> v=0.
>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>> s=Asterisk PBX 11.3.0.
>>>> c=IN IP4 94.94.X.X.
>>>> t=0 0.
>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>> a=rtpmap:0 PCMU/8000.
>>>> a=rtpmap:110 speex/8000.
>>>> a=rtpmap:101 telephone-event/8000.
>>>> a=fmtp:101 0-16.
>>>> a=ptime:20.
>>>> a=sendrecv.
>>>>
>>>> #
>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>> SIP/2.0 407 Proxy Authentication Required.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>>>> Supported: replaces, timer.
>>>> Content-Type: application/sdp.
>>>> Content-Length: 264.
>>>> .
>>>> v=0.
>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>> s=Asterisk PBX 11.3.0.
>>>> c=IN IP4 94.94.X.X.
>>>> t=0 0.
>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>> a=rtpmap:0 PCMU/8000.
>>>> a=rtpmap:110 speex/8000.
>>>> a=rtpmap:101 telephone-event/8000.
>>>> a=fmtp:101 0-16.
>>>> a=ptime:20.
>>>> a=sendrecv.
>>>>
>>>> #
>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>> SIP/2.0 407 Proxy Authentication Required.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 INVITE.
>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>> Max-Forwards: 70.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> Max-Forwards: 16.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> #
>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>> Max-Forwards: 16.
>>>> From: "asterisk" <sip:512@test.domain>;tag=as76007db0.
>>>> To: <sip:526@test.domain:5060>.
>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>> CSeq: 102 ACK.
>>>> User-Agent: DICE 1.8.20.1.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>> Cheers,
>>>>>> Roberto Fichera.
>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Sorry for cross-posting this email to PJLIB, but maybe
there are some things related.
>>>>>>>> Anyhow! I'm having problems on kamailio v4.0.2 under
Fedora 18 64bit and TCP client like iPhone using PJSIP
>>>>>>>> as SIP
>>>>>>>> library.
>>>>>>>> Basically once the iPhone side in close the call
(TCP->UDP) I'm getting the error below. Kamailio is running
>>>>>>>> under
>>>>>>>> a VPS
>>>>>>>> without
>>>>>>>> NATed network so it uses a real public address.
Furthermore, note that tcp_main is answering to a
>>>>>>>> 192.168.2.98 ip
>>>>>>>> address
>>>>>>>> which is the iPhone client. This looks really strange to
me since it should answer directly to the
>>>>>>>> public/port used
>>>>>>>> for
>>>>>>>> the registration
>>>>>>>> and not to a such kind of reserved address. The kamilio
configuration is basically the default with a very few
>>>>>>>> changes
>>>>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>>>>
>>>>>>>> This problems doesn't happen at all when using
UDP->UDP calls. But I cannot use it because as you certain
>>>>>>>> know UDP
>>>>>>>> connection under iPhone will not work when the
application run in background mode.
>>>>>>>>
>>>>>>>> Can someone suggest how to solve this issue or maybe
suggest a TCP working solution for iPhone?
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:get_command:
received command "9483_9 D
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
as74e0c388 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: INFO:handle_delete:
forcefully deleting session 1 on ports 15604/17354
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTP stats: 354 in from callee, 603 in from caller,
>>>>>>>> 957
>>>>>>>> relayed, 0 dropped
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTCP stats: 5 in from callee, 2 in from caller, 7
>>>>>>>> relayed, 0
>>>>>>>> dropped
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: session on ports 15604/17354 is cleaned up
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: DBUG:doreply:
sending reply "9483_9 0
>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]: ERROR:
<core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:get_command:
received command "9496_16 D
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
INFO:handle_command: delete request failed: session
>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060, tags
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: DBUG:doreply:
sending reply "9496_16 E8
>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
>>>>>>>> sr-users(a)lists.sip-router.org
>>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
11:20 a.m.
Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla
wrote:
Hi,
then how they discover the public IP address if they are behind NAT? Or
did I misunderstand that they are behind NAT?
If they are on the public IP, they they should listen on the port
advertised in the Contact header of registration and accept the
connection from Kamailio.
Cheers,
Daniel
Hello,
as you can see in the REGISTER, the phone give a public IP where it can be contacted and
kamailio tries to deliver to
that address sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
Yep! That's the
problem
You should disable stun in the client and let the
server care of nat traversal.
As already said all client doesn't use any stun-
Or you can try to add flag 128 to nat test:
- http://kamailio.org/docs/modules/stable/modules/nathelper.html#idp15376536
Also, you can try to add an alias for contact port:
- http://www.kamailio.org/wiki/cookbooks/4.0.x/core#force_tcp_alias
Ok! I'll
try both!
Cheers,
Roberto Fichera.
> Cheers,
> Daniel
>
> On 8/13/13 4:17 PM, Roberto Fichera wrote:
>> On 08/13/2013 03:32 PM, Roberto Fichera wrote:
>>> On 08/13/2013 03:25 PM, Daniel-Constantin Mierla wrote:
>>>> Can you get a ngrep trace for a registration as well (for the phone using
tcp)?
>>> Ok! I'll use pjsua from my local machine connecting in the same way as
the
>>> TCP client was doing. The TCP client it's an iPhone using the same pjlib
library.
>> I can confirm that the default cfg for TCP client doesn't work for me. My cfg
file is attached.
>> The TCP client doesn't receive any package at INVITE. Finally in
/var/log/message I get this log below:
>>
>> Aug 13 14:05:37 proxy /usr/sbin/kamailio[8401]: ERROR: <core>
[tcp_main.c:4247]: handle_tcpconn_ev(): connect
>> 94.94.X.X:1274 failed
>>
>> Contact::
>>
<sip:528@94.94.X.X:1274;transport=TCP;ob>;q=;expires=38;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;user_agent=<PJSUA
>>
>> v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
>> [root@proxy ~]# kamctl ul show 512
>> Contact::
>>
<sip:512@94.94.X.X:5060>;q=;expires=61;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.X.X:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>
>>
>> user_agent=<DICE 1.8.20.1>;reg-id=0
>>
>> [root@proxy ~]# ngrep -W byline -d eth0 port 5060
>> interface: eth0 (178.79.X.X/255.255.255.0)
>> filter: (ip or ip6) and ( port 5060 )
>> #
>> T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
>> Max-Forwards: 70.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30034 REGISTER.
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
>> Expires: 300.
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS.
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9167.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30034 REGISTER.
>> WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> ....
>> ##
>> T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
>> Max-Forwards: 70.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30035 REGISTER.
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
>> Expires: 300.
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS.
>> Authorization: Digest username="528", realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV",
>> uri="sip:test.domain;transport=tcp;hide",
response="ac1c7311ccb887fc8fb494d8ebf1bd36".
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
>> SIP/2.0 200 OK.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.5440.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30035 REGISTER.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>;expires=300.
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> ##
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 14:04:11 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 262.
>> .
>> v=0.
>> o=root 883039875 883039875 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 18120 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 14:04:11 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 262.
>> .
>> v=0.
>> o=root 883039875 883039875 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 18120 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> ------------------ This is the client behind NAT ---------------------------
>>
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
>> Max-Forwards: 70
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30028 REGISTER
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
>> Expires: 300
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.580 pjsua_acc.c .Acc 0: Registration sent
>>>>> 15:54:02.681 tcpc0x1515a08 !TCP transport 192.168.2.90:49519 is
connected to 178.79.x.x:5060
>> 15:54:02.681 pjsua_app.c SIP TCP transport is connected to [178.79.x.x:5060]
>> 15:54:02.785 pjsua_core.c .RX 538 bytes Response msg 401/REGISTER/cseq=30028
(rdata0x1515cf8) from TCP
>> 178.79.x.x:5060:
>> SIP/2.0 401 Unauthorized
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9663
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30028 REGISTER
>> WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF"
>> Server: kamailio (4.0.2 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.785 pjsua_core.c ....TX 849 bytes Request msg REGISTER/cseq=30029
(tdta0x1513000) to TCP 178.79.x.x:5060:
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
>> Max-Forwards: 70
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30029 REGISTER
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
>> Expires: 300
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
>> Authorization: Digest username="528", realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF",
>> uri="sip:test.domain;transport=tcp;hide",
response="c3dd687602ec35b2403b3eb142b496f5"
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.890 pjsua_core.c .RX 495 bytes Response msg 200/REGISTER/cseq=30029
(rdata0x1515cf8) from TCP
>> 178.79.x.x:5060:
>> SIP/2.0 200 OK
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.189b
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30029 REGISTER
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300
>> Server: kamailio (4.0.2 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.890 pjsua_acc.c ....SIP outbound status for acc 0 is not active
>> 15:54:02.890 pjsua_acc.c ....sip:528@test.domain;transport=tcp;hide:
registration success, status=200 (OK), will
>> re-register in 300 seconds
>>
>>
>> ---------------------------------------------------
>>
>>
>>
>>>> Daniel
>>>>
>>>> On 8/13/13 3:23 PM, Roberto Fichera wrote:
>>>>> On 08/13/2013 03:15 PM, Roberto Fichera wrote:
>>>>>> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>>>>>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> you should grab the ngrep for such call to understand
better what happens. Also, dumping the location records
>>>>>>>>> will be
>>>>>>>>> useful (kamctl ul show).
>>>>>>>>>
>>>>>>>>> Also, be sure that tcp connection lifetime is long
enough to survive re-registration. To avoid trying to open
>>>>>>>>> connections behind nat, use set_forward_no_connect()
for calls involving nat traversal.
>>>>>>>> I'm using the default conf coming from fedora rpm.
So, mainly the problem seems related to kamailio
>>>>>>>> which doesn't reuse the TCP port used by NATed
clients. I've also notice that the received
>>>>>>>> field isn't set at all, so this means that the
contact will not get aliased at all.
>>>>>>>>
>>>>>>>> I would really like to have a look to a working cfg file
for TCP NATed clients that reuse the TCP port.
>>>>>>>> Even better if the configuration is based on the fedora
default rpm.
>>>>>>> if received is not set, then means the register was not
detected as coming from behind nat. Is the phone using
>>>>>>> stun?
>>>>>> I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
>>>>>>
>>>>>>> Again, put here the ngrep for registration and a call to see
if something is wrong with signaling. There is no help
>>>>>>> that we can provide otherwise. The default config works fine
for tcp and natted clients, I use it everywhere for
>>>>>>> this
>>>>>>> case without issues.
>>>>>> I tried the default cfg enabling both NAT and RTPproxy, but seems
that kamailio doesn't reuse TCP ports.
>>>>>> Anyway, this is a call from UDP (512) -> TCP (526) both behind
the same NAT, from kamailio point of view
>>>>> I forgot to say that the received field is now present because
I've changed the
>>>>> route[NATDETECT] in the default configuration as
>>>>>
>>>>> route[NATDETECT] {
>>>>> #!ifdef WITH_NAT
>>>>> force_rport();
>>>>>
>>>>> -->>> if (nat_uac_test("19") || proto !=
UDP) {
>>>>> if (is_method("REGISTER")) {
>>>>> fix_nated_register();
>>>>> } else {
>>>>> fix_nated_contact();
>>>>> }
>>>>> setflag(FLT_NATS);
>>>>> }
>>>>> #!endif
>>>>> return;
>>>>> }
>>>>>
>>>>>
>>>>>> [root@proxy ~]# kamctl ul show 526
>>>>>> Contact::
>>>>>>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>>>>>>
>>>>>>
>>>>>> Smartphone 1.0/iPhone>;reg-id=0
>>>>>> [root@proxy ~]# kamctl ul show 512
>>>>>> Contact::
>>>>>>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>>>>>>
>>>>>>
>>>>>> 1.8.20.1>;reg-id=0
>>>>>> [root@proxy ~]#
>>>>>>
>>>>>>
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH.
>>>>>> Supported: replaces, timer.
>>>>>> Content-Type: application/sdp.
>>>>>> Content-Length: 264.
>>>>>> .
>>>>>> v=0.
>>>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>>>> s=Asterisk PBX 11.3.0.
>>>>>> c=IN IP4 94.94.X.X.
>>>>>> t=0 0.
>>>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>>>> a=rtpmap:0 PCMU/8000.
>>>>>> a=rtpmap:110 speex/8000.
>>>>>> a=rtpmap:101 telephone-event/8000.
>>>>>> a=fmtp:101 0-16.
>>>>>> a=ptime:20.
>>>>>> a=sendrecv.
>>>>>>
>>>>>> #
>>>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>>>> SIP/2.0 407 Proxy Authentication Required.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH.
>>>>>> Supported: replaces, timer.
>>>>>> Content-Type: application/sdp.
>>>>>> Content-Length: 264.
>>>>>> .
>>>>>> v=0.
>>>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>>>> s=Asterisk PBX 11.3.0.
>>>>>> c=IN IP4 94.94.X.X.
>>>>>> t=0 0.
>>>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>>>> a=rtpmap:0 PCMU/8000.
>>>>>> a=rtpmap:110 speex/8000.
>>>>>> a=rtpmap:101 telephone-event/8000.
>>>>>> a=fmtp:101 0-16.
>>>>>> a=ptime:20.
>>>>>> a=sendrecv.
>>>>>>
>>>>>> #
>>>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>>>> SIP/2.0 407 Proxy Authentication Required.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> Max-Forwards: 16.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> Max-Forwards: 16.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Sorry for cross-posting this email to PJLIB, but
maybe there are some things related.
>>>>>>>>>> Anyhow! I'm having problems on kamailio
v4.0.2 under Fedora 18 64bit and TCP client like iPhone using PJSIP
>>>>>>>>>> as SIP
>>>>>>>>>> library.
>>>>>>>>>> Basically once the iPhone side in close the call
(TCP->UDP) I'm getting the error below. Kamailio is running
>>>>>>>>>> under
>>>>>>>>>> a VPS
>>>>>>>>>> without
>>>>>>>>>> NATed network so it uses a real public address.
Furthermore, note that tcp_main is answering to a
>>>>>>>>>> 192.168.2.98 ip
>>>>>>>>>> address
>>>>>>>>>> which is the iPhone client. This looks really
strange to me since it should answer directly to the
>>>>>>>>>> public/port used
>>>>>>>>>> for
>>>>>>>>>> the registration
>>>>>>>>>> and not to a such kind of reserved address. The
kamilio configuration is basically the default with a very few
>>>>>>>>>> changes
>>>>>>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>>>>>>
>>>>>>>>>> This problems doesn't happen at all when
using UDP->UDP calls. But I cannot use it because as you certain
>>>>>>>>>> know UDP
>>>>>>>>>> connection under iPhone will not work when the
application run in background mode.
>>>>>>>>>>
>>>>>>>>>> Can someone suggest how to solve this issue or
maybe suggest a TCP working solution for iPhone?
>>>>>>>>>>
>>>>>>>>>> Thanks in advance.
>>>>>>>>>> Roberto Fichera.
>>>>>>>>>>
>>>>>>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]:
ERROR: <core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
DBUG:get_command: received command "9483_9 D
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
as74e0c388 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:handle_delete: forcefully deleting session 1 on ports 15604/17354
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTP stats: 354 in from callee, 603 in from caller,
>>>>>>>>>> 957
>>>>>>>>>> relayed, 0 dropped
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTCP stats: 5 in from callee, 2 in from caller, 7
>>>>>>>>>> relayed, 0
>>>>>>>>>> dropped
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: session on ports 15604/17354 is cleaned up
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
DBUG:doreply: sending reply "9483_9 0
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>>>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]:
ERROR: <core> [tcp_main.c:4432]: tcpconn_main_timeout(): connect
>>>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
DBUG:get_command: received command "9496_16 D
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
INFO:handle_command: delete request failed: session
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060,
tags GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
DBUG:doreply: sending reply "9496_16 E8
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
>>>>>>>>>> sr-users(a)lists.sip-router.org
>>>>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>>> sr-users(a)lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
11:26 a.m.
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
Yes! They are behind NAT! Shouldn't kamailio detect such behaviour so it will change
the contact header and the other
fields accordingly using the nat_fix_XXXX functions?
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla
wrote:
Hi,
then how they discover the public IP address if they are behind NAT? Or did I
misunderstand that they are behind NAT? Hello,
as you can see in the REGISTER, the phone give a public IP where it can be contacted and
kamailio tries to deliver to
that address sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
Yep! That's the
problem
You should disable stun in the client and let the
server care of nat traversal.
As already said all client doesn't use any stun-
If they are on the public IP, they they should listen
on the port advertised in the Contact header of registration and
accept the connection from Kamailio.
Cheers,
Daniel
Or you can try to add flag 128 to nat test:
- http://kamailio.org/docs/modules/stable/modules/nathelper.html#idp15376536
Also, you can try to add an alias for contact port:
- http://www.kamailio.org/wiki/cookbooks/4.0.x/core#force_tcp_alias
Ok! I'll
try both!
Cheers,
Roberto Fichera.
> Cheers,
> Daniel
>
> On 8/13/13 4:17 PM, Roberto Fichera wrote:
>> On 08/13/2013 03:32 PM, Roberto Fichera wrote:
>>> On 08/13/2013 03:25 PM, Daniel-Constantin Mierla wrote:
>>>> Can you get a ngrep trace for a registration as well (for the phone using
tcp)?
>>> Ok! I'll use pjsua from my local machine connecting in the same way as
the
>>> TCP client was doing. The TCP client it's an iPhone using the same pjlib
library.
>> I can confirm that the default cfg for TCP client doesn't work for me. My cfg
file is attached.
>> The TCP client doesn't receive any package at INVITE. Finally in
/var/log/message I get this log below:
>>
>> Aug 13 14:05:37 proxy /usr/sbin/kamailio[8401]: ERROR: <core>
[tcp_main.c:4247]: handle_tcpconn_ev(): connect
>> 94.94.X.X:1274 failed
>>
>> Contact::
>>
<sip:528@94.94.X.X:1274;transport=TCP;ob>;q=;expires=38;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;user_agent=<PJSUA
>>
>>
>> v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
>> [root@proxy ~]# kamctl ul show 512
>> Contact::
>>
<sip:512@94.94.X.X:5060>;q=;expires=61;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.X.X:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>
>>
>>
>> user_agent=<DICE 1.8.20.1>;reg-id=0
>>
>> [root@proxy ~]# ngrep -W byline -d eth0 port 5060
>> interface: eth0 (178.79.X.X/255.255.255.0)
>> filter: (ip or ip6) and ( port 5060 )
>> #
>> T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
>> Max-Forwards: 70.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30034 REGISTER.
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
>> Expires: 300.
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS.
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPje03c11fd-d742-4502-98d8-69ca456ddd56;alias.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9167.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30034 REGISTER.
>> WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> ....
>> ##
>> T 94.94.X.X:49519 -> 178.79.x.x:5060 [AP]
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
>> Max-Forwards: 70.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30035 REGISTER.
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>.
>> Expires: 300.
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS.
>> Authorization: Digest username="528", realm="test.domain",
nonce="Ugo+VFIKPSgVy8fh9fSy9SDLvT0wO4QV",
>> uri="sip:test.domain;transport=tcp;hide",
response="ac1c7311ccb887fc8fb494d8ebf1bd36".
>> Content-Length: 0.
>> .
>>
>> #
>> T 178.79.x.x:5060 -> 94.94.X.X:49519 [AP]
>> SIP/2.0 200 OK.
>> Via: SIP/2.0/TCP
94.94.X.X:49519;rport=49519;branch=z9hG4bKPj68a9c487-ae8c-428a-8c50-dd195a46a6bf;alias.
>> From: <sip:528@test.domain;hide>;tag=64c9e9b9-cb23-4a79-bb0d-2497135e449b.
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.5440.
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1.
>> CSeq: 30035 REGISTER.
>> Contact: <sip:528@94.94.X.X:1274;transport=TCP;ob>;expires=300.
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> ##
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 14:04:11 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 262.
>> .
>> v=0.
>> o=root 883039875 883039875 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 18120 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> INVITE sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> User-Agent: DICE 1.8.20.1.
>> Date: Tue, 13 Aug 2013 14:04:11 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
>> Supported: replaces, timer.
>> Content-Type: application/sdp.
>> Content-Length: 262.
>> .
>> v=0.
>> o=root 883039875 883039875 IN IP4 94.94.X.X.
>> s=Asterisk PBX 11.3.0.
>> c=IN IP4 94.94.X.X.
>> t=0 0.
>> m=audio 18120 RTP/AVP 0 110 101.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:110 speex/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>> a=sendrecv.
>>
>> #
>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>> SIP/2.0 407 Proxy Authentication Required.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport=1025.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 INVITE.
>> Proxy-Authenticate: Digest realm="test.domain",
nonce="Ugo+XVIKPTFBd9tXC0QemfR9bHiZXO6x".
>> Server: kamailio (4.0.2 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.038f.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> #
>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>> ACK sip:528@test.domain:5060 SIP/2.0.
>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK69275d13;rport.
>> Max-Forwards: 70.
>> From: "asterisk" <sip:512@test.domain>;tag=as4531a4ee.
>> To: <sip:528@test.domain:5060>.
>> Contact: <sip:512@94.94.X.X:5060>.
>> Call-ID: 2ea7e0f3173949d40b69385b62b79d6a(a)test.domain.
>> CSeq: 102 ACK.
>> User-Agent: DICE 1.8.20.1.
>> Content-Length: 0.
>> .
>>
>> ------------------ This is the client behind NAT ---------------------------
>>
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
>> Max-Forwards: 70
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30028 REGISTER
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
>> Expires: 300
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.580 pjsua_acc.c .Acc 0: Registration sent
>>>>> 15:54:02.681 tcpc0x1515a08 !TCP transport 192.168.2.90:49519 is
connected to 178.79.x.x:5060
>> 15:54:02.681 pjsua_app.c SIP TCP transport is connected to [178.79.x.x:5060]
>> 15:54:02.785 pjsua_core.c .RX 538 bytes Response msg 401/REGISTER/cseq=30028
(rdata0x1515cf8) from TCP
>> 178.79.x.x:5060:
>> SIP/2.0 401 Unauthorized
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj92d04d45-bd84-45b3-9439-563ebfaebf00;alias
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.9663
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30028 REGISTER
>> WWW-Authenticate: Digest realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF"
>> Server: kamailio (4.0.2 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.785 pjsua_core.c ....TX 849 bytes Request msg REGISTER/cseq=30029
(tdta0x1513000) to TCP 178.79.x.x:5060:
>> REGISTER sip:test.domain;transport=tcp;hide SIP/2.0
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
>> Max-Forwards: 70
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30029 REGISTER
>> User-Agent: PJSUA v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>
>> Expires: 300
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
>> Authorization: Digest username="528", realm="test.domain",
nonce="Ugo7/FIKOtBneWAQzD/VoJuucFT3cNuF",
>> uri="sip:test.domain;transport=tcp;hide",
response="c3dd687602ec35b2403b3eb142b496f5"
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.890 pjsua_core.c .RX 495 bytes Response msg 200/REGISTER/cseq=30029
(rdata0x1515cf8) from TCP
>> 178.79.x.x:5060:
>> SIP/2.0 200 OK
>> Via: SIP/2.0/TCP
192.168.2.90:49519;rport=49519;branch=z9hG4bKPj03a4a7eb-d086-4add-b84c-ca5c6cf4d05d;alias
>> From: <sip:528@test.domain;hide>;tag=ab763476-0fdb-4d85-9064-1deabcaa23e4
>> To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.189b
>> Call-ID: 3ebadaeb-e6d6-42e3-9362-5ca4b5ddd8e1
>> CSeq: 30029 REGISTER
>> Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300
>> Server: kamailio (4.0.2 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> --end msg--
>> 15:54:02.890 pjsua_acc.c ....SIP outbound status for acc 0 is not active
>> 15:54:02.890 pjsua_acc.c ....sip:528@test.domain;transport=tcp;hide:
registration success, status=200 (OK), will
>> re-register in 300 seconds
>>
>>
>> ---------------------------------------------------
>>
>>
>>
>>>> Daniel
>>>>
>>>> On 8/13/13 3:23 PM, Roberto Fichera wrote:
>>>>> On 08/13/2013 03:15 PM, Roberto Fichera wrote:
>>>>>> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>>>>>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> you should grab the ngrep for such call to understand
better what happens. Also, dumping the location records
>>>>>>>>> will be
>>>>>>>>> useful (kamctl ul show).
>>>>>>>>>
>>>>>>>>> Also, be sure that tcp connection lifetime is long
enough to survive re-registration. To avoid trying to open
>>>>>>>>> connections behind nat, use set_forward_no_connect()
for calls involving nat traversal.
>>>>>>>> I'm using the default conf coming from fedora rpm.
So, mainly the problem seems related to kamailio
>>>>>>>> which doesn't reuse the TCP port used by NATed
clients. I've also notice that the received
>>>>>>>> field isn't set at all, so this means that the
contact will not get aliased at all.
>>>>>>>>
>>>>>>>> I would really like to have a look to a working cfg file
for TCP NATed clients that reuse the TCP port.
>>>>>>>> Even better if the configuration is based on the fedora
default rpm.
>>>>>>> if received is not set, then means the register was not
detected as coming from behind nat. Is the phone using
>>>>>>> stun?
>>>>>> I'm testing with a normal rtpproxy configuration. BTW udp
-> udp work perfectly.
>>>>>>
>>>>>>> Again, put here the ngrep for registration and a call to see
if something is wrong with signaling. There is no
>>>>>>> help
>>>>>>> that we can provide otherwise. The default config works fine
for tcp and natted clients, I use it everywhere for
>>>>>>> this
>>>>>>> case without issues.
>>>>>> I tried the default cfg enabling both NAT and RTPproxy, but seems
that kamailio doesn't reuse TCP ports.
>>>>>> Anyway, this is a call from UDP (512) -> TCP (526) both behind
the same NAT, from kamailio point of view
>>>>> I forgot to say that the received field is now present because
I've changed the
>>>>> route[NATDETECT] in the default configuration as
>>>>>
>>>>> route[NATDETECT] {
>>>>> #!ifdef WITH_NAT
>>>>> force_rport();
>>>>>
>>>>> -->>> if (nat_uac_test("19") || proto !=
UDP) {
>>>>> if (is_method("REGISTER")) {
>>>>> fix_nated_register();
>>>>> } else {
>>>>> fix_nated_contact();
>>>>> }
>>>>> setflag(FLT_NATS);
>>>>> }
>>>>> #!endif
>>>>> return;
>>>>> }
>>>>>
>>>>>
>>>>>> [root@proxy ~]# kamctl ul show 526
>>>>>> Contact::
>>>>>>
<sip:526@94.94.X.X:1238;transport=TCP;ob>;q=;expires=537;flags=0x0;cflags=0x40;state=0;socket=<tcp:178.79.x.x:5060>;methods=0x1FDF;received=<sip:94.94.X.X:61922;transport=TCP>;user_agent=<DICE
>>>>>>
>>>>>>
>>>>>>
>>>>>> Smartphone 1.0/iPhone>;reg-id=0
>>>>>> [root@proxy ~]# kamctl ul show 512
>>>>>> Contact::
>>>>>>
<sip:512@94.94.X.X:5060>;q=;expires=32;flags=0x0;cflags=0x40;state=0;socket=<udp:178.79.x.x:5060>;methods=0xFFFFFFFF;received=<sip:94.94.X.X:1025>;user_agent=<DICE
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1.8.20.1>;reg-id=0
>>>>>> [root@proxy ~]#
>>>>>>
>>>>>>
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH.
>>>>>> Supported: replaces, timer.
>>>>>> Content-Type: application/sdp.
>>>>>> Content-Length: 264.
>>>>>> .
>>>>>> v=0.
>>>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>>>> s=Asterisk PBX 11.3.0.
>>>>>> c=IN IP4 94.94.X.X.
>>>>>> t=0 0.
>>>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>>>> a=rtpmap:0 PCMU/8000.
>>>>>> a=rtpmap:110 speex/8000.
>>>>>> a=rtpmap:101 telephone-event/8000.
>>>>>> a=fmtp:101 0-16.
>>>>>> a=ptime:20.
>>>>>> a=sendrecv.
>>>>>>
>>>>>> #
>>>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>>>> SIP/2.0 407 Proxy Authentication Required.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> INVITE sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Date: Tue, 13 Aug 2013 13:04:30 GMT.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH.
>>>>>> Supported: replaces, timer.
>>>>>> Content-Type: application/sdp.
>>>>>> Content-Length: 264.
>>>>>> .
>>>>>> v=0.
>>>>>> o=root 1263161426 1263161426 IN IP4 94.94.X.X.
>>>>>> s=Asterisk PBX 11.3.0.
>>>>>> c=IN IP4 94.94.X.X.
>>>>>> t=0 0.
>>>>>> m=audio 10782 RTP/AVP 0 110 101.
>>>>>> a=rtpmap:0 PCMU/8000.
>>>>>> a=rtpmap:110 speex/8000.
>>>>>> a=rtpmap:101 telephone-event/8000.
>>>>>> a=fmtp:101 0-16.
>>>>>> a=ptime:20.
>>>>>> a=sendrecv.
>>>>>>
>>>>>> #
>>>>>> U 178.79.x.x:5060 -> 94.94.X.X:1025
>>>>>> SIP/2.0 407 Proxy Authentication Required.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 INVITE.
>>>>>> Proxy-Authenticate: Digest realm="test.domain",
nonce="UgowYFIKLzQXDSUWUpy4xlhdXZ7WNjPt".
>>>>>> Server: kamailio (4.0.2 (x86_64/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To:
<sip:526@test.domain:5060>;tag=333a0370df4a40d5d5a0c21bb156e2a6.4a00.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> U 94.94.X.X:1025 -> 178.79.x.x:5060
>>>>>> ACK sip:526@test.domain:5060 SIP/2.0.
>>>>>> Via: SIP/2.0/UDP 94.94.X.X:5060;branch=z9hG4bK4a420cee;rport.
>>>>>> Max-Forwards: 70.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:5060>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> Max-Forwards: 16.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> #
>>>>>> T 178.79.x.x:5060 -> 94.94.X.X:61922 [AP]
>>>>>> ACK sip:526@94.94.X.X:1238;transport=TCP;ob SIP/2.0.
>>>>>> Via: SIP/2.0/TCP 178.79.x.x;branch=z9hG4bKcydzigwkX.
>>>>>> Via: SIP/2.0/UDP
94.94.X.X:5060;branch=z9hG4bK4a420cee;rport=1025.
>>>>>> Max-Forwards: 16.
>>>>>> From: "asterisk"
<sip:512@test.domain>;tag=as76007db0.
>>>>>> To: <sip:526@test.domain:5060>.
>>>>>> Contact: <sip:512@94.94.X.X:1025>.
>>>>>> Call-ID: 068a5a23639785a7583d952d6f9bca84(a)test.domain.
>>>>>> CSeq: 102 ACK.
>>>>>> User-Agent: DICE 1.8.20.1.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>> On 7/30/13 6:44 PM, Roberto Fichera wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Sorry for cross-posting this email to PJLIB, but
maybe there are some things related.
>>>>>>>>>> Anyhow! I'm having problems on kamailio
v4.0.2 under Fedora 18 64bit and TCP client like iPhone using PJSIP
>>>>>>>>>> as SIP
>>>>>>>>>> library.
>>>>>>>>>> Basically once the iPhone side in close the call
(TCP->UDP) I'm getting the error below. Kamailio is running
>>>>>>>>>> under
>>>>>>>>>> a VPS
>>>>>>>>>> without
>>>>>>>>>> NATed network so it uses a real public address.
Furthermore, note that tcp_main is answering to a
>>>>>>>>>> 192.168.2.98 ip
>>>>>>>>>> address
>>>>>>>>>> which is the iPhone client. This looks really
strange to me since it should answer directly to the
>>>>>>>>>> public/port used
>>>>>>>>>> for
>>>>>>>>>> the registration
>>>>>>>>>> and not to a such kind of reserved address. The
kamilio configuration is basically the default with a very few
>>>>>>>>>> changes
>>>>>>>>>> like NAT, rtpproxy and postgresql backend.
>>>>>>>>>>
>>>>>>>>>> This problems doesn't happen at all when
using UDP->UDP calls. But I cannot use it because as you certain
>>>>>>>>>> know UDP
>>>>>>>>>> connection under iPhone will not work when the
application run in background mode.
>>>>>>>>>>
>>>>>>>>>> Can someone suggest how to solve this issue or
maybe suggest a TCP working solution for iPhone?
>>>>>>>>>>
>>>>>>>>>> Thanks in advance.
>>>>>>>>>> Roberto Fichera.
>>>>>>>>>>
>>>>>>>>>> Jul 30 16:21:53 proxy /usr/sbin/kamailio[9502]:
ERROR: <core> [tcp_main.c:4432]: tcpconn_main_timeout():
>>>>>>>>>> connect
>>>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
DBUG:get_command: received command "9483_9 D
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
as74e0c388 GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj"
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:handle_delete: forcefully deleting session 1 on ports 15604/17354
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTP stats: 354 in from callee, 603 in from caller,
>>>>>>>>>> 957
>>>>>>>>>> relayed, 0 dropped
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: RTCP stats: 5 in from callee, 2 in from caller, 7
>>>>>>>>>> relayed, 0
>>>>>>>>>> dropped
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
INFO:remove_session: session on ports 15604/17354 is cleaned up
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]:
DBUG:doreply: sending reply "9483_9 0
>>>>>>>>>> Jul 30 16:21:55 proxy rtpproxy[2262]: "
>>>>>>>>>> Jul 30 16:22:04 proxy /usr/sbin/kamailio[9502]:
ERROR: <core> [tcp_main.c:4432]: tcpconn_main_timeout():
>>>>>>>>>> connect
>>>>>>>>>> 192.168.2.98:5060 failed (timeout)
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
DBUG:get_command: received command "9496_16 D
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060
GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj as74e0c388"
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
INFO:handle_command: delete request failed: session
>>>>>>>>>> 12d1d19926c4ff742a52f0c855b1bb83@94.94.x.x:5060,
tags GROahimCK6KTrl5CkYEg7nuoPIIXZ8cj/as74e0c388 not found
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]:
DBUG:doreply: sending reply "9496_16 E8
>>>>>>>>>> Jul 30 16:22:14 proxy rtpproxy[2262]: "
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
>>>>>>>>>> sr-users(a)lists.sip-router.org
>>>>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>>> sr-users(a)lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
11:31 a.m.
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla
wrote:
Hi,
detection of whether a device
is behind nat is done based on comparing
source IP of the packet with the IP addresses in the SIP message. It is
no other way from application point of view.
If you look at the trace, the REGISTER has only public IP addresses, no
private address. Also, the Via header is perfectly matching the the
source IP and port of the packet.
Therefore, if the device is behind a nat in a private network, how does
it discover the public IP or the NAT router? Is the nat router running a
SIP ALG? Can you get the SIP trace on the device itself?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
Yes! They are behind NAT! Shouldn't
kamailio detect such behaviour so it will change the contact header and the other
fields accordingly using the nat_fix_XXXX functions? On 08/14/2013 10:19 AM, Daniel-Constantin Mierla
wrote:
Hi,
then how they discover the public IP address if they are behind NAT? Or did I
misunderstand that they are behind NAT? Hello,
as you can see in the REGISTER, the phone give a public IP where it can be contacted and
kamailio tries to deliver to
that address sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
Yep! That's the
problem
You should disable stun in the client and let the
server care of nat traversal.
As already said all client doesn't use any stun-
11:51 a.m.
On 08/14/2013 11:31 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
Mhhh!!! That's true!
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla
wrote:
Hi,
detection of whether a device
is behind nat is done based on comparing source IP of the packet with the IP addresses
in the SIP message. It is no other way from application point of view.
If you look at the trace, the REGISTER has only public IP addresses, no private address.
Also, the Via header is
perfectly matching the the source IP and port of the packet. Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
Yes! They are behind NAT! Shouldn't kamailio detect such behaviour so it will
change the contact header and the other
fields accordingly using the nat_fix_XXXX functions? On 08/14/2013 10:19 AM, Daniel-Constantin Mierla
wrote:
Hi,
> Hello,
>
> as you can see in the REGISTER, the phone give a public IP where it can be contacted
and kamailio tries to deliver to
> that address sip:528@94.94.X.X:1274;transport=TCP
>
> REGISTER comes from another port, but that is allowed in SIP.
Yep! That's the problem
> You should disable stun in the client and let the server care of nat traversal.
As already said all client doesn't use any stun-
then how they discover the
public IP address if they are behind NAT? Or did I misunderstand that they are behind NAT?
Therefore, if the device is behind a nat in a private
network, how does it discover the public IP or the NAT router?
Is the nat router running a SIP ALG? Can you get the SIP trace on the device itself?
Good question! It's a cisco 877 but the conf doesn't have any kind of SIP related
configuration. Does it handle
transparently the SIP traffic?
Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE
SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 02:31 by prod_rel_team
Cheers,
Daniel
11:59 a.m.
On 08/14/2013 11:51 AM, Roberto Fichera wrote:
On 08/14/2013 11:31 AM, Daniel-Constantin Mierla
wrote:
Hi,
Ok! There are two commands to disable it, since it's enabled by default!!!
no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
I'll test it right now!
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
Mhhh!!! That's
true!
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla
wrote:
Hi,
detection of whether a device
is behind nat is done based on comparing source IP of the packet with the IP addresses
in the SIP message. It is no other way from application point of view.
If you look at the trace, the REGISTER has only public IP addresses, no private address.
Also, the Via header is
perfectly matching the the source IP and port of the packet. Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
> On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
>
> Hi,
>
>> Hello,
>>
>> as you can see in the REGISTER, the phone give a public IP where it can be
contacted and kamailio tries to deliver to
>> that address sip:528@94.94.X.X:1274;transport=TCP
>>
>> REGISTER comes from another port, but that is allowed in SIP.
> Yep! That's the problem
>
>> You should disable stun in the client and let the server care of nat traversal.
> As already said all client doesn't use any stun-
then how they discover the public IP address if they are behind NAT? Or did I
misunderstand that they are behind NAT?
Yes! They are behind NAT! Shouldn't
kamailio detect such behaviour so it will change the contact header and the other
fields accordingly using the nat_fix_XXXX functions? Therefore, if the device is behind a nat in a
private network, how does it discover the public IP or the NAT router?
Is the nat router running a SIP ALG? Can you get the SIP trace on the device itself?
Good question! It's a cisco 877 but the conf doesn't have any kind of SIP
related configuration. Does it handle
transparently the SIP traffic?
Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE
SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 02:31 by prod_rel_team Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:36 p.m.
If you won't be able to disable SIP ALG on your router you can fill
$avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp +
";transport=" + $proto;
In this case all user location records will have the "received" attribut
even if a UA isn't behind NAT, but I don't see any problems with that.
On 08/14/2013 11:51 AM, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 08/14/2013 11:31 AM, Daniel-Constantin Mierla
wrote:
Hi,
Ok! There are two commands to
disable it, since it's enabled by default!!!
no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
I'll test it right now!
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
Mhhh!!! That's
true!
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla
wrote:
Hi,
> Hello,
>
> On 8/14/13 11:16 AM, Roberto Fichera wrote:
>> On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
>>
>> Hi,
>>
>>> Hello,
>>>
>>> as you can see in the REGISTER, the phone give a public IP where it can be
contacted and kamailio tries to deliver to
>>> that address sip:528@94.94.X.X:1274;transport=TCP
>>>
>>> REGISTER comes from another port, but that is allowed in SIP.
>> Yep! That's the problem
>>
>>> You should disable stun in the client and let the server care of nat
traversal.
>> As already said all client doesn't use any stun-
> then how they discover the public IP address if they are behind NAT? Or did I
misunderstand that they are behind NAT?
Yes! They are behind NAT! Shouldn't kamailio detect such behaviour so it will change
the contact header and the other
fields accordingly using the nat_fix_XXXX functions?
detection of whether a device
is behind nat is done based on comparing source IP of the packet with the IP addresses
in the SIP message. It is no other way from application point of view.
If you look at the trace, the REGISTER has only public IP addresses, no private address.
Also, the Via header is
perfectly matching the the source IP and port of the packet. Therefore, if the device is behind a nat in a
private network, how does it discover the public IP or the NAT router?
Is the nat router running a SIP ALG? Can you get the SIP trace on the device itself?
Good question! It's a cisco 877 but the conf doesn't have any kind of SIP
related configuration. Does it handle
transparently the SIP traffic?
Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE
SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 02:31 by prod_rel_team Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:32 p.m.
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
If you won't be able to disable SIP ALG on your
router you can fill $avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp +
";transport=" + $proto;
In this case all user location records will have the "received" attribut even
if a UA isn't behind NAT, but I don't
see any problems with that.
This one looks working, but the callee doesn't answer correctly because the TCP
isn't correct:
Contact::
<sip:528@94.94.X.X:1380;transport=TCP;ob>;q=;expires=294;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;received=<sip:94.94.X.X:37030;transport=tcp>;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
The contact uses a port which isn't translated inside by the router, the received
field shows the right one.
Should I change the Contact header instead? In case, how can I do that?
Cheers,
Roberto Fichera.
On 08/14/2013 11:51 AM, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 08/14/2013 11:31 AM, Daniel-Constantin Mierla
wrote:
Hi,
Ok! There are two commands to
disable it, since it's enabled by default!!!
no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
I'll test it right now!
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
> On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
>
> Hi,
>
>> Hello,
>>
>> On 8/14/13 11:16 AM, Roberto Fichera wrote:
>>> On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
>>>
>>> Hi,
>>>
>>>> Hello,
>>>>
>>>> as you can see in the REGISTER, the phone give a public IP where it can
be contacted and kamailio tries to
>>>> deliver to
>>>> that address sip:528@94.94.X.X:1274;transport=TCP
>>>>
>>>> REGISTER comes from another port, but that is allowed in SIP.
>>> Yep! That's the problem
>>>
>>>> You should disable stun in the client and let the server care of nat
traversal.
>>> As already said all client doesn't use any stun-
>> then how they discover the public IP address if they are behind NAT? Or did I
misunderstand that they are behind
>> NAT?
> Yes! They are behind NAT! Shouldn't kamailio detect such behaviour so it will
change the contact header and the other
> fields accordingly using the nat_fix_XXXX functions?
detection of whether a device is behind nat is done based on comparing source IP of the
packet with the IP addresses
in the SIP message. It is no other way from application point of view.
If you look at the trace, the REGISTER has only public IP addresses, no private address.
Also, the Via header is
perfectly matching the the source IP and port of the packet.
Mhhh!!! That's
true!
Therefore, if the device is behind a nat in a
private network, how does it discover the public IP or the NAT router?
Is the nat router running a SIP ALG? Can you get the SIP trace on the device itself?
Good question! It's a cisco 877 but the conf doesn't have any kind of SIP
related configuration. Does it handle
transparently the SIP traffic?
Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE
SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 02:31 by prod_rel_team Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:58 p.m.
On 08/14/2013 07:32 PM, Roberto Fichera wrote:
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
I didn't understand what "callee doesn't answer correctly" means.
Callee doesn't know what's in the received field of its registration.
The only problem I see is that your router changes ip in the contact
field of REGISTER requests and then kamailio puts this value
(new_ip:old_port) to INVITEs destined to UAs behind your NAT router.
It's not likely, but maybe pjsip doesn't like INVITEs with RURI which
differs from what it put to the contact during registration.
IIRC pjsua prints lots of debugging information. So you can check if
pjsua shows anything when INVITE comes in its log and also attach a
trace of such a call.
P.S. IMHO the best way to pass sip through such routers is sip over TLS.
If you won't be able to disable SIP ALG on
your router you can fill $avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp +
";transport=" + $proto;
In this case all user location records will have the "received" attribut even
if a UA isn't behind NAT, but I don't
see any problems with that.
This one looks working, but the callee doesn't
answer correctly because the TCP isn't correct:
Contact::
<sip:528@94.94.X.X:1380;transport=TCP;ob>;q=;expires=294;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;received=<sip:94.94.X.X:37030;transport=tcp>;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
The contact uses a port which isn't translated inside by the router, the received
field shows the right one.
Should I change the Contact header instead? In case, how can I do that?
16 Aug
16 Aug
12:29 p.m.
On 08/14/2013 09:58 PM, Vitaliy Aleksandrov wrote:
On 08/14/2013 07:32 PM, Roberto Fichera wrote:
Sorry! My typo! I meant why kamilio wasn't reusing the TCP port specified in the
REGISTER even for the INVITE.
I mean, kamailio now knows the received field so I'm expecting it routes the requests
for the called UA through the
address:port specified in this field.
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov
wrote:
I didn't understand what "callee doesn't answer correctly" means.
Callee doesn't know what's in the received field of its registration. If you won't be able to disable SIP ALG on
your router you can fill $avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp +
";transport=" + $proto;
In this case all user location records will have the "received" attribut even
if a UA isn't behind NAT, but I don't
see any problems with that.
This one looks working, but the callee doesn't
answer correctly because the TCP isn't correct:
Contact::
<sip:528@94.94.X.X:1380;transport=TCP;ob>;q=;expires=294;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;received=<sip:94.94.X.X:37030;transport=tcp>;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
The contact uses a port which isn't translated inside by the router, the received
field shows the right one.
Should I change the Contact header instead? In case, how can I do that? The only problem I see is that your router changes ip
in the contact field of REGISTER requests and then kamailio puts
this value
(new_ip:old_port) to INVITEs destined to UAs behind your NAT router.
Indeed, my testing router is affected by this ALG "problem"! I guess it's
better to disable it and complete simple TCP tests
then move to TLS.
It's not likely, but maybe pjsip doesn't like INVITEs with RURI which differs
from what it put to the contact during
registration.
IIRC pjsua prints lots of debugging information. So you can check if pjsua shows anything
when INVITE comes in its log
and also attach a trace of such a call.
pjsua doesn't report any problem so far, so seems accepting the INVITE.
P.S. IMHO the best way to pass sip through such routers is sip over TLS.
Yep! I'll do that.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
30 Aug
30 Aug
5:30 p.m.
On 08/16/2013 12:29 PM, Roberto Fichera wrote:
On 08/14/2013 09:58 PM, Vitaliy Aleksandrov wrote:
Just to say that everything works pretty fine once moved to TLS!
On 08/14/2013 07:32 PM, Roberto Fichera wrote:
Sorry! My typo! I meant why kamilio wasn't reusing the TCP port specified in the
REGISTER even for the INVITE.
I mean, kamailio now knows the received field so I'm expecting it routes the requests
for the called UA through the
address:port specified in this field.
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov
wrote:
I
didn't understand what "callee doesn't answer correctly" means.
Callee doesn't know what's in the received field of its registration. If you won't be able to disable SIP ALG on
your router you can fill $avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp +
";transport=" + $proto;
In this case all user location records will have the "received" attribut even
if a UA isn't behind NAT, but I don't
see any problems with that.
This one looks working, but the callee doesn't
answer correctly because the TCP isn't correct:
Contact::
<sip:528@94.94.X.X:1380;transport=TCP;ob>;q=;expires=294;flags=0x0;cflags=0x0;state=0;socket=<tcp:178.79.X.X:5060>;methods=0x1FDF;received=<sip:94.94.X.X:37030;transport=tcp>;user_agent=<PJSUA
v2.1-svn Linux-3.10.5.201/x86_64/glibc-2.17>;reg-id=0
The contact uses a port which isn't translated inside by the router, the received
field shows the right one.
Should I change the Contact header instead? In case, how can I do that? The only problem I see is that your router
changes ip in the contact field of REGISTER requests and then kamailio puts
this value
(new_ip:old_port) to INVITEs destined to UAs behind your NAT router.
Indeed, my
testing router is affected by this ALG "problem"! I guess it's better to
disable it and complete simple TCP tests
then move to TLS.
It's not likely, but maybe pjsip doesn't
like INVITEs with RURI which differs from what it put to the contact during
registration.
IIRC pjsua prints lots of debugging information. So you can check if pjsua shows anything
when INVITE comes in its log
and also attach a trace of such a call.
pjsua doesn't report any problem so
far, so seems accepting the INVITE.
P.S. IMHO the best way to pass sip through such
routers is sip over TLS.
Yep! I'll do that. _______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3899
days inactive
3930
days old
22 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Roberto Fichera -
Vitaliy Aleksandrov