On 12/10/23 15:32, Richard Fuchs via sr-users wrote:
On 12/10/2023 09.02, [EXT] Leonardo Arena via sr-users
wrote:
I've opened the captured traffic with
Wireshark and I've found out
that Kamailio is actually forwarding the call with a double SDP
header. ngrep was showing only a partial header. I think this happens
because when forwarding the call I use rtpengine_offer() and not
rtpengine_manage(). I've tried using rtpengine_manage() and I get only
one SDP header but with the (wrong) private IP address. I've tried
also rtpengine_delete() before rtpengine_offer() but there's always a
double header. Ideas? Still digging..
Duplicated SDPs in combination with rtpengine are usually the result
of manipulating the SDP multiple times, e.g. using sdpops first and
then passing the SDP to rtpengine (or the other way around) without
msg_apply_changes() in between, or perhaps invoking the rtpengine
methods multiple times within the same script run.
Thanks for replying.
Using rtpengine_manage() there is no duplicated SDP header. But the
problem is exactly what is written in the first email: the Kamailio
private IP address is present in the Connection Information field
instead of the public one. I read wrong RTPEngine about having the
correct endpoints after rewriting the destination[1]. I thought that
calling rtpengine_manage() would be enough to rewrite the RTP
destination endpoints when Kamailio redirect the call, but it doesn't
seem to be the case.
In short the problem is that I receive a call with a private leg and
public leg (rtpengine_manage("direction=public direction=private"). Then
after rewriting destination (due to no answer) the private leg is
transformed into a public one, but alas, it still contains SDP private
information, even though after rewriting I call
"rtpengine_manage("direction=public direction=public
replace-session-connection)".
If I tell to rtpengine "direction=public direction=public" as soon as
the call hit the private leg, everything works out-of-the-box, but the
RTP traffic for the private leg goes via the public IP address of
Kamailio, while the SIP signaling remains private. That's not something
I want.
[1]
2023-10-13T11:14:22.000242+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] Final packet stats:
2023-10-13T11:14:22.000293+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --- Tag 'gK042283cd', created
1:24 ago for branch '', in dialogue with 'faff17c2-6e14-436f-854a-7dd
9be10dea8'
2023-10-13T11:14:22.000338+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] ------ Media #1 (audio over
RTP/AVP) using PCMU/8000
2023-10-13T11:14:22.000402+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --------- Port
22.33.177.156:30660 <> 44.55.78.59:36954, SSRC a0d76404, 181 p,
31132 b, 0 e,
60 ts
2023-10-13T11:14:22.000463+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --------- Port
22.33.177.156:30661 <> 44.55.78.59:36955 (RTCP), SSRC 0, 0 p, 0 b, 0
e, 84 ts
2023-10-13T11:14:22.000512+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --- Tag
'faff17c2-6e14-436f-854a-7dd9be10dea8', created 1:24 ago for branch
'z9hG4bKa916.e6b938772e
bf4f5505b77b2997269b69.0', in dialogue with 'gK042283cd'
2023-10-13T11:14:22.000554+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] ------ Media #1 (audio over
RTP/AVP) using unknown codec
2023-10-13T11:14:22.000612+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --------- Port
172.30.0.156:30384 <> 22.33.178.77:16208, SSRC 0, 0 p, 0 b, 0 e, 84 ts
2023-10-13T11:14:22.000671+00:00 voipsipr7 rtpengine[35061]: INFO:
[205823320_78862162(a)44.55.73.157]: [core] --------- Port
172.30.0.156:30385 <> 22.33.178.77:16209 (RTCP), SSRC 0, 0 p, 0 b, 0
e, 84 ts