..

HAIRPINNING sip rtp audio - experiencing high latency audio

..

Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic PowerMedia HMP GlobalCall and R4 API

HAIRPINNING sip rtp audio - experiencing high latency audio

  • When hairpinning audio  (HMP3.0 SU349 - G.711@pime=20) between separate SIP calls, I am noticing approximately 100 to 200 milliseconds delay/latency in the hairpinned audio in both directions.

    My app places two outbound calls and hairpins the two calls audio using gc_Listen()

    Question - what would be the expected normal latency on HMP between receiving an RTP packet on one call  and sending the packet on a second call when the two calls are hairpinned using gc_listen()?

  • Hi,

    I don't know about the expected latency, but I do know that the latency is indeed noticeable. We had an installation where, because os some crazy routing requirements, the calls had 4 legs in our system instead of 2. In that case the delay was really noticeable.

    The situation improved considerably after we used "Receive only RFC 2833 mode".

    Please check "13.2.5 Setting Receive-only RFC 2833 Mode" in the ip_media_api documentation.

    Chris

  • Indeed an interesting question which comes up time to time. Also note there may be improvements for this in later SU as opposed to build from 5+ years ago. (349 released Jan 2014).

    Overall, there are a lot of variables at play here to amount network traffic being processed at the network adapter level of the system (or OS level processing), even before it get up to HMP level. In that case, if you are only using the xx_listen APs, then there will be transcoding done on the inbound and outbound streams since the G711 is decoded to linear on the virtual TDM bus and encoded back to G711 on the way out.

    You may be better off switching to faster method, that being dev_portconnect and NATIVE mode for the IPM streams, that way no processing is done (ie decode/encode) and what RTP packets come in get directly shipped back out the other IPM channel connect.

    Unfortunately I don't have exact metrics for relay of data in a hairpin call. How exactly were you taking the measurement in this case? Was it from wireshark trace of some other means. I know typically people have tried to bounce a DTMF off the system, but then that may involve delay

    as well if using RFC2833 vs that of inband DTMF due to difference in processing.

    Regards,

    Jeff

  • Thanks for the reply Jeff,

    I used wireshark for the measurement.

    To switch to native with no transcoding:

    Would it be as simple as replacing the gc_Listen(linedev_a, timeslot_b) and gc_Listen(linedev_b, timeslot_a) with dev_PortConnect(ipmdev_a, ,,,) and dev_PortConnect(ipmdev_b,...) as well as replacing the corresponding gc_UnListen()'s with dev_PortDisconnect()'s (with event handling as needed for the dev_ functions)?