[SR-Users] Problem Proxy

[Nicolas Breuer]

Hello the list,

I have a problem on the proxy with the audio between two calls bridged by a UAC.
When I made a normal call, no problems.

My UAC is nated.
UAC > Router > KAMAILIO

Frames arrives with private IP in the SDP.

U 2018/01/18 21:50:16.798581 217.112.180.235:1024 -> 217.112.180.10:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 217.112.180.10;branch=z9hG4bK2d06.2f2a1856bde881173a3fc413c4136b83.0.
Via: SIP/2.0/UDP 84.14.241.179:5060;rport=5060;branch=z9hG4bK0dBe3143bcf7f60a70b.
Record-Route: <sip:217.112.180.10;lr=on;ftag=gK0d4dfe6f;did=227.c0d2;nat=yes>.
From: <sip:32XXXXXX87@ >;tag=gK0d4dfe6f.
Call-ID: 940401290_111374574 at 84.14.241.179.
CSeq: 29328 INVITE.
Contact: <sip:32XXXXXX61 at 192.168.2.2:5060;transport=udp>.
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY.
Supported: timer,100rel.
Server: IP Office 10.1.0.0.0 build 237.
Min-SE: 1800.
Require: timer.
Session-Expires: 1800;refresher=uas.
To: <sip:32XXXXXX61 at 217.112.180.235>;tag=998e429e819ba686.
Content-Type: application/sdp.
Content-Length: 202.
.
v=0.
o=UserA 3721571424 1025404311 IN IP4 192.168.2.2.
s=Session SDP.
c=IN IP4 192.168.2.2.
t=0 0.
m=audio 49154 RTP/AVP 9 101.
a=rtpmap:9 G722/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

I don't understand why but the proxy (in case of an incoming call) succeed to determine the public IP.

Jan 18 21:40:08 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: caller's address filled in: 217.112.180.235:49154 (RTP)
Jan 18 21:40:08 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: guessing RTCP port for caller to be 49155
Jan 18 21:40:16 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: caller's address latched in: 217.112.180.235:49155 (RTCP)

Don't know why because the only information in SDP is 192.168.2.2
The Kamailio didn't send the information of the proxy to the UAC , but to the other end as this is an incoming call.


So I have audio in this case.

When I setup a bridge on the UAC to a second number, we have an issue. ( Kamailio 4.4.6 )

This is the same frames

U 2018/01/18 21:51:26.607270 217.112.180.235:1024 -> 217.112.180.10:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 217.112.180.10;branch=z9hG4bK4181.bb7aab84b6fb0aea5836b4d8874406ec.0.
Via: SIP/2.0/UDP 84.14.241.179:5060;rport=5060;branch=z9hG4bK0bB16ee5a3d300fee16.
Record-Route: <sip:217.112.180.10;lr=on;ftag=gK0b5d7652;did=cc6.5452;nat=yes>.
From: <sip:32XXXXXX87@ >;tag=gK0b5d7652.
Call-ID: 940248136_13287504 at 84.14.241.179.
CSeq: 21946 INVITE.
Contact: <sip:32XXXXXX61 at 192.168.2.2:5060;transport=udp>.
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY.
Supported: timer,100rel.
Server: IP Office 10.1.0.0.0 build 237.
Min-SE: 1800.
Require: timer.
Session-Expires: 1800;refresher=uas.
To: <sip:32XXXXXX61 at 217.112.180.235>;tag=559c99f5edcab5d4.
Content-Type: application/sdp.
Content-Length: 202.
.
v=0.
o=UserA 1781830446 4071482272 IN IP4 192.168.2.2.
s=Session SDP.
c=IN IP4 192.168.2.2.
t=0 0.
m=audio 49156 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.

But in this case no audio

RTCP detected but no the RTP.
He took the private ip address "192.168.2.2" and this is the reason of the "no audio".


Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rtpp_command_ul_handle:940248136_13287504 at 84.14.241.179: lookup on ports 11264/10446, session timer restarted
Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rtpp_command_ul_handle:940248136_13287504 at 84.14.241.179: pre-filling callee's address with 192.168.2.2:49156
Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rxmit_packets:e1e387824e0753522b7bc55e02090784: callee's address latched in: 79.137.49.139:39176 (RTP)
Jan 18 21:51:32 proxy1 rtpproxy[1314]: INFO:rxmit_packets:e1e387824e0753522b7bc55e02090784: caller's address filled in: 217.112.180.235:49155 (RTCP)
Jan 18 21:51:32 proxy1 rtpproxy[1314]: INFO:rxmit_packets:940248136_13287504 at 84.14.241.179: callee's address filled in: 217.112.180.235:49157 (RTCP)

I would like to understand why with the first call, no issues to determine the RTP IP and not in the second case,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180118/e805696d/attachment.html>