Also asterisk is a B2BUA, so if calls are delivered to the B side by asterisk, the B side will see call coming from the Asterisks, not from the Kamailio.
On Mon, Oct 8, 2018, 15:54 Alex Balashov <[email protected]> wrote: > On Mon, Oct 08, 2018 at 02:35:54PM +0200, Daniel Tryba wrote: > > > On Mon, Oct 08, 2018 at 07:16:43AM -0400, Alex Balashov wrote: > > > The SDP-bearing INVITE and response are simply passed along as-is by > > > Kamailio, and it is the SDP which specifies where the media goes. So, > if > > > endpoint A calls through Kamailio proxy B to Asterisk server C via SIP, > > > A and C will negotiate media amongst themselves without any > intervention > > > or special measures on your part whatsoever. > > > > In theory, but with Asterisk in the middle be prepared to have this fail > > since it initially is in the loop regarding RTP and can negotiate > > incompatible RTP legs between AB and BC which will not be fixed when > > Asterisk leaves the RTP path. Mainly I experience this with > > dtmf/telephone-events mapping, e.g.: a=rtpmap:101 telephone-event/8000 > > If a and c have different values, dtmf will fail. > > Well, yes, all kinds of interesting things can happen in the bridging > process. But in principle, at least, it is possible to bridge RTP across > two call legs without such issues. :-) > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
