Issue Details (XML | Word | Printable)

Key: XMR-105
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Chemeris
Reporter: Soledad Alborno
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
sipXtapi: sipXmediaLib

I get one way audio when a 183 or 180 (ringing) message arrives

Created: 2008-04-07 15:39   Updated: 2008-04-17 16:19
Component/s: sipXmediaLib
Affects Version/s: 2.9
Fix Version/s: None

File Attachments: 1. Text File oneWayaudio.patch (0.7 kB)
2. File other fix.diff (0.6 kB)

Environment: windows xp, build with visual studio 2003


 Description  « Hide
The problem:
We are using the SipXtapi lib to dial-out to a SIP-to-PSTN gateway. During the setup of the call we're receiving a 183+SDP from the gateway. This enables us to listen to the dial-tone. (the one you usually hear before somebody picks up the phone). This dial tone is generated by the gateway (or somewhere further up in the network). After the 183+SDP we're correctly receiving and sending media. After a few seconds we receive a 180(RINGING) and the media is still being send and received. When the call is answered on the PSTN side we're receiving a 200+SDP. All goes well so far, but imediately after receiving the 200+SDP the SipX library stops sending media to the gateway.

Simplified schematic drawing:

    A B
0.0s INVITE
    ----------------->
0.1s 100(TRYING)
    <-----------------
0.1s 183 + SDP
    <-----------------

          MEDIA
    <----------------> //both ways (silence from gw-side)

3.0s 180(RINGING)
    <-----------------

          MEDIA
    <----------------> //both ways (dial tone from gw-side)

        200 + SDP
5.0s <-----------------
           ACK
5.1s ----------------->

5.1s MEDIA
    <----------------- //one way (audio from PSTN)


A = SipX client
B = SIP-to-PSTN gateway

We noticed this behavior when using the PlaceCall sample application.

The analysis:
When the 200 + SDP message is received by the voice client, SipXCallLib executes the method SipConnection::processInviteResponseNormal, then the MpRtpOutputAudioConnection::handleStopSendRtp method is called (from MpCallFlowGraph) to stop the channel that is reproducing the ring tone. And then the method MpRtpOutputAudioConnection::handleStartSendRtp is called in order to start the outgoing audio channel which must send audio to the other endpoint.

The problem is that MpRtpOutputAudioConnection::handleStopSendRtp is adding to the queue a message to deselect codecs and MpRtpOutputAudioConnection::handleStartSendRtp does not put a message in the queue, instead it calls to the handler function directly



The solution:
in file sipXmediaLib\src\mp\MpRtpOutputAudioConnection.cpp in the method handleStartSendRtp delete ln 233 and 234 (written below)
      SdpCodec* codecs[] = {pPrimaryCodec, pDtmfCodec};
      mpEncode->handleSelectCodecs(sizeof(codecs)/sizeof(SdpCodec*), codecs);
And add a line to enqueue the message to the encoder
      mpEncode->selectCodecs(pPrimaryCodec, pDtmfCodec);



PS:

I don't know if these 2.9 is the real version, I've checked out the code from: http://scm.sipfoundry.org/rep/sipX/branches/sipXtapi/
and in a log from PlaceCall I've found: sipXtapi SDK 2.9.1.0 Rls (built 0000-00-00)

This is the first time I works with SipX so maybe something is wrong on the description of the solution. Please tell me if something is wrong.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Alexander Chemeris added a comment - 2008-04-08 18:48
Could you try this fix instead?
It should be better, because it avoids a one frame delay in in selectCodecs/deselectCodecs processing.

Soledad Alborno added a comment - 2008-04-09 08:15
I've tried the fix,
I think it has more performance, I think that setting up a queue for three kinds of messages is not the best approach, maybe the best option is removing the queues in the Encoder and Decoder for future releases.

Thanks
Soledad

Alexander Chemeris added a comment - 2008-04-09 14:44
Sorry, I'm not sure I understood you fully. Does my version works for you? I guess yes, but for sure...

What about removing queues for Encoder and Decoder - it more then just performance/latency question. It is more of design. This part of code needs some shaping I haven't done yet. Idea of input and output RTP connections should be expressed slightly diffrent in code.

Soledad Alborno added a comment - 2008-04-09 15:16
I'm sorry; I will explain myself a bit more.

Your fix does work for me. It has the same result than the fix I've published before.

The new fix has more performance that the old one, but my fix was following the architecture principle :).

When I've told you about removing the queues, I was talking about the queue that the encoder is using for handling the events: SELECT_CODECS, DESELECT_CODECS, START_TONE, STOP_TONE, etc.
I can not see why decoder and encoder are using a queue of messages. Using queues decreases the performance, I understand that it is a design decision but I don't think that it worth to use queues in this case. But it is just a point of view.

BTW, where can I find SipXcallLib documentation? Is there Doxygen documentation or something to make it easier to understand the modules?

Thanks,
Sole



Alexander Chemeris added a comment - 2008-04-12 07:32

Well, using queues in sipXmediaLib is a performance benefit actually. :) Queues allows us to do audio frame processing without any interruption and (sic!) calls to synchronization functions. So incoming requests are processed only when inbetween frame processing. This also save us from handling crazy problems with flowgraph topology changes during audio processing. But for decoder/encoder there is a subtle difference - they're part of other resource, which actually handles queued requests. I'm not happy with this situation and hope to change it once I have spare time - no resources should contain other resources, this breaks design principle and introduce a lot of headache and problems like one we have here.

Alexander Chemeris added a comment - 2008-04-12 07:35
As for sipXcallLib documentation - yes, there are some Doxygen-style docs in headers. But I personally have not compiled it with Doxygen for a long time - I just read it raw in sources :)

Alexander Chemeris added a comment - 2008-04-14 09:26
Finally fixed in rev 10632 of sipXtapi branch:
http://scm.sipfoundry.org/viewsvn/sipX?view=rev&rev=10632

Alexander Chemeris added a comment - 2008-04-17 16:19
Ok. Now really finally fixed.
Count rev.10638 and rev.10640 commits.