Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine
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@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@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@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@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@44.55.73.157 ... Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912@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@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@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@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@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@44.55.73.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@44.55.73.157]: ... 4-a585-af9b568a5ecb", "command": "answer" }
...
Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912@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@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@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
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@44.55.73.157]
On Wed, Oct 11, 2023 at 12:29 PM Leonardo Arena rnalrd@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@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@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@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@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@44.55.73.157 ... Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912@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@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@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@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@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@44.55.73.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@44.55.73.157]: ... 4-a585-af9b568a5ecb", "command": "answer" } ... Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912@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@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@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
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
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@44.55.73.157]: [core] Final packet stats: 2023-10-13T11:14:22.000293+00:00 voipsipr7 rtpengine[35061]: INFO: [205823320_78862162@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@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@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@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@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@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@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@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
-
Leonardo -
Leonardo Arena
-
Richard Fuchs