RE: [reSIProcate] re: B2BUA devel qs
Hello again
ppl,
Starting to
build the B2BUA.
Quite some
code browsing so far.
As I had
mentioned, I am building a B2BUA.
So, again
delving a lil deeper into the flow :
User A
---> reSIProcate ----> UAS -----> UAC -----> reSIProcate ---->
User B.
Now in the
UAC, if I am not mistaken, I create a new invite to send to user
B.
The problem
is, with the INVITE containing sdp content, on a 200 OK from user B, UAC
immediately sends an ACK.(ClientInviteSession.cxx : line
626).
Wot i want is
to forward the 200 OK back to the UAS, and then onto User A. The User A would
then send the UAS an ACK which would be forwarded to UAC and then onto User
B.
Looking at
the code it seems, to not have the ACK sent, the INVITE sent to User B should
not contain the sdp content.????
Is there
anyway, I can stop those ACKs being sent to User B until i get an ACK from
user A??
Also, another
problem in immediately sending an ACK to User B, is that User B would think that
the call is established, even tho the 200 OK hasnt yet reached User
A.
Any
pointers?
Thanks
Ben.
Thanks
David.
This should
help alrite :-)
Ben.
Ben,
I've
been doing a bit of research as I've had to put a B2BUA together fairly
quickly. While there is no direct samples that I could find, here is a basic
structure that is working for me: (classes are simplified and displayed
inline for brevity)
Basically it is one B2bService class
which inherits InviteSessionHandler and one PairAgent class
which also inherits InviteSessionHandler
The trick is
when you first get your onNewSession from the inbound, you create your
invite for the outbound, then you immediately bind these two together by
passing the pointer of one to the other.
Then you add the callID and the agents to a module level Hash map
so that any future events that the main B2bService gets can easily be
delegated to the proper agent (which will always know his pair to sync the
events).
You then either tap into the state properties of the
dialog or keep your own state machine and use these to properly sync
events to your agent pair.
As for expensive items like
billing or logging, I am looking at creating a Fifo or other async method to
handle so blocking does not occur.
Hope this helps, and good
luck.
David
class
B2bService : public
InviteSessionHandler
{
public:
B2bService(const
resip::Data& host, int port)
:
mStack(),
mStackThread(mStack),
mDum(mStack),
mDumThread(mDum),
{
mStack.addTransport(UDP,
port);
SharedPtr<MasterProfile> profile(new
MasterProfile);
auto_ptr<ClientAuthManager> clientAuth(new
ClientAuthManager);
mDum.setClientAuthManager(clientAuth);
mDum.setMasterProfile(profile);
mDum.setInviteSessionHandler(this);
mStackThread.run();
mDumThread.run();
}
virtual
~B2bService()
{
mStackThread.shutdown();
mStackThread.join();
mStack.shutdown();
mDumThread.shutdown();
mDumThread.join();
}
virtual
void onNewSession(ServerInviteSessionHandle h,
InviteSession::OfferAnswerType oat, const
SipMessage& msg)
{
//authenticates the
origination
//validates a termination
point
//creates the invite for the termination:
//ie:
//
SdpContents* sdp = dynamic_cast<SdpContents*>(msg.getContents());
// SharedPtr<SipMessage>
invite(mDum.makeInviteSession(NameAddr(target), sdp));
// mDum.send(invite);
// now
that you have the call id's from both the origination and termination agents
you can add them to the hashmap
//ie:
mAgents[Data(h->getCallId())] = new PairedAgent();
mAgents[Data(invite->header(h_CallID).value()] =
new PairedAgent();
//swap references
between agents to "bind" them together;
// ie: inboundAgent->linkAgent(outboundAgent);
outboundAgent->linkAgent(inboundAgent);
//creates two PairedAgent object and adds them to the mAgents
HashMap
}
virtual void AllOtherInviteSessionHandlerMethods(InvitesessionHandler
h)
{
HashMap<resip::Data, PairedAgent*>::iterator i =
mAgents.find(h->getCallID);
if (i != mAgents.end())
{
return
i->second->SameInviteSessionHandlerMethod(h);
}
}
private:
SipStack
mStack;
StackThread
mStackThread;
DialogUsageManager
mDum;
DumThread
mDumThread;
HashMap<resip::Data, PairedAgent*>
mAgents;
}
class PairedAgent :
public InviteSessionHandler
{
public:
virtual
void onNewSession(ServerInviteSessionHandle h,
InviteSession::OfferAnswerType oat, const
SipMessage& msg)
{
mAppDialog =
h->getAppDialog();
}
virtual
void onNewSession(ClientInviteSessionHandle h,
InviteSession::OfferAnswerType oat, const
SipMessage& msg)
{
mAppDialog =
h->getAppDialog();
}
virtual
void onOffer(InviteSessionHandle h, const
SipMessage& msg, const SdpContents&
offer)
{
mLinked->provideOfferToPair(offer);
}
virtual void provideOfferToPair(const resip::SdpContents&
sdp)
{
mAppDialog->getInviteSession()->provideOffer(sdp);
}
private:
PairedAgent* mLinked;
AppDialogHandle
mAppDialog;
}
Ben
wrote:
Hello ppl,
I am building a B2BUA using
reSIProcate and DUM.
Please be patient and verryy forgiving if I this is
the wrong place for the
questions below.
Ofcourse tel me abt the
correct link too :)
Ok.. Ive been reading the reSIP and DUM docs,
whatever's available on wiki n
elsewhere.
At a real huge height, my
idea of a B2BUA wud be something like this :
RESIP
<---> DUM <----> Application(Voicemail, Billing,
etc)
My qs:
It seems the Application is responsible for
informing the reSIP stack to
start listening on 5060.
So all messages
coming on 5060 wud be passed onto the application and
courtesy DUM, you
would get wot kinda message is it, and for which dialog,
for e.g. a 180
for a previous INVITE n so on(the onAnswer, or onOffer, etc
callbacks).
So, duz it mean, all this will happen serially?
Won't that hamper the
performance?
How do I fork off the service(for e.g. an INVITE in case of
a billing
service) to the billing application, and that decides whether
to call the
callee, or play a file to the caller, etc.
If it happens
serialy, and I need to contact a database to check the
caller's billing
details, wont the other calls be blocked till that time?
All help
greatly appreciated.
Also, any links where a few examples have been
implemented(all as one entire
package, instead of individual executables
in the tarball)??.
Cheers.
Ben.
Express yourself instantly with Windows Live Messenger