One Way Audio - Continues Marker bit

[Lewis Hutchinson]

I have an example I wanted to run by this group to make sure I had all bases covered.

When a call is received from a particular international provider down a certain route there is one way audio. The issue i believe is that the RTP has a marker bit set on every packet from that direction but the RFC states that it should not be used like this https://www.ietf.org/rfc/rfc3551.txt (Section 4 in particular ) and

Every packet having              1... .... = Marker: True                  is not right….

It should be ( N.B ** there is no silence suppression enabled )

Marker bit (M): In audio streams, if silence suppression is enabled, the marker bit (M) SHOULD be one for the first packet of a talk spurt and zero for all other packets. Failure to do so can result in reduced audio quality at the receiving end. If silence suppression is disabled, the marker bit can be one for the first packet in the stream, but SHOULD be zero for all other packets. 



In other cases where the Marker bit is used but in accordance with the RFC everything works fine. I have asked for this to be escalated to the upstream provider and am waiting a response but wanted to make sure i have all bases covered and wondering if there is anything in RTP engine i can do to help diagnose, resolve, handle this scenario or this is outside of our control.

Thanks

Lewis

[Richard Fuchs]

Hi,

I'd say your interpretation of the RFC is correct, with the caveat that in most cases that I'm aware of the marker bit should be taken only as a hint and not as a strict requirement. IOW setting the marker bit on every packet is definitely unusual and unexpected and not what the RFC suggests, and I can see how it can cause problems on the receiver's side. OTOH it's also not strictly "wrong" and a well behaved receiver should be able to cope with it.

In fact rtpengine largely ignores the marker bit, and so I'm afraid that as of today it's also not able to clean it up when passing through RTP. You could only run the audio through the transcoding engine, which will (probably?) reset the marker bit, but at a heavy CPU penalty.

HTH

Cheers

Lewis --
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/d38a9b67-1071-4da6-9a8e-e45a485f2d9an%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lewis]

Hi,

Thanks for taking the time to look at it and providing comment. I can confirm that there is numerous calls that go through RTPengine with the "Correct" Marker bit pattern and everything works fine but with the RTP stream going into RTP engine with a Marker on every Bit nothing comes out the other side of the RTPengine to the next hop (SBC). Its like the RTPengine isn't able to handle this and doesnt send onto the next Hop (SBC >>> SIP DEVICE)

Received audio from SIP DEVICE >>> SBC >>> RTPengine is all good causing One Way Audio

So the below comment surprised me a bit

| "In fact rtpengine largely ignores the marker bit, and so I'm afraid that as of today it's also not able to clean it up when passing through RTP."  |

Is there any documents about what RTPengine does with Marker Bits?

I think the issue is with the marker being continually sent but i want to be 100% because as it manifests with it not sending a stream back out of RTPengine onwards fingers are pointed this way 

Regards

Lewis

[Richard Fuchs]

On 02/09/2022 10.48, [EXT] Lewis wrote:
> Hi,
>
> Thanks for taking the time to look at it and providing comment. I can
> confirm that there is numerous calls that go through RTPengine with
> the "Correct" Marker bit pattern and everything works fine but with
> the RTP stream going into RTP engine with a Marker on every Bit
> nothing comes out the other side of the RTPengine to the next hop
> (SBC). Its like the RTPengine isn't able to handle this and doesnt
> send onto the next Hop (SBC >>> SIP DEVICE)
>
> Received audio from SIP DEVICE >>> SBC >>> RTPengine is all good
> causing One Way Audio
>
> So the below comment surprised me a bit
>
> | "In fact rtpengine largely ignores the marker bit, and so I'm afraid
> that as of today it's also not able to clean it up when passing
> through RTP."  |
>
> Is there any documents about what RTPengine does with Marker Bits?

Well no, since it doesn't really do anything with it. 😃

The only reference I see in the code that pays any attention to it is
the jitter buffer, which uses it to reset the timing.

Every other piece of code simply preserves the bit when passing through RTP.

> I think the issue is with the marker being continually sent but i want
> to be 100% because as it manifests with it not sending a stream back
> out of RTPengine onwards fingers are pointed this way

That would be very surprising. Usually networking problems or some
booboo in the SDP negotiation or other signalling to rtpengine are more
likely explanations. If you have logs and pcaps that demonstrate the
issue, feel free to post them.

Cheers

[Lewis]

Let me continue looking and see if I can see anything although I have reviewed it several times. Maybe some fresh eyes on Monday might help. I appreciate the offer but I don't think I am allowed to put the traces on a public group. I would have to check.

Regards

Lewis

[Lewis]

I am still struggling with this, I have looked at many different aspects of the bad calls to see if i could find any patter and there isnt one, Other than when RTPengine is spammed with Marker Bits from the International PSTN Provider the Stream does not come out of the other sided. Every other hop in the chain ignores it and passes it on, until it hits RTPengine then it stops

Can you assist me in debugging this a little more. Is there anything you would suggest me looking at. Any extra logging or specific tests to carry out?

Currently on
Version: 10.4.1.3-1~bpo10+1

[Richard Fuchs]

On 05/09/2022 10.34, [EXT] Lewis wrote:
> I am still struggling with this, I have looked at many different
> aspects of the bad calls to see if i could find any patter and there
> isnt one, Other than when RTPengine is spammed with Marker Bits from
> the International PSTN Provider the Stream does not come out of the
> other sided. Every other hop in the chain ignores it and passes it on,
> until it hits RTPengine then it stops
>
> Can you assist me in debugging this a little more. Is there anything
> you would suggest me looking at. Any extra logging or specific tests
> to carry out?

I would suggest to enable debug logging (either globally or just for one
call) and see what rtpengine does with the packets. You should have log
messages both for received RTP packets and for sent/forwarded packets.
This should give you a pretty good clue about what is happening to the
packets.

Cheers

[Lewis]

Hi Richard

I have enabled log-level = 7 and captured traces but i cant find anything in there that is jumping out with WARNING or ERROR, there appears to be no attempt to send the RTP stream in the trace. I have walked through the traces side by side with good calls from a DEBUG log but things look to be the same. I have also shut down all RTPengine except for 1 to ensure that everything flows through one RTPengine but again nothing in logs to help identify the issue. Every time the call originates from a Romanian Orange Mobile number we get masses of Marker Bits and the RTP stream comes into RTPengine but never out the other side.

I have asked this to be escalated to the provider to try and stop this happening but wanted to try and have a concrete answer on what is happened to back up my request.

I have debug log and a PCAPs of bad calls but can not find anything to say why the stream does not get passed out of RTPengine when received with this format. I have also tried several options around transcoding, fixing Codes, branch handling and so on to no avail. I am stumped.

I will keep you posted.

[Ahmed]

Hi,

I'm having a similar issue and was wondering if there was any solution to this. In my case rtpengine is relaying the packets as they are from leg B to leg A but leg A device doesn't handle this  case well either. 

Does running the audio through the transcoding engine reset the marker bit? I didn't find an option to force transcoding when both legs of the call use the same codec. 

Is there any other way to let rtpengine reset the marker bit?

[Lewis Hutchinson]

We pushed this back to the PSTN provider. Not sure what other equipment you have in the call flow but there is quite alot of things in FreeSWITCH to handle 'Marker Bits' in various scenarios which we had limited success with but was not able to continually resolve this. 

Lewis 

---

From: rtpe...@googlegroups.com <rtpe...@googlegroups.com> on behalf of Ahmed <mouba...@gmail.com>
Sent: 13 October 2022 14:51
To: rtpengine <rtpe...@googlegroups.com>
Subject: Re: One Way Audio - Continues Marker bit

 

--
You received this message because you are subscribed to a topic in the Google Groups "rtpengine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtpengine/_aWesG6Yz_U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/74aa0e21-820c-4f67-a9c0-ffac56f61a62n%40googlegroups.com.

[Ahmed]

Hi Lewis,

Thanks for taking the time to reply, I was really hoping to resolve this on rtpengine instead of adding another hop.

What about Richard's original suggestion of running the audio through the transcoding engine? Is it possible to do that when both legs of the call are already using the same codec? Did it do anything with the marker bits?

Hi Richard,

If there's any other advice you can offer about resetting the marker bits or force engaging the transcoding engine when both endpoints agree on the codec it would be very much appreciated. Thanks!

[Lewis Hutchinson]

Morning Ahmed

I tried that also but no matter what I did I could not get every call to 

- clean marker bits

- ignore and play

- play audio without adverse effects

There was always something wrong with about 75% of the calls with the continuous marker bit sent from the PSTN. 

In my case there was multiple anchor points for the audio and attempting to clean it up in one or an all places using a variety of methods including transcoding wasn't successful enough for a production environment.

Our case was very specific to an obscure international mobile provider over a certain interconnect so we went up the chain to have it resolved that way. 

Sorry I couldn't help further but if you do find anything please let me know. 

Lewis

---

From: rtpe...@googlegroups.com <rtpe...@googlegroups.com> on behalf of Ahmed <mouba...@gmail.com>

Sent: Thursday, October 13, 2022 5:10:11 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/300ef8ee-0913-4c0f-b407-44309b2088d8n%40googlegroups.com.

[Lewis]

Hi Ahmed

it took some time but the carrier acknowledged this fault on their side.

Hope that is of use to you.