What causes empty RTP packets

25 pts.
Tags:
empty RTP payload
In several enterprise projects I have seen in one direction RTP streams with empty RTP payload, i.e. $55 values only from the beginning instead of real audio. This happens a few times a week, while hundreds of calls show bidirectional audio. To me there seems to be no systematical schema - incoming as well as outgoing calls (call initiation) are affected - the empty RTP streams sometimes are directed from the enterprise customer to the carrier - sometimes in the reverse direction - apparently never in both directions. Furthermore it doesn't matter, what kind of external user is involved (mobile phone or wireline users). As far as the SIP signalling is concerned I (hopefully) have checked everything thats relevant (port# for media traffic are OK, senrecv parameter is OK). Such calls usually last between 20 .. 40 seconds, as the other party ('hallo ?') will give up soon and terminate the call.
Would be great, if anyone can give me a hint ... thx in advance !


Software/Hardware used:
VoIP (SIP) calls, RTP protocol
0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • carlosdl
    You didn't explain what the real problem is.

    An empty RTP packet is not really the problem, I suppose, but rather what you think is the cause of "the problem".  So, what is the problem?  Dropped calls? Mute calls? something else?
    86,030 pointsBadges:
    report
  • Fossilero
    thx for your response. To make the case clearer (sorry if I failed to do so before): users do complain aboute calls w/o any audio in one direction (permanently in mute state). Sometimes the external user (located somewhere in the carrier cloud - i.e. the incoming direction) is muted, sometimes the internal user (in the enterprise - the outgoing direction).
    My first guess was, that sth. within the SIP signalling process went wrong, but I have compared every tiny detail in the SIP requests / responses w/ regular calls (bidirectional audio) - it's absolutely identical.
    25 pointsBadges:
    report
  • ToddN2000
    What hardware is being used on your end and how is it configured?
    136,960 pointsBadges:
    report
  • Fossilero
    the HW really depends on the project. In this case it's a VM-Ware running a virtual SBC (OpenScape). As this belongs to the customer, I don't have access to it's config. All I know is from the measurement data (10 days of complete traces), that SIP runs on UDP. My hope was / is, that the solution can be found within the data. Even more confusing - there are such one-way calls and regular calls (w/ bidirectional audio) - looking both the same in terms of signalling (incl. every tiny detail). If you have an idea, it would be highly welcome ...
    25 pointsBadges:
    report
  • carlosdl
    Most one-way audio problems I have seen are related to RTP routing and/or firewalls, but if you do see that RTP packets are arriving at the destination, but they have an empty payload, then I would discard that.

    Have you reviewed the list of supported codecs mentioned in the SIP negotiation phase?  Are they always the same both in successful and one-way audio calls?

    Also, are some (or all) of those calls passing through some kind of equipment that could need to decode and re-encode the audio streams?

    Other than that, I can only think that the end devices are sometimes really failing to capture the audio signal, but that seems a little unlikely if you see the problem happening on calls from very different devices and networks.
    86,030 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: