Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine
11 Oct
2023
11 Oct
'23
12:29 p.m.
Hi all,
I have the following setup:
Phone <-> private net using TCP transport <-> (172.30.0.156) Kamailio
v5.6.3 + RTPEngine v9.3.1 (22.33.177.156) <-> public net using UDP
transport <-> Asterisk (22.33.178.77)
Phone is registered on Kamailio and forward calls on no answer or when
ext is unregistered, to Asterisk's custom IVR (nodejs app + CouchDB),
using failure_route() [1].
The problem is that when the none answer the phone and the call is
redirected to Asterisk, Kamailio announce its private IP address in
the SDP connection endpoint, hence there is no audio [2]. From
RTPEngine debug logs, it seems that RTPEngine replies with the correct
SDP connection endpoint IP [3]. See also RTPEngine interfaces
definition [4].
What am I missing? Why Kamailio is offering its private IP address in
the SDP connection, instead of its public address when forwarding the
call? If comment "route(SDP_MANAGE_IN)" in route[IN], Kamailio uses
the correct IP endpoint address in the SDP offer when forwarding the
call to Asterisk. But of course this breaks audio when someone answer
the phone. It seems that Kamailio is storing the initial SDP offer
settings and does not update it upon RTPEngine's request, even though
I have added "replace-session-connection" in route[SDP_OFFER_IVR].
Thanks for any help!
leo
[1]
route[IN] {
if (!lookup('location')) {
t_on_reply("SDP_MANAGE");
route(TOIVR);
} else {
xlog("L_INFO", "Route(IN) Req $mi $rm From <$fu> To
<$tu> RURI
<$ru>\n");
record_route();
t_on_reply("SDP_MANAGE");
route(SDP_MANAGE_IN);
t_on_failure("TOIVR");
t_relay();
exit;
}
}
route[SDP_MANAGE] {
if (has_body("application/sdp")) {
rtpengine_manage();
}
}
route[SDP_MANAGE_IN] {
if (has_body("application/sdp")) {
rtpengine_manage("direction=public direction=private via-branch=1");
}
}
...
route[SDP_OFFER_IVR] {
if (has_body("application/sdp")) {
rtpengine_offer("direction=public direction=public
replace-session-connection via-branch=1");
}
}
failure_route[TOIVR] {
if (t_is_canceled()) {
exit;
}
append_branch();
route(SDP_OFFER_IVR);
# using t_relay_to so that UDP is used with the correct IP address
if (!t_relay_to("xh.voip.net")) {
xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm
From <$fu> To <$tu> RURI <$ru> failed\n");
t_reply("500", "Unable to route");
} else {
xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm
From <$fu> To <$tu> RURI <$ru>\n");
}
}
[2]
U 2023/10/11 09:05:43.797393 22.33.177.156:5060 -> 22.33.176.8:5060 #3
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0.
Via: SIP/2.0/UDP
22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0.
Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb.
Record-Route: <sip:172.30.0.156;transport=TCP;r2=on;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.177.156;r2=on;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>.
Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>.
From: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e.
To: <sip:8555000033@22.33.176.20>;tag=660096088.
Call-ID: 474758100_116775912(a)44.55.73.157.
CSeq: 704680 INVITE.
Contact: <sip:+18555000033@172.30.96.2:11815;transport=TCP>.
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY,
REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE.
User-Agent: Yealink SIP-T31P 124.86.0.40.
Allow-Events: talk,hold,conference,refer,check-sync.
Content-Length: 0.
.
U 2023/10/11 09:06:03.751585 22.33.177.156:5060 -> 22.33.178.77:5060 #4
INVITE sip:+18555000033@172.30.96.2:11815;transport=TCP SIP/2.0.
Record-Route: <sip:22.33.177.156;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>.
Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>.
Via: SIP/2.0/UDP
22.33.177.156;branch=z9hG4bK2cb2.afb825e30e294872c72c5e21ef26f3f3.1.
Via: SIP/2.0/UDP
22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0.
Via: SIP/2.0/UDP
22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0.
Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb.
f: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e.
t: <sip:8555000033@22.33.176.20>.
i: 474758100_116775912(a)44.55.73.157.
CSeq: 704680 INVITE.
Max-Forwards: 32.
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH.
Accept: application/sdp, application/isup, application/dtmf,
application/dtmf-relay, multipart/mixed.
m: "Unavailable" <sip:013335553222@44.55.73.157:5060>.
Remote-Party-ID: "Unavailable"
<sip:013335553222@44.55.73.157:5060>;privacy=off.
k: timer,100rel,precondition.
Session-Expires: 1800.
Min-SE: 90.
l: 604.
Content-Disposition: session; handling=required.
c: application/sdp.
.
v=0.
o=Sonus_UAC 525653 764118 IN IP4 44.55.73.157.
s=SIP Media Capabilities.
c=IN IP4 172.30.0.156.
t=0 0.
m=audio 30030 RTP/AVP 0 18 101.
a=maxptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=n
[3]
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Received command 'offer'
from 127.0.0.1:39942
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Dump for 'offer' from
127.0.0.1:39942: { "supports": [ "load limit" ], "sdp":
"v=0^M
o=Sonus_UAC 5
25653 764118 IN IP4 44.55.73.157^M s=SIP Media Capabilities^M c=IN IP4
44.55.78.60^M t=0 0^M m=audio 61610 RTP/AVP 0 18 101^M a=rtpmap:0
PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=maxptime:20^M
", "direction": [ "public", "public" ],
"replace": [
"session-connection" ], "call-id":
"474758100_116775912(a)44.55.73.157
...
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: ... ", "via-branch":
"z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0", "received-from": [
"IP4", "22.33.176
.8" ], "from-tag": "gK0c1bb12e", "command":
"offer" }
...
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Replying to 'offer' from
127.0.0.1:39942 (elapsed time 0.000638 sec)
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Response dump for
'offer' to 127.0.0.1:39942: { "sdp": "v=0^M o=Sonus_UAC 525653
764118
IN IP4 207
.223.73.157^M s=SIP Media Capabilities^M c=IN IP4 22.33.177.156^M t=0
0^M m=audio 30068 RTP/AVP 0 18 101^M a=maxptime:20^M a=rtpmap:0
PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101
teleph
one-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=rtcp:30069^M ",
"result": "ok" }
Oct 11 09:06:03 voipsipr7 daemon.info /usr/sbin/kamailio[35261]: INFO:
<script>: No answer - Failure Route(TOIVR) Req 4 INVITE From
<sip:013335553222@44.55.73.157> To <sip:8555000033@22.33.176.20> RURI
<sip:
+18555000033@172.30.96.2:11815;transport=TCP>
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Received command
'answer' from 127.0.0.1:53245
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Dump for 'answer' from
127.0.0.1:53245: { "supports": [ "load limit" ], "sdp":
"v=0^M o=-
525653 7
64120 IN IP4 22.33.178.77^M s=Asterisk^M c=IN IP4 22.33.178.77^M t=0
0^M m=audio 11264 RTP/AVP 0 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-16^M a=ptime:20^M a=maxptime:150^M
a=sendrecv^M m=audio 0 RTP/AVP 0 18 101^M ", "call-id":
"474758100_116775912(a)44.55.73.157".157", "received-from": [
"IP4",
"22.33.178.77" ], "from-tag": "gK0c1bb12e",
"to-tag":
"a21c53b6-ca33-43b ...
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: ... 4-a585-af9b568a5ecb",
"command": "answer" }
...
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Replying to 'answer'
from 127.0.0.1:53245 (elapsed time 0.000915 sec)
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Response dump for
'answer' to 127.0.0.1:53245: { "sdp": "v=0^M o=- 525653 764120 IN
IP4
22.33.178
.77^M s=Asterisk^M c=IN IP4 22.33.177.156^M t=0 0^M m=audio 30056
RTP/AVP 0 101^M a=maxptime:150^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-16^M a=sendrecv^M a=rtcp:30057^M
a=ptime
:20^M m=audio 0 RTP/AVP 0 18 101^M ", "result": "ok" }
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [core] Forward to sink endpoint:
22.33.178.77:11264 (RTP seq 0 TS 0)
[4]
Interface definition in RTPEngine:
interface = public/22.33.177.156;public/22:33:201:105::156;private/172.30.0.156
12 Oct
12 Oct
3:02 p.m.
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..
Thanks!
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Sonus_UAC 157372 901736 IN IP4 44.55.73.157
Session Name (s): SIP Media Capabilities
Connection Information (c): IN IP4 172.30.0.156
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 30154 RTP/AVP 0 18 101
Media Attribute (a): maxptime:20
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
Media Attribute (a): rtcp:30155
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Sonus_UAC 157372 901736 IN IP4 44.55.73.157
Session Name (s): SIP Media Capabilities
Connection Information (c): IN IP4 22.33.177.156
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 30358 RTP/AVP 0 18 101
Media Attribute (a): maxptime:20
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
Media Attribute (a): rtcp:30359
[Generated Call-ID: 241993330_65984054(a)44.55.73.157]
On Wed, Oct 11, 2023 at 12:29 PM Leonardo Arena <rnalrd(a)gmail.com> wrote:
Hi all,
I have the following setup:
Phone <-> private net using TCP transport <-> (172.30.0.156) Kamailio
v5.6.3 + RTPEngine v9.3.1 (22.33.177.156) <-> public net using UDP
transport <-> Asterisk (22.33.178.77)
Phone is registered on Kamailio and forward calls on no answer or when
ext is unregistered, to Asterisk's custom IVR (nodejs app + CouchDB),
using failure_route() [1].
The problem is that when the none answer the phone and the call is
redirected to Asterisk, Kamailio announce its private IP address in
the SDP connection endpoint, hence there is no audio [2]. From
RTPEngine debug logs, it seems that RTPEngine replies with the correct
SDP connection endpoint IP [3]. See also RTPEngine interfaces
definition [4].
What am I missing? Why Kamailio is offering its private IP address in
the SDP connection, instead of its public address when forwarding the
call? If comment "route(SDP_MANAGE_IN)" in route[IN], Kamailio uses
the correct IP endpoint address in the SDP offer when forwarding the
call to Asterisk. But of course this breaks audio when someone answer
the phone. It seems that Kamailio is storing the initial SDP offer
settings and does not update it upon RTPEngine's request, even though
I have added "replace-session-connection" in route[SDP_OFFER_IVR].
Thanks for any help!
leo
[1]
route[IN] {
if (!lookup('location')) {
t_on_reply("SDP_MANAGE");
route(TOIVR);
} else {
xlog("L_INFO", "Route(IN) Req $mi $rm From <$fu> To
<$tu> RURI
<$ru>\n");
record_route();
t_on_reply("SDP_MANAGE");
route(SDP_MANAGE_IN);
t_on_failure("TOIVR");
t_relay();
exit;
}
}
route[SDP_MANAGE] {
if (has_body("application/sdp")) {
rtpengine_manage();
}
}
route[SDP_MANAGE_IN] {
if (has_body("application/sdp")) {
rtpengine_manage("direction=public direction=private via-branch=1");
}
}
...
route[SDP_OFFER_IVR] {
if (has_body("application/sdp")) {
rtpengine_offer("direction=public direction=public
replace-session-connection via-branch=1");
}
}
failure_route[TOIVR] {
if (t_is_canceled()) {
exit;
}
append_branch();
route(SDP_OFFER_IVR);
# using t_relay_to so that UDP is used with the correct IP address
if (!t_relay_to("xh.voip.net")) {
xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm
From <$fu> To <$tu> RURI <$ru> failed\n");
t_reply("500", "Unable to route");
} else {
xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm
From <$fu> To <$tu> RURI <$ru>\n");
}
}
[2]
U 2023/10/11 09:05:43.797393 22.33.177.156:5060 -> 22.33.176.8:5060 #3
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0.
Via: SIP/2.0/UDP
22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0.
Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb.
Record-Route: <sip:172.30.0.156;transport=TCP;r2=on;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.177.156;r2=on;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>.
Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>.
From: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e.
To: <sip:8555000033@22.33.176.20>;tag=660096088.
Call-ID: 474758100_116775912(a)44.55.73.157.
CSeq: 704680 INVITE.
Contact: <sip:+18555000033@172.30.96.2:11815;transport=TCP>.
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY,
REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE.
User-Agent: Yealink SIP-T31P 124.86.0.40.
Allow-Events: talk,hold,conference,refer,check-sync.
Content-Length: 0.
.
U 2023/10/11 09:06:03.751585 22.33.177.156:5060 -> 22.33.178.77:5060 #4
INVITE sip:+18555000033@172.30.96.2:11815;transport=TCP SIP/2.0.
Record-Route: <sip:22.33.177.156;lr=on;ftag=gK0c1bb12e>.
Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>.
Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>.
Via: SIP/2.0/UDP
22.33.177.156;branch=z9hG4bK2cb2.afb825e30e294872c72c5e21ef26f3f3.1.
Via: SIP/2.0/UDP
22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0.
Via: SIP/2.0/UDP
22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0.
Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb.
f: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e.
t: <sip:8555000033@22.33.176.20>.
i: 474758100_116775912(a)44.55.73.157.
CSeq: 704680 INVITE.
Max-Forwards: 32.
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH.
Accept: application/sdp, application/isup, application/dtmf,
application/dtmf-relay, multipart/mixed.
m: "Unavailable" <sip:013335553222@44.55.73.157:5060>.
Remote-Party-ID: "Unavailable"
<sip:013335553222@44.55.73.157:5060>;privacy=off.
k: timer,100rel,precondition.
Session-Expires: 1800.
Min-SE: 90.
l: 604.
Content-Disposition: session; handling=required.
c: application/sdp.
.
v=0.
o=Sonus_UAC 525653 764118 IN IP4 44.55.73.157.
s=SIP Media Capabilities.
c=IN IP4 172.30.0.156.
t=0 0.
m=audio 30030 RTP/AVP 0 18 101.
a=maxptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=n
[3]
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Received command 'offer'
from 127.0.0.1:39942
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Dump for 'offer' from
127.0.0.1:39942: { "supports": [ "load limit" ], "sdp":
"v=0^M
o=Sonus_UAC 5
25653 764118 IN IP4 44.55.73.157^M s=SIP Media Capabilities^M c=IN IP4
44.55.78.60^M t=0 0^M m=audio 61610 RTP/AVP 0 18 101^M a=rtpmap:0
PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=maxptime:20^M
", "direction": [ "public", "public" ],
"replace": [
"session-connection" ], "call-id":
"474758100_116775912(a)44.55.73.157
...
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: ... ", "via-branch":
"z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0", "received-from": [
"IP4", "22.33.176
.8" ], "from-tag": "gK0c1bb12e", "command":
"offer" }
...
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Replying to 'offer' from
127.0.0.1:39942 (elapsed time 0.000638 sec)
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Response dump for
'offer' to 127.0.0.1:39942: { "sdp": "v=0^M o=Sonus_UAC 525653
764118
IN IP4 207
.223.73.157^M s=SIP Media Capabilities^M c=IN IP4 22.33.177.156^M t=0
0^M m=audio 30068 RTP/AVP 0 18 101^M a=maxptime:20^M a=rtpmap:0
PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101
teleph
one-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=rtcp:30069^M ",
"result": "ok" }
Oct 11 09:06:03 voipsipr7 daemon.info /usr/sbin/kamailio[35261]: INFO:
<script>: No answer - Failure Route(TOIVR) Req 4 INVITE From
<sip:013335553222@44.55.73.157> To <sip:8555000033@22.33.176.20> RURI
<sip:
+18555000033@172.30.96.2:11815;transport=TCP>
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Received command
'answer' from 127.0.0.1:53245
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Dump for 'answer' from
127.0.0.1:53245: { "supports": [ "load limit" ], "sdp":
"v=0^M o=-
525653 7
64120 IN IP4 22.33.178.77^M s=Asterisk^M c=IN IP4 22.33.178.77^M t=0
0^M m=audio 11264 RTP/AVP 0 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-16^M a=ptime:20^M a=maxptime:150^M
a=sendrecv^M m=audio 0 RTP/AVP 0 18 101^M ", "call-id":
"474758100_116775912(a)44.55.73.157".157", "received-from": [
"IP4",
"22.33.178.77" ], "from-tag": "gK0c1bb12e",
"to-tag":
"a21c53b6-ca33-43b ...
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: ... 4-a585-af9b568a5ecb",
"command": "answer" }
...
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO:
[474758100_116775912(a)44.55.73.157]: [control] Replying to 'answer'
from 127.0.0.1:53245 (elapsed time 0.000915 sec)
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [control] Response dump for
'answer' to 127.0.0.1:53245: { "sdp": "v=0^M o=- 525653 764120 IN
IP4
22.33.178
.77^M s=Asterisk^M c=IN IP4 22.33.177.156^M t=0 0^M m=audio 30056
RTP/AVP 0 101^M a=maxptime:150^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101
telephone-event/8000^M a=fmtp:101 0-16^M a=sendrecv^M a=rtcp:30057^M
a=ptime
:20^M m=audio 0 RTP/AVP 0 18 101^M ", "result": "ok" }
Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG:
[474758100_116775912(a)44.55.73.157]: [core] Forward to sink endpoint:
22.33.178.77:11264 (RTP seq 0 TS 0)
[4]
Interface definition in RTPEngine:
interface = public/22.33.177.156;public/22:33:201:105::156;private/172.30.0.156
3:32 p.m.
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.
Cheers
17 Oct
17 Oct
3:08 p.m.
New subject: Rewriting SDP connection endpoint from private to public (was: Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine)
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:
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
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.
216
days inactive
222
days old
3 comments
3 participants
participants (3)
-
Leonardo -
Leonardo Arena
-
Richard Fuchs