Received answer SDP with media ID ('0') when no media ID was offered

[Alex Balashov]

I know this log emission from RTPEngine has been discussed here before:

[core] Received answer SDP with media ID ('0') when no media ID was offered
[core] Usage error: List of codecs empty. Restoring original list of codecs. Results may be unexpected.

But I don't think a clear conclusion was ever reached about what gives rise to it. In this case, the offending SDP answer stanza, coming from a browser endpoint (JsSIP), is:

----------
v=0
o=- 8392163017797943107 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS J3pAm2caPjJBsW4ISr4Ii60ObgTJVaWiodUl
m=audio 9 UDP/TLS/RTP/SAVP 0
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:iFJV
a=ice-pwd:Aw9HwtfhTPoc3sXY0orNc2Rq
a=ice-options:trickle
a=fingerprint:sha-256 32:76:EA:EA:3C:1D:DE:A8:83:3C:95:DD:27:5D:77:82:D5:8D:1A:A3:18:DC:6C:5C:4B:57:6F:BE:0D:43:A4:98
a=setup:active
a=mid:0
a=sendrecv
a=msid:J3pAm2caPjJBsW4ISr4Ii60ObgTJVaWiodUl 9c46eb67-c7ef-40d1-b3bf-df58df477702
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=ptime:20
a=ssrc:3475439576 cname:rnigRRKWMbibSiKp
a=ssrc:3475439576 msid:J3pAm2caPjJBsW4ISr4Ii60ObgTJVaWiodUl 9c46eb67-c7ef-40d1-b3bf-df58df477702
a=ssrc:3475439576 mslabel:J3pAm2caPjJBsW4ISr4Ii60ObgTJVaWiodUl
a=ssrc:3475439576 label:9c46eb67-c7ef-40d1-b3bf-df58df477702
----------

I am uncertain as to what could be upsetting about this SDP. For what it's worth, the incoming SDP offer to the browser endpoint was:

----------
v=0
o=- 1711932753 1711932754 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=audio 60824 UDP/TLS/RTP/SAVP 0 8 3 101
c=IN IP4 x.x.x.x
a=rtcp:60825 IN IP4 x.x.x.x
a=candidate:IG3nueCZQkR7uv99 1 udp 2130706431 x.x.x.x 60824 typ host generation 0
a=candidate:IG3nueCZQkR7uv99 2 udp 2130706430 x.x.x.x 60825 typ host generation 0
a=ice-ufrag:cbsIZrsn
a=ice-pwd:zZV2IpcZV3UJ7E590WBxTAv3Gv
a=fingerprint:sha-256 CE:FA:DF:27:AF:65:0F:21:AC:03:06:72:A7:C2:D1:F5:E9:A8:B6:CF:11:CF:48:D4:09:F7:0A:23:90:D7:FA:7C
a=setup:actpass
a=mid:0
a=sendrecv
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
----------

The `a=mid:0` attribute is present in both of these. Of course, the plain UDP endpoint on the other side of RTPEngine would not send a media ID in its offer; this is added by RTPEngine. Moreover, we are plainly offering PCMU/8000 to the browser endpoint, and payload type 0 is the customary PT for it, is it not?

Thank you in advance for any insight!

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

[Richard Fuchs]

On 02/04/2024 11.43, Alex Balashov wrote:

I know this log emission from RTPEngine has been discussed here before:

[core] Received answer SDP with media ID ('0') when no media ID was offered
[core] Usage error: List of codecs empty. Restoring original list of codecs. Results may be unexpected.

But I don't think a clear conclusion was ever reached about what gives rise to it. In this case, the offending SDP answer stanza, coming from a browser endpoint (JsSIP), is:

You'll have to look at the signalling in more detail. If what you've posted was in fact the SDP going to the WebRTC client and the SDP coming from it, then this would indeed be unexpected, unless you have a mix-up in from/to-tags for example (i.e. rtpengine doesn't know that these relate to the same client). Using additional SDP manipulation options may also be an explanation.

Cheers

[Alex Balashov]

> On Apr 2, 2024, at 12:25 PM, 'Richard Fuchs' via Sipwise rtpengine <rtpe...@googlegroups.com> wrote:
>
> You'll have to look at the signalling in more detail. If what you've posted was in fact the SDP going to the WebRTC client and the SDP coming from it, then this would indeed be unexpected, unless you have a mix-up in from/to-tags for example (i.e. rtpengine doesn't know that these relate to the same client).

Do you know under what circumstances such a mix-up might occur, provided that Kamailio is the controlling instrument?

> Using additional SDP manipulation options may also be an explanation.

For what it's worth, here are the RTPEngine options used in the offer from Kamailio:

replace-origin replace-session-connection ICE=force UDP/TLS/RTP/SAVP SDES-off rtcp-mux-offer
direction=internal direction=external

And for the answer going back to the UDP endpoint:

replace-origin replace-session-connection ICE=remove RTP/AVP rtcp-mux-demux codec-strip=all
codec-offer=PCMU,telephone-event direction=external direction=internal

[Richard Fuchs]

On 02/04/2024 12.30, Alex Balashov wrote:

Do you know under what circumstances such a mix-up might occur, provided that Kamailio is the controlling instrument?

The most common situation I know of is an extra answer from an unknown to-tag (i.e. offer from A, answer from B, then another answer from C). We don't currently support this without explicitly telling rtpengine ahead of time that another branch (the one to C) exists, using a second offer message.

For what it's worth, here are the RTPEngine options used in the offer from Kamailio:

   replace-origin replace-session-connection ICE=force UDP/TLS/RTP/SAVP SDES-off rtcp-mux-offer 
   direction=internal direction=external

Assuming this offer was coming from a non-WebRTC client that didn't have `a=mid` included already, this is missing the `generate-mid` option. Also for WebRTC endpoints normally you'd want to use `rtcp-mux-require` instead (and possibly also `no-rtcp-attribute`).

And for the answer going back to the UDP endpoint:

   replace-origin replace-session-connection ICE=remove RTP/AVP rtcp-mux-demux codec-strip=all
   codec-offer=PCMU,telephone-event direction=external direction=internal

I'm not 100% positive off the top of my head but I don't believe the comma syntax works for codec-offer. List them separately (`codec-offer-PCMU codec-offer-telephone-event`). Check the debug log to see what's actually in the message.

Cheers

[Alex Balashov]

> On Apr 2, 2024, at 12:44 PM, 'Richard Fuchs' via Sipwise rtpengine <rtpe...@googlegroups.com> wrote:
>
> On 02/04/2024 12.30, Alex Balashov wrote:
>> Do you know under what circumstances such a mix-up might occur, provided that Kamailio is the controlling instrument?

> The most common situation I know of is an extra answer from an unknown to-tag (i.e. offer from A, answer from B, then another answer from C). We don't currently support this without explicitly telling rtpengine ahead of time that another branch (the one to C) exists, using a second offer message.

Would this be cured by using the via-branch parameter?

>> For what it's worth, here are the RTPEngine options used in the offer from Kamailio:
>>
>> replace-origin replace-session-connection ICE=force UDP/TLS/RTP/SAVP SDES-off rtcp-mux-offer
>> direction=internal direction=external

> Assuming this offer was coming from a non-WebRTC client that didn't have `a=mid` included already, this is missing the `generate-mid` option. Also for WebRTC endpoints normally you'd want to use `rtcp-mux-require` instead (and possibly also `no-rtcp-attribute`).

Thank you for these recommendations. However, I am curious:

1) a=mid seems to be generated on offers and answers anyway, despite not being present on the incoming offer/answer from the plain UDP side, and without the `generate-mid` option.

2) Is RTCP-MUX pretty much universal now? I got the impression this was a Chrome-mandated thing.

3) Is the reason for `no-rtcp-attribute` that the RTCP attribute would conflict with RTCP-MUX?

If I understand SDP correctly, it is a statement about what one is willing to accept, and it seems that it would be all right to accept both? Or am I mistaken?

>> And for the answer going back to the UDP endpoint:
>>
>> replace-origin replace-session-connection ICE=remove RTP/AVP rtcp-mux-demux codec-strip=all
>> codec-offer=PCMU,telephone-event direction=external direction=internal
>>

> I'm not 100% positive off the top of my head but I don't believe the comma syntax works for codec-offer. List them separately (`codec-offer-PCMU codec-offer-telephone-event`). Check the debug log to see what's actually in the message.

I could also be mistaken, but I believe past testing revealed that the comma-separated codec-offer list did work, when the context is the RTPEngine control module in Kamailio. I'll take a second look, thank you.

[Richard Fuchs]

On 03/04/2024 10.08, Alex Balashov wrote:

The most common situation I know of is an extra answer from an unknown to-tag (i.e. offer from A, answer from B, then another answer from C). We don't currently support this without explicitly telling rtpengine ahead of time that another branch (the one to C) exists, using a second offer message.

Would this be cured by using the via-branch parameter? 

In combination with submitting the offer multiple times to rtpengine, yes. But there are instances that produce multiple answers with multiple to-tags unsolicited (usually involving 18x replies), i.e. without doing the branching yourself.

1) a=mid seems to be generated on offers and answers anyway, despite not being present on the incoming offer/answer from the plain UDP side, and without the `generate-mid` option.

I don't think that's correct as most of our test cases would then fail.

2) Is RTCP-MUX pretty much universal now? I got the impression this was a Chrome-mandated thing. 

3) Is the reason for `no-rtcp-attribute` that the RTCP attribute would conflict with RTCP-MUX? 

If I understand SDP correctly, it is a statement about what one is willing to accept, and it seems that it would be all right to accept both? Or am I mistaken?

RTCP-mux is mandated by WebRTC and so cannot be negotiated in that context, and for this reason some WebRTC stacks don't like to see an `a=rtcp` attribute as it's redundant (and especially not with a port different from the RTP port, as that would indicate that RTCP-mux is optional).

Cheers