Hi
Have you tried using the "a" mode of force_rtp_proxy?
This will disable symmetric RTP which it seems is broken by your E72.
Leo
On 12 May 2013, at 12:39, hiro <23h...@gmail.com> wrote:
> On 5/12/13, Leo Brown wrote:
>> Hi
>>
>> I don't know the
Hi
I don't know the e72, but if you do a `tcpdump -A -s0 port 5060` we can see
the SDP data to determine the issue
RTP should be sent to the address defined in SDP unless a symmetric RTP
setup is used for auto NAT traversal- but I believe only Asterisk provides
this, not rtpproxy.
Leo
00 OK to split the Record-Route header into the
separate entries that is possibly more "standard"…?
Cheers,
Leo
On 6 May 2013, at 12:20, Henning Westerholt wrote:
> Am Freitag, 3. Mai 2013, 16:54:29 schrieb Leo Brown:
>> I added record_route() and now I see an extra re
Hi Henning,
I added record_route() and now I see an extra record-route and Via: header:
.9INVITE sip:44800800...@pstn-out.netfuse.net SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 85.13.242.55;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP 81.88.163.210:5060;rport=5060;branch=z9hG4bK82ae6ced
Ace,
So record-route goes like a stack and moves the current contact one down the
chain.
You could then presumably truncate the list of other routes for privacy if
needed?
I don't see why all "record-route" entries need to be maintained if the
conversation is mediated by Kamailio.
Leo
On 3
Hi
My application is for mobile (MVNO) users making calls, which will generally
end up on the PSTN via our carriers.
MVNO Carrier --> Our Edge Switch --> Our PSTN Switch --> Our carrier's
switch
|
