== D-Series Cards == D-Series cards contain special media processors (the so-called modules). D100 for example, has one of this modules internally. D-500 can contain up to 5 of this media processors (modules). Each of this media processors have also an ethernet interface to receive commands and send responses or IP traffic (for example the actual RTP media). Those internal ethernet interfaces are not directly visible to the operating system. The D-Series cards expose a special gateway ethernet interface to access the network of media processors that are embedded in the card. Effectively each media processor can be seen as an independent computer with a separate IP address, it just happens to be embedded inside the D-Series card. The ethernet interface seen by the operating system (eth9 in this example) is internally connected via ethernet to those media modules. ---------------------------------- | | D100 | ------------ ---------------------------- | eth9 | | media module #1 | | | ----------------| w/ ethernet (10.1.1.150) | | 10.1.1.1 | ---------------------------- ------------ | | | | | --------------------------------- ---------------------------------- --------------------------- | --------------|media module #1 | | | | w/ ethernet (10.1.1.150)| D500 | | --------------------------- ------------ | --------------------------- | eth9 | | |media module #2 | | |------------------------------| w/ ethernet (10.1.1.151)| | 10.1.1.1 | | --------------------------- ------------ | --------------------------- | --------------|media module #3 | | | | w/ethernet (10.1.1.152) | | | --------------------------- | | --------------------------- | | | media module #4 | ---------------------------------- |-------------| w/ethernet (10.1.1.153) | --------------------------- == Transcoding Sessions in the D-Series == From the D-Series card point of view, a transcoding session is defined as 2 RTP streams bridged together where one RTP stream uses a different codec that the other and therefore the media module needs to transcode the media in both directions. The following diagram shows what the D-Series card understands as transcoding session. -------------- -------------------------------- ------------- | SIP UA #1 | ---------- PCMU RTP (tx/rx)------| media module #1 (10.1.1.150) | ------------ G729 (tx/rx) --------| SIP UA #2 | -------------- -------------------------------- ------------- There is audio flowing in both directions, therefore this is what is known as a 2-legged call. Roughly speaking, a single media module can handle around 400 sessions of transcoding. However, there is no fixed number. The capacity will depend on the codecs being used across sessions (some codecs require more processing power than others). == Transcoding Sessions in Asterisk == The current design of the codec interface for Asterisk is assuming the media will flow through Asterisk, because by definition in order to Asterisk to perform transcoding it needs to receive the media to transcode. As shown in the previous section, the D-Series media modules can send and receive RTP directly to/from the SIP UA (or any other RTP capable device). In order to adapt the D-Series card to the codec interface exposed by Asterisk, the RTP (or any other non-RTP media) must be received by Asterisk first, then Asterisk provides raw media to codec_sangoma.so interface module which then packs the media in RTP and send it to the D-Series card and receives the RTP coming from the card and delivers the raw media (without RTP headers) back to the Asterisk core (which in turn may end up packing the media into RTP again). -------------- -------------------------------- ------------- | SIP UA #1 | ---------- PCMU RTP (tx/rx)------| Asterisk (192.168.1.100) | ------------ G729 (tx/rx) --------| SIP UA #2 | -------------- -------------------------------- ------------- | | | | PCMU RTP (tx/rx) G729 RTP (tx/rx) | | -------------------------------- | media module #1 (10.1.1.150) | -------------------------------- In Asterisk terms, a transcoding session is a unidirectional codec conversion. For example, going from ulaw to g729, in that direction only. The library libsngtc-node needs to play some tricks in order to accomodate as many Asterisk transcoding sessions as possible within the D-Series card. When Asterisk requests a transcoding session from PCMU to G729, the hardware really creates a bidireccional transcoding session (both from PCMU to G729 and from G729 to PCMU). However one direction remains unused until Asterisk requests the other direction (G729 to PCMU), it may not request it ever, depending on call conditions. The command "sangoma show transcoding sessions" will display the unidirectional transcoding sessions requested by Asterisk. However, seeing 2 transcoding sessions like: ulaw -> g729 g729 -> ulaw It might be only using one transcoding session as far as the D-series card is concerned. == SOAP == TODO == Licensing == TODO