Hi Stefan, Your points are valid. One can actually use SEMS in signalling only B2B mode and can use something like RTP-Proxy or Media Proxy for media IP hiding. But the drawback here comes when it is needed to maintain different applications. In other words, if I plan to have a redundant environment, RTP Proxy would be another point of failure along with SIP-Proxy server and SEMS. So if SEMS is able to do the media forwarding along with signalling, I can eliminate RTP-Proxy altogether.
--- Jayesh On Tue, Apr 6, 2010 at 3:31 PM, Stefan Sayer <[email protected]>wrote: > Jeremya wrote: > >> Stefan Sayer wrote: >> >>> Hello Jayesh, >>> >>> Jayesh Nambiar wrote: >>> >>>> Hi, >>>> I intend to test SEMS 1.2 starting with the b2b_connect application. >>>> It works well but the only issue is that in the second leg, it sends >>>> out only the enabled codec plugins. >>>> Is it possible somehow to make sems work in transparent codec mode, >>>> where it just forwards the codec value as it is and does not try to >>>> transcode?? The aim is to send G729 in pass-through mode !! >>>> >>> in SEMS 1.2 there is only applications with signaling only B2BUA >>> (call_timer, auh_b2b, sw_prepaid_sip etc) and applications with full >>> media decode/encode, there is no pass-through mode in SEMS yet. >>> What do you want to use the B2B for? You could use one of the >>> signaling only B2B applications in SEMS in combination with one of the >>> RTP relay solutions for SER-based proxies >>> (kamailio/sip-router+iptrtpproxy, opensips+mediaproxy2, >>> k/sip-router/os + rtpproxy/mediaproxy), if you need to force RTP >>> through that server. >>> >>> I have been thinking about an RTP forwarding mode for the B2B for a >>> while, but haven't had the actual need for it. If there is interest, I >>> think it would not be particularly large implementation task, as all >>> the necessary components are already there. >>> >>> >> >> I read the original post and I assumed the OP wanted pass-through so >> proprietary codecs could work. SEMS does not support G729, so a >> pass-through option is the only choice. >> >> I realise SEMS is a media server but I think a design goal should be >> that it does the minimum with the media stream - simply for efficiency. >> In the B2B mode pass-through should be default unless there is a >> transcoding requirement. I realise this is relatively difficult as the >> B2B code must determine if there are compatible codecs or if it is >> required to do a transcode. >> >> The use of external RTP proxies requires SEMS to figure out the >> requirements and then somehow instruct the RTP proxy to do the correct >> transcode. I'm not sure this works easily at present. >> > i was thinking about the possibility to have the call go through a proxy > which just engages RTP relay for every call. > > >> The simplest solution is for different SEMS applications - or different >> parameters for SEMS applications - to allow pass-through as an option. >> e.g. "transcode=no" >> > right (or: relay_rtp=yes). > > I was asking what the B2B is used for, because I would usually like to see > it at another level of "optimizing for efficiency": If it is possible, the > RTP should be flowing end to end and the B2B should not need to touch it > (e.g. for topology hiding, identity change, call timer etc; or after > pre-call announcements or similar applications). The RTP should flow through > the B2B only if needed, for example something will be played into the stream > (like, a tone shortly before the prepaid card is empty), and in that case it > needs to decode/encode, or at least it needs to support the codecs. > > The only other use of RTP pass through where it would make sense for me is > to catch RTP time out and for NAT handling, and on the border of the > network. For catching RTP time out, that feature definitely would make > sense. On the border of the network, I would usually recommend a proxy > anyway, possibly behind a SEMS working as topo hiding B2B; as SEMS currently > does not support multi homing, you would need a proxy in that situation > anyway. > > So, in conclusion, there is interest? > > Regards > Stefan > > _______________________________________________ >> Sems mailing list >> [email protected] >> http://lists.iptel.org/mailman/listinfo/sems >> >> > > -- > Stefan Sayer > VoIP Services Consulting and Development > > Warschauer Str. 24 > 10243 Berlin > > tel:+491621366449 > sip:[email protected] <sip%[email protected]> > email/xmpp:[email protected] <xmpp%[email protected]> > > > _______________________________________________ > Sems mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/sems >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
