8 Oct
2018
8 Oct
'18
6:33 p.m.
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 <abalashov(a)evaristesys.com> wrote:
On Mon, Oct 08, 2018 at 02:35:54PM +0200, Daniel Tryba
wrote:
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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.