David J. wrote:
Stefan, Sorry for all the trouble;
So I finally got it to work in xlite and a PAP2 ATA.
(I initiated the call from blink and had it ring xlite and ATA, I had
one way audio on the blink client, so I reversed the test and dialed
from xlite and it rang blink and PAP2, I answered the call on the PAP2
and it worked, Audio both ways.)
i
I made some modifications, like adding a domain column to the database
so we can fork to other destinations outside the domain as well, that
was and easy and obvious enhancement.
if you like, you can send a git format-patch or so to the list (semsdev).
I wish I would understand how to write this from scratch.
I'd suggest to re-read the DSM tutorial(s) and the other files in
doc/dsm. this is also not one of the simplest examples to start with.
a simpler service that does not involve early media, multiple calls
and so on, would probably be a better place to start.
but, in fact I think it is not so complicated. A script is composed of
1. comments (starting with --)
2. imports (import mod_name)
3. state definitions
4. definitions of transition between the states.
you have one initial state which the DSM jumps to when the call starts.
Then, events are processed. You have got call related events (hangup,
hold, unhold); dtmf (key), audio (noAudio, playlist separator), etc.
If an event is processed, all transitions are checked, the first one
where all conditions match is executed. when a transition is executed,
all transition actions are executed.
states have enter and exit actions; enter actions are executed when a
state is entered, exit actions when a state is left.
you have variables, accessed with $name. you have event parameters,
accessed with #name. you have selects, which are properties of the
call, accessed with @name.
you have modules which implement specific actions and conditions.
that's all.
Couldn't this also be done in Python as well?
I have spend already too much of my life-time trying to get embedded
python interpreter leak- and crash-free, probably mostly caused by my
own stupidity.
besides that, embedded python is
- much much slower
- consumes much more memory
- difficult to debug
- difficult to profile for mem leak
- has the GIL, so you won't get much more performance out of multi
core servers, at least for signaling intensive applications.
contrasting to that, with DSM is
- very fast
- consumes little memory overhead
- clear to understand what happens when in your call
- a direct representation of call/service state diagram, something you
will probably do anyway while inventing your service
- best integrated with all the other capabilities of the sems core
- helping you very much in production with live script reload and
monitoring capabilities
- can be instrumented best
- can run checks like "handling bye everywhere"
- eventually will provide the means to do active calls replication
Is DSM just a more robust way of doing it?
having said that, you can use mod_py to embed python code into your
DSM script (even though iirc i am not convinced this is 100% stable on
high load).
Stefan
On 8/24/10 12:34 PM, Stefan Sayer wrote:
you need to look further up, where the SDP negotiation takes place.
the problem is that RTP dtmf is sent as ID 96, but it is apparently
not included in the SDP as supported payload as it should be. is this
blink? possibly we need to tell this to the blink devs. therefore, can
you send an ngrep of the full call flow to the blink?
stefan
David J. wrote:
[#4046d950/27306] [~AmSipDialog, AmSipDialog.cpp:52] DEBUG: callid
= [email protected]
[#4046d950/27306] [~AmSipDialog, AmSipDialog.cpp:53] DEBUG:
local_tag = 68580430-4C73F2AC000C3110-4132F950
[#4046d950/27306] [~AmSipDialog, AmSipDialog.cpp:54] DEBUG:
uac_trans.size() = 0
[#4046d950/27306] [~AmSipDialog, AmSipDialog.cpp:62] DEBUG:
uas_trans.size() = 0
[#4046d950/27306] [run, AmSessionContainer.cpp:134] DEBUG: Session
cleaner finished
[#4196d950/27307] [conceal_loss, AmRtpAudio.cpp:182] DEBUG: default
PLC (ts_diff = 160; s = 320)
[#4196d950/27307] [read, AmAudioFile.cpp:409] DEBUG: 0-stuffing
packet: adding 260 bytes (packet size=320)
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [get, AmPlaylist.cpp:78] DEBUG: get: gotoNextItem
[#4196d950/27307] [gotoNextItem, AmPlaylist.cpp:62] DEBUG: posting
AmAudioEvent::noAudio event!
[#4196d950/27307] [postEvent, AmEventQueue.cpp:53] DEBUG:
AmEventQueue: trying to post event
[#4196d950/27307] [postEvent, AmEventQueue.cpp:64] DEBUG:
AmEventQueue: event posted
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#40ae9950/27319] [processEvents, AmEventQueue.cpp:79] DEBUG: before
processing event (12AmAudioEvent)
[#40ae9950/27319] [runEvent, DSMStateEngine.cpp:342] DEBUG: checking
transition 'got cancel from A leg'
[#40ae9950/27319] [runEvent, DSMStateEngine.cpp:342] DEBUG: checking
transition 'pressed a number'
[#40ae9950/27319] [runEvent, DSMStateEngine.cpp:342] DEBUG: checking
transition 'pressed hash or start'
[#40ae9950/27319] [processEvents, AmEventQueue.cpp:83] DEBUG: event
processed (12AmAudioEvent)
[#40ae9950/27319] [processingCycle, AmSession.cpp:446] DEBUG:
[email protected]/7F742D34-4C73F2AC000C7F30-4132F950:
Connected, running, 0 UACTransPending
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [setCurrentPayload, AmAudio.cpp:71] ERROR: Could
not find payload <96>
[#4196d950/27307] [read, AmAudioFile.cpp:409] DEBUG: 0-stuffing
packet: adding 260 bytes (packet size=320)
On 8/24/10 12:21 PM, Stefan Sayer wrote:
-D 3
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
