Exactly,

 

It appears that the destination of the 1st call (217.112.180.235) is NAT aware 
but the 2nd (79.137.49.139) isn’t. The latter is probably using the local IP in 
the SDP rather than the public IP detectable by examining the IP of the 
incoming RTP.

 

What’s the difference between these 2 UAs?

 

 

From: sr-users [mailto:[email protected]] On Behalf Of David 
Villasmil
Sent: Monday, January 22, 2018 11:42 AM
To: Kamailio (SER) - Users Mailing List <[email protected]>
Subject: Re: [SR-Users] Problem Proxy

 

Hello

Without looking at the config. It looks like you're not doing nat traversal. 
Are you using a default config? Which one? 

 

On Mon, Jan 22, 2018, 09:21 Nicolas Breuer <[email protected] 
<mailto:[email protected]> > wrote:

Hello,

 

Any ideas on this ? 😊

 

 

De : sr-users [mailto:[email protected] 
<mailto:[email protected]> ] De la part de Nicolas Breuer
Envoyé : jeudi 18 janvier 2018 23:49
À : Kamailio (SER) - Users Mailing List <[email protected] 
<mailto:[email protected]> >
Objet : [SR-Users] Problem Proxy

 

 

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 <http://217.112.180.235:1024> 
 -> 217.112.180.10:5060 <http://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@  <sip:32XXXXXX87@%20> >;tag=gK0d4dfe6f.

Call-ID: [email protected] 
<mailto:[email protected]> .

CSeq: 29328 INVITE.

Contact: <sip:[email protected]: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:[email protected]>;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 <http://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 <http://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 <http://217.112.180.235:1024> 
 -> 217.112.180.10:5060 <http://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@  <sip:32XXXXXX87@%20> >;tag=gK0b5d7652.

Call-ID: [email protected] 
<mailto:[email protected]> .

CSeq: 21946 INVITE.

Contact: <sip:[email protected]: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:[email protected]>;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:[email protected] 
<mailto:INFO%3Artpp_command_ul_handle%[email protected]> : 
lookup on ports 11264/10446, session timer restarted

Jan 18 21:51:26 proxy1 rtpproxy[1314]: 
INFO:rtpp_command_ul_handle:[email protected] 
<mailto:INFO%3Artpp_command_ul_handle%[email protected]> : 
pre-filling callee's address with 192.168.2.2:49156 <http://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 <http://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 <http://217.112.180.235:49155>  (RTCP)

Jan 18 21:51:32 proxy1 rtpproxy[1314]: 
INFO:rxmit_packets:[email protected] 
<mailto:INFO%3Arxmit_packets%[email protected]> : callee's 
address filled in: 217.112.180.235:49157 <http://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,

 

 

_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected] <mailto:[email protected]> 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to