Alex Balashov wrote:
Raphael Coeffic wrote:
Alex Balashov wrote:
Stefan,
Stefan Sayer wrote:
Hi,
o Alex Balashov [11/17/2009 01:17 PM]:
Greetings,
Having not taken the time to extensively familiarise myself with
the Python and C++ APIs, I am curious as to whether it is possible
to use SEMS for pure (signaling-only) B2BUA functionality without
involving myself in a great deal of complex work.
The problem is that both of the pre-built applications that have
this effect - early_announce and ann_b2b - are constructed on the
premise that I wish to play some sort of audio prior to forwarding
the call. I do not want to play audio, I just want to forward the
call and have SEMS continue to stay in the call path.
have a look at sw_prepaid_sip.
This may also be possible by using b2b functions in INVITE event in
DSM, but we need to try it out and have a look into that, maybe
there needs to be some additional things done.
Perhaps the easiest thing to do is to simply copy ann_b2b, rename
it, and hack out the announcement-related bits out of AnnounceB2B.cpp?
I would say that it depends on your call-flows. Without these, we can
hardly discuss about what is possible or not. If you want a
transparent B2BUA, you will get it with SEMS and very few lines of
code. But if you want to do nasty things with the signaling, you
might have to read a lot of C++ code in the core.
Maybe you could share you intended call flows, and we could help you
much better.
I just want as transparent a B2BUA as possible, for the purpose of
establishing dialogs via INVITE transactions solely.
No funny signaling manipulation, no remapping of reply codes, no
special stateful chicanery.
Then I would say that your idea with the slated ann_b2b example might
work properly, if you remove anything related to audio and the 183 reply.
-Raphael.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
