Update : I piggy backed Freeswitch to Kamailio and have resolved the issue. No
media touching us now. Pros and Cons for doing that I know. But we have it
working.
Thanks for the dialog.
KD
On Wednesday, May 9, 2018, 8:57:49 PM EDT, KamDev Essa
wrote:
Response from the carrier matche
Response from the carrier matches your description. Looks like their Inbound
carrier is latching but the outbound carrier is not and yes they recommended
handling the NAT on my end.
That said, whats my options here. Is the native rtpproxy scalable? or is it
better to go with a Freeswitch farm t
Re-read the piece of the article related to "RTP latching":
http://blog.csrpswitch.com/server-side-nat-traversal-with-kamailio-the-definitive-guide/
In order for RTP to reach a NAT'd endpoint, all other things being
equal, the other party has to do RTP latching. This is true of both
inbound and o
Well then why does Inbound (from carrier to NATed UA) call work. Kam is doing
something clever there. Why not when sending the call out.
KD
On Wednesday, May 9, 2018, 4:34:55 PM EDT, Alex Balashov
wrote:
Oh, the UAs are NAT'd? Yeah, you're going to need something clever in the
midd
Update. I just checked inbound calls using the "rtpproxy clean" cfg.
Inbound calls from Carrier to UA work fine with bidirectional RTP. Its the
outbound calls from UA to carrier that have a NAT issue.
I am so close :)
KD
On Wednesday, May 9, 2018, 4:29:39 PM EDT, KamDev Essa
wrote:
Oh, the UAs are NAT'd? Yeah, you're going to need something clever in the
middle that can do the RTP latching, then.
-- Alex
--
Sent via mobile, please forgive typos and brevity.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
ht
That did not help. sip capture shows NATed SDP being sent to carrier.
Obviously carrier will not be able to make head nor tails about it. And carrier
SDP sent to UA is perfect as its not NATed. So UA ===> Carrier is fine. Carrier
> UA is no RTP. Does not look like Kam alone can do RTP rela
You'll want to not load the rtpproxy module, and lose any rtpproxy_*() calls in
the actual script.
On May 9, 2018 3:26:43 PM EDT, KamDev Essa wrote:
>If I comment out the modparam("rtpproxy", "rtpproxy_sock",
>"udp:127.0.0.1:7722") as suggested, I do get RTP flowing just in one
>direction. Fro
If I comment out the modparam("rtpproxy", "rtpproxy_sock",
"udp:127.0.0.1:7722") as suggested, I do get RTP flowing just in one direction.
From the UA to kam and out to the carrier. I get nothing geting back to the
end point. In other words 1 way RTP. Looks like its Kam RTPProxy or bust.
KD
Correct. So remove all semblance of any RTP proxy and the resulting behaviour
will be exactly what you expect.
On May 9, 2018 2:13:22 PM EDT, KamDev Essa wrote:
>I dont. I want the 2 end points to talk to each other because I am on
>AWS with shaky bandwidth stats. It can handle signalingbut not
I dont. I want the 2 end points to talk to each other because I am on AWS with
shaky bandwidth stats. It can handle signalingbut not RTP.
However the cfg entry modparam("rtpproxy", "rtpproxy_sock",
"udp:127.0.0.1:7722") gives me to believe (not tcdumped RTP ports yet to prove
it ) that Kam anc
That depends. Start with a more basic question: why do you need RTP relay in
the middle at all?
On May 9, 2018 1:54:55 PM EDT, KamDev Essa wrote:
>So all calls that kamailio processes using the default cfg file anchor
>RTP on the kamailio server? Is it a best architecture to farm out RTP
>to Fr
So all calls that kamailio processes using the default cfg file anchor RTP on
the kamailio server? Is it a best architecture to farm out RTP to Freeswitch?
Or is the Kamailio RTP proxy a better gig?
KD
On Wednesday, May 9, 2018, 1:38:04 PM EDT, Alex Balashov
wrote:
Ironically, nothing
Ironically, nothing. Kamailio doesn't touch the respective parties' SDP unless
you invoke an RTP relay (or something else like fix_nated_sdp()).
On May 9, 2018 1:03:19 PM EDT, KamDev Essa wrote:
>What cfg files changes do I need to make to get Kamailio to be a
>signally only server, yet manipul
What cfg files changes do I need to make to get Kamailio to be a signally only
server, yet manipulate the SDP part of the INVITE message to allow remote
parties to send media to each other? In Freeswitch terms "bypassmedia".
KD___
Kamailio (SER) - Users
15 matches
Mail list logo