search

sipwise / rtpengine

The Sipwise media proxy for Kamailio
GNU General Public License v3.0
794 stars 372 forks source link

RTP relaying issue after re-INVITE changing codec and ip/port #1416

Open miconda opened 2 years ago

miconda commented 2 years ago

With RTPEngine 8.5.7.1, but I haven't noticed any change that should be relevant in the diff to 8.5.7.2. I haven't checked newer series for LTS, sorry if this was fixed (or is how it should be) and wasting time here.

The problem results in no-audio after a re-INVITE from caller changing its codec and rtp ip/port, which puts on-hold and sending music. RTPEngine allocates a new rtp port towards the caller, which is fine from specs point of view. It keeps the same port towards the caller in the 200ok of the re-INVITE. It seems that RTPEngine still sends to callee from the port associated during the initial INVITE and in case of restrictive clients and nat (symmetric rtp required) the rtpstream does not go through.

What I notice is that RTPEngine shows the old RTP port (associated for initial INVITE) and new RTCP port (associated for re-INVITE) when listing the details of the session via rtpengine-ctl.

Next some relevant details.

Incoming sdp for initial invite snippet:

c=IN IP4 A.A.A.203
t=0 0
m=audio 3000 RTP/AVP 9 8 0 18 101

Outgoing:

c=IN IP4 R.R.R.7
t=0 0
m=audio 25854 RTP/AVP 9 8 0 18 101
a=rtcp:25855

Incoming 200ok:

c=IN IP4 B.B.B.250
t=0 0
m=audio 31442 RTP/AVP 9 101

Outgoing 200ok:

c=IN IP4 R.R.R.7
t=0 0
m=audio 25868 RTP/AVP 9 101

The rtpengine-ctl output:

--- Tag 'AIB39D641C339C7064', type: FROM_TAG, label '', branch '', callduration 17.391026, in dialogue with '2B4E3030333033307C121600'
------ Media #1 (audio over RTP/AVP) using G722/8000
-------- Port   R.R.R.7:25868 <> N.N.N.100:3000 , SSRC 80a0f05, 694 p, 119368 b, 0 e, 1639736016 ts
-------- Port   R.R.R.7:25869 <> N.N.N.100:1088  (RTCP), SSRC 80a0f05, 3 p, 252 b, 0 e, 1639736015 ts
--- Tag '2B4E3030333033307C121600', type: TO_TAG, label '', branch '', callduration 14.375741, in dialogue with 'AIB39D641C339C7064'
------ Media #1 (audio over RTP/AVP) using G722/8000
-------- Port   R.R.R.7:25854 <> B.B.B.250:31442, SSRC 820ef50d, 653 p, 112316 b, 0 e, 1639736016 ts
-------- Port   R.R.R.7:25855 <> B.B.B.250:31443 (RTCP), SSRC 820ef50d, 3 p, 240 b, 0 e, 1639736015 ts

Now, incoming re-INVITE from caller:

c=IN IP4 C.C.C.220
t=0 0
m=audio 40000 RTP/AVP 8 0 101

Outgoing re-INVITE:

c=IN IP4 R.R.R.7
t=0 0
m=audio 22378 RTP/AVP 8 0 101
a=rtcp:22379

Incoming 200ok:

c=IN IP4 B.B.B.250
t=0 0
m=audio 31442 RTP/AVP 8 101

Outgoing 200ok:

c=IN IP4 R.R.R.7
t=0 0
m=audio 25868 RTP/AVP 8 101

The rtpengine-ctl output:

--- Tag 'AIB39D641C339C7064', type: FROM_TAG, label '', branch '', callduration 2.107252, in dialogue with '2B4E3030333033307C121600'
------ Media #1 (audio over RTP/AVP) using G722/8000
-------- Port   R.R.R.7:25868 <> N.N.N.100:1088 , SSRC 10e4, 1492 p, 256624 b, 0 e, 1639736033 ts
-------- Port   R.R.R.7:25869 <> N.N.N..100:1088  (RTCP), SSRC 80a0f05, 7 p, 596 b, 0 e, 1639736031 ts
--- Tag '2B4E3030333033307C121600', type: TO_TAG, label '', branch '', callduration 1.992494, in dialogue with 'AIB39D641C339C7064'
------ Media #1 (audio over RTP/AVP) using G722/8000
-------- Port   R.R.R.7:25854 <> B.B.B.250:31442, SSRC 820ef50d, 1358 p, 233576 b, 0 e, 1639736031 ts
-------- Port   R.R.R.7:22379 <>  B.B.B.250:31443 (RTCP), SSRC 820ef50d, 6 p, 480 b, 0 e, 1639736031 ts

R.R.R.7 is the RTPEngine, N.N.N.100 is the NAT router, the rest are addresses for caller and callee as in sdp (callee is not behind nat).

As I could notice in the rtpengine-ctl output after re-INVITE, the rtp port on callee side is same as for initial INVITE, the RTCP port was updated on the other hand, as per sdp.

On caller side, both RTP and RTCP ports are listed being 1088, which for initial invite was only for RTCP.

I solved it by adding port-latching (inspired by https://github.com/sipwise/rtpengine/issues/1354 -- which seems different issues, btw), but feels like there is an issue without this flag, which is the default behaviour, therefore I thought of filling this report. At least the output of rtpengine-ctl seems to show the data messed up vs what's in sdp.

rfuchs commented 2 years ago

I can't immediately reproduce this. Is there any rtcp-mux involved? Do the incoming SDPs have an a=rtcp attribute?

miconda commented 2 years ago

No a=rtcp in incoming, and no rtcp-mux - here is full incoming sdp of the intial invite:

v=0
o=xyz 2108243473 2108243473 IN IP4 A.A.A.220
s=call
c=IN IP4 A.A.A.203
t=0 0
m=audio 3000 RTP/AVP 9 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -

And the outgoing:

v=0
o=xyz 2108243473 2108243473 IN IP4 R.R.R.7
s=call
c=IN IP4 R.R.R.7
t=0 0
m=audio 25854 RTP/AVP 9 8 0 18 101
a=silenceSupp:off - - - -
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv
a=rtcp:25855
a=ptime:20

Incoming re-INVITE sdp:

v=0
o=xyz 2108243473 2108243474 IN IP4 A.A.A.220
s=call
c=IN IP4 A.A.A.220
t=0 0
m=audio 40000 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
a=ptime:20

And outgoing:

v=0
o=xyz 2108243473 2108243474 IN IP4 R.R.R.7
s=call
c=IN IP4 R.R.R.7
t=0 0
m=audio 22378 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
a=rtcp:22379
a=ptime:20
rfuchs commented 2 years ago

Still can't reproduce this, even with some packets from random ports sent in. Something is missing. Either some extra flags that I'm not using, or something weird with the RTP flow.

moose:~/src/ngcp-git/rtpengine(detached*)$ CALLID=$RANDOM
moose:~/src/ngcp-git/rtpengine(detached*)$ perl -Iperl utils/rtpengine-ng-client offer --call-id=$CALLID --from-tag=foo --sdp-file=/home/dfx/sdp-offer --ICE=remove 
Old SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=xyz 2108243473 2108243473 IN IP4 10.0.0.220
s=call
c=IN IP4 10.0.0.203
t=0 0
m=audio 3000 RTP/AVP 9 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -

----->8----->8----->8----->8----->8-----
New SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=xyz 2108243473 2108243473 IN IP4 10.0.0.220
s=call
c=IN IP4 192.168.1.87
t=0 0
m=audio 30092 RTP/AVP 9 8 0 18 101
a=silenceSupp:off - - - -
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv
a=rtcp:30093
a=ptime:20

----->8----->8----->8----->8----->8-----
moose:~/src/ngcp-git/rtpengine(detached*)$ perl -Iperl utils/rtpengine-ng-client answer --call-id=$CALLID --from-tag=foo --sdp-file=/home/dfx/sdp-answer --ICE=remove --to-tag=bar
Old SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=nga911 1626335931 1626335932 IN IP4 100.86.60.67
s=nga911
c=IN IP4 192.168.1.95
t=0 0
m=audio 9000 RTP/AVP 9 101
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000

----->8----->8----->8----->8----->8-----
New SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=nga911 1626335931 1626335932 IN IP4 100.86.60.67
s=nga911
c=IN IP4 192.168.1.87
t=0 0
m=audio 30102 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=rtcp:30103
a=ptime:20

----->8----->8----->8----->8----->8-----
moose:~/src/ngcp-git/rtpengine(detached*)$ perl -Iperl utils/rtpengine-ng-client offer --call-id=$CALLID --from-tag=foo --sdp-file=/home/dfx/sdp-offer2 --ICE=remove 
Old SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=xyz 2108243473 2108243474 IN IP4 10.0.0.220
s=call
c=IN IP4 10.0.0.220
t=0 0
m=audio 40000 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
a=ptime:20

----->8----->8----->8----->8----->8-----
New SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=xyz 2108243473 2108243474 IN IP4 10.0.0.220
s=call
c=IN IP4 192.168.1.87
t=0 0
m=audio 30118 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
a=rtcp:30119
a=ptime:20

----->8----->8----->8----->8----->8-----
moose:~/src/ngcp-git/rtpengine(detached*)$ perl -Iperl utils/rtpengine-ng-client answer --call-id=$CALLID --from-tag=foo --sdp-file=/home/dfx/sdp-answer2 --ICE=remove --to-tag=bar
Old SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=nga911 1626335931 1626335932 IN IP4 100.86.60.67
s=nga911
c=IN IP4 192.168.1.95
t=0 0
m=audio 9000 RTP/AVP 8 101
a=recvonly
a=rtpmap:101 telephone-event/8000

----->8----->8----->8----->8----->8-----
New SDP:
-----8<-----8<-----8<-----8<-----8<-----
v=0
o=nga911 1626335931 1626335932 IN IP4 100.86.60.67
s=nga911
c=IN IP4 192.168.1.87
t=0 0
m=audio 30102 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=recvonly
a=rtcp:30103
a=ptime:20

----->8----->8----->8----->8----->8-----
moose:~/src/ngcp-git/rtpengine(detached*)$ echo list sessions $CALLID | nc localhost 2224

callid: 28119
deletionmark: no
created: 1639766478
proxy: 127.0.0.1:56112
tos: 0
last_signal: 1639766516
redis_keyspace: 0
foreign: no

--- Tag 'foo', type: FROM_TAG, label '', branch '', callduration 22.428681, in dialogue with 'bar'
------ Media #1 (audio over RTP/AVP) using unknown codec
-------- Port    192.168.1.87:30102 <>    192.168.1.87:36778, SSRC 0, 2 p, 28 b, 0 e, 1639766520 ts
-------- Port    192.168.1.87:30103 <>    192.168.1.87:38271 (RTCP), SSRC 0, 2 p, 27 b, 0 e, 1639766522 ts
--- Tag 'bar', type: TO_TAG, label '', branch '', callduration 10.466440, in dialogue with 'foo'
------ Media #1 (audio over RTP/AVP) using unknown codec
-------- Port    192.168.1.87:30118 <>    192.168.1.87:57172, SSRC 0, 2 p, 32 b, 0 e, 1639766516 ts
-------- Port    192.168.1.87:30119 <>    192.168.1.87:41044 (RTCP), SSRC 0, 2 p, 22 b, 0 e, 1639766516 ts

moose:~/src/ngcp-git/rtpengine(detached*)$
miconda commented 2 years ago

I will get the flags sent to rtpegnine, this time I was involved on troubleshooting session only. The issue was observed with a UA (some pbx as I understood) that changes the ip/port and codec on re-INVITE to put the call on hold and play music. Looked like during the call was doing pass through RTP and for on-hold, it sends the music.

miconda commented 2 years ago

Here is the relevant kamailio.cfg snippet:

        $var(rtpflags) = "replace-origin replace-session-connection ICE=remove";

        if (nat_uac_test("8")) {
            $var(rtpflags) = "SIP-source-address " + $var(rtpflags);
        }
        rtpengine_manage("$var(rtpflags)");

For the the caller the flags should be:

SIP-source-address replace-origin replace-session-connection ICE=remove

I added port-latching before ICE=remove and made it work.

As I wrote initialy, the rtpengine version is 8.5.7.1, and in case it matters, it is configured to do also call recording, but not enabled for this kind of calls.