| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
I am using librepro.so for a custom proxy project. Repro Proxy itself is just an application wrapper on top of librepro. Being a proxy, I do not think repro would also be the entire solution to what you are trying to achieve. I am assuming that you want media to be peer to peer after the announcement has been played? If so I recommend the following setup. Use an announcement server to play the initial early media. Freeswitch comes to mind here.
UAC -> Repro -> Announcement Server.
Configure repro to handle redirects locally. After your announcement has been played, issue a redirect to the correct destination
F1. UAC INVITE -> Repro -> AS
F2. AS -> 183 (early media) -> UAC
F3. AS -----> Play announcement -----> UAC
F4. AS -> 302 Redirect -> Repro (handles redirect locally)
F5. Repro forks INVITE -> UAS
F6. UAS -> 200 Ok with new media -> Repro -> UAC
F7. UAC -----------------> Updated media flow ------------> UAS
-joegen
On 02/19/2014 09:01 AM, leung terry wrote:
Hi Scott,
Thanks for your answerHowever, my flow involve having some kind of early media for playing some announcement before connecting the call to the real callee.And it may involves other kind of logic that I want to implement separately.
To my understanding, repro is a standalone sip proxy, but not a set of api, am I correct?How can I define my own flow there? just by configuration or by changing its code?Also, does it
Thanks!Best Regards,Terry
On Tue, Feb 18, 2014 at 10:14 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
I think you are probably going down the wrong path here. Sounds like what you want to create is pretty much SIP proxy functionality. In that case, I would avoid using DUM or ichat-gw altogether (unless you really want a B2BUA) and take a look at using repro (SIP proxy) as your starting ground. There is already logic in repro to forward/fork requests and to gather their responses for sending back to the request originator.
Regards,Scott
On Tue, Feb 18, 2014 at 3:19 AM, leung terry <terryleung83@xxxxxxxxx> wrote:
_______________________________________________Hi all,
I am new to here. I am now reading the document and code.I am going to have a new project which involves forking an incoming request.It is not supposed to be a B2BUA. The incoming and outgoing invite should have the same To/From/Call-Id.
I tried to read the ichat-gw included in the source code. However, it is actually a B2BUA case and I cannot find any example doing proxy by using dum layer api or forking incoming invite.
My question, for such case, I should have 3 Session object per call?I am not sure if I am correct or not. I just put my understanding based on the ichat-gw I read and I think I should do the following modification in order to made it work for my case.
When I receive the first invite, I should receive onNewSession and then onOffer in the B2BSession.Then I should now create two peer by creating two more B2BSession(createNewPeer in ichat-gw) and run mDum.makeInviteSession with the use of the incoming message with the use of another overloaded version
SharedPtr<SipMessage> makeInviteSession(const NameAddr& target, InviteSessionHandle sessionToReplace, const SharedPtr<UserProfile>& userProfile, const Contents* initialOffer, AppDialogSet* ads = 0);
I should change the RURI/Route header/.... accordingly in the two different makeInviteSession
Am I correct?
Best Regards,Terry
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
_______________________________________________ resiprocate-users mailing list resiprocate-users@xxxxxxxxxxxxxxx List Archive: http://list.resiprocate.org/archive/resiprocate-users/