Getting other side no call RTP P2P packates

Asterisk Asterisk SIP
1

I have one server which is running ok for everywhere but one of my client is getting error in RTP packet. when I checked log, I am getting following log at RTP debuggin

Got  RTP packet from    18.216.***.***:56018 (type 00, seq 039150, ts 1485731616, len 000160)
Sent RTP packet to      89.208.152.***:32086 (type 08, seq 008691, ts 1485731616, len 000160)
Sent RTP P2P packet to 198.101.50.**:13342 (type 00, len 000160)
Sent RTP P2P packet to 14.102.145.**:29842 (type 00, len 000160)
Sent RTP P2P packet to 198.101.50.**:13342 (type 00, len 000160)

I am not sure what is P2P packets but other side customer complaining he is not getting RTP packet, but on our all servers everything is working fine.
anyhow idea how I can investigate.

2

It means that RTP packets are being forwarded internally in an optimized fashion. I’d suggest providing the SIP traffic so the addresses provided can be examined, and you should also do a packet capture to see the traffic flowing.

3

I got from the customer side following debug information

U 2019/04/17 11:20:19.315795 162.243.32.115:5060 -> 10.99.0.155:5060
INVITE sip:16173138888@18.216.101.155 SIP/2.0.
Via: SIP/2.0/UDP 162.243.32.115:5060;branch=z9hG4bK78618661;rport.
Max-Forwards: 70.
From: "73519218764" <sip:73519218764@162.243.32.115>;tag=as2b32f158.
To: <sip:16173138888@18.216.101.155>.
Contact: <sip:73519218764@162.243.32.115:5060>.
Call-ID: 59a6df5d3006fb585ff8ecb81628f84d@162.243.32.115:5060.
CSeq: 102 INVITE.
User-Agent: DiDXsuPErTecSIP4.
Date: Wed, 17 Apr 2019 15:20:19 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Remote-Party-ID: "73519218764" <sip:73519218764@162.243.32.115>;party=calling;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 311.
.
v=0.
o=root 1569428527 1569428527 IN IP4 162.243.32.115.
s=Asterisk PBX 11.25.3.
c=IN IP4 162.243.32.115.
t=0 0.
m=audio 12042 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.


U 2019/04/17 11:20:19.316858 10.99.0.155:5060 -> 162.243.32.115:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 162.243.32.115:5060;branch=z9hG4bK78618661;rport=5060.
From: "73519218764" <sip:73519218764@162.243.32.115>;tag=as2b32f158.
To: <sip:16173138888@18.216.101.155>;tag=5e64e7c1ee.
Call-ID: 59a6df5d3006fb585ff8ecb81628f84d@162.243.32.115:5060.
CSeq: 102 INVITE.
Content-Length: 0.
.


U 2019/04/17 11:20:19.320505 10.99.0.155:5060 -> 162.243.32.115:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 162.243.32.115:5060;branch=z9hG4bK78618661;rport=5060.
From: "73519218764" <sip:73519218764@162.243.32.115>;tag=as2b32f158.
To: <sip:16173138888@18.216.101.155>;tag=5e64e7c1ee.
Call-ID:
4

That is incomplete, but you need to check your side as well and look at the actual addresses and ports used - ensuring that they appear to be correct.

5

This is on my side sip debu

Audio is at 18260
Adding codec 100003 (ulaw) to SDP
Adding codec 100004 (alaw) to SDP
Adding codec 100008 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 192.216.101.155:5060:
6

I don’t have context and RTP debug was not on, so I can’t say anything else except that nothing looks out of the ordinary.

The IP address we would send to is in the “c=” line, and the port we would send to is on the “m=” line. If NAT options are enabled then this may change, but if no NAT options are enabled then we will send to where we are told.

7

Yes actually seem all ok on our side, I transferred call to other server and it is working perfectly. Thank you will check with customer side.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.