[OpenSIPS-Users] OpenSIPs not replacing SDP after rtpengine_offer()

[Peter Baines (lists)]

Hello,

When I am calling rtpengine_offer() on an INVITE it is not replacing the
internal address with the external address as expected, it is however
replacing the SDP for 200 OKs correctly when I call rtpengine_answer().

So the intial SDP of the INVITE has the following which I want push through
rtpengine and replace with 123.45.67.89:

o=vfa117 3467 3657 IN IP4 192.168.0.2.
c=IN IP4 192.168.0.2.

I am calling rtpengine_offer() like so and it reports the SDP it gets:

Apr  6 09:40:10 ip-172-31-26-213 /usr/local/opensips/sbin/opensips[2179]:
-- [y30aqn3JtY] - Got [INVITE], going to
rtpengine_offer(replace-session-connection replace-origin ICE=remove)
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: INFO: [y30aqn3JtY]: Received
command 'offer' from 127.0.0.1:63992
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: Dump for
'offer' from 127.0.0.1:63992: { "sdp": "v=0#015#012o=vfa117 3467 3657 IN
IP4 *192.168.0.2*#015#012s=Talk#015#012c=IN IP4
*192.168.0.2*#015#012b=AS:2500#015#012t=0
0#015#012a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL
voip-metrics#015#012m=audio 7078 RTP/SAVP 96 0 8 101 97#015#012a=rtpmap:96
speex/16000#015#012a=fmtp:96 vbr=on#015#012a=rtpmap:101
telephone-event/16000#015#012a=rtpmap:97
telephone-event/8000#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:M4awKdXUI4tjdr2Uy2SwlmZy3+xzw1XWCPd/Pe4d#015#012a=crypto:2
AES_CM_128_HMAC_SHA1_32
inline:gINiLpKF6iqnTYltJv0lmn17sG08JSPSsjGXSYV9#015#012a=crypto:3
AES_CM_256_HMAC_SHA1_80
inline:xn16IAQSOFbAqVkttJCxstdmMHGCLIEw4B1XthdYs8a7iPHi6fslcHmPlLZGuA==#015#012a=crypto:4
AES_CM_256_HMAC_SHA1_32
inline:gj2UuLeb1DbnMczCvD7H+fB82Nq0BRISk+0QLved90s3ZcIQ5y+2eIwbP3kYyw==#015#012m=video
9078 RTP/SAVP 96#015#012a=rtpmap:96 VP8/90000#015#012a=crypto:1
AES_CM_128_HMAC_SHA1_80
inline:RZuVyT7/JQw8pG1JF9ogj9mfD1s5t+jImPQ9ritH#015#012a=crypto:2
AES_CM_128_HMAC_SHA1_32
inline:3+SbKwybJNXpH2q4fvZ4Wl5t7mFeXsAXrNp0X2Fd#015#012a=crypto:3
AES_CM_256_HMAC_SHA1_80
inline:N4EYmBBQAVwvK2AXuD3Q4XnzR5ABFuq6vFvMvgy2g99uDzM7Fud8L/qtCfJgRQ==#015#012a=crypto:4
AES_CM_256_HMAC_SHA1_32
inline:vmkHPEUdDaAEpNDdPUKSAylB5OWsVO65Wpk3QIFsFZTq3SZmiXRr0oKTw5x1pw==#015#012",
"ICE": "remove", "replace": [ "session-connection", "origin" ], "call-id":
"y30aqn3JtY", "received-from": [ "IP4", "98.76.54.32" ], "from-tag":
"zqSHHhSVK", "command": "offer" }
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: ERR: [y30aqn3JtY]: Failed to
parse a=crypto attribute, ignoring: unknown crypto suite
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: ERR: [y30aqn3JtY]: Failed to
parse a=crypto attribute, ignoring: unknown crypto suite
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: ERR: [y30aqn3JtY]: Failed to
parse a=crypto attribute, ignoring: unknown crypto suite
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: ERR: [y30aqn3JtY]: Failed to
parse a=crypto attribute, ignoring: unknown crypto suite
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: NOTICE: [y30aqn3JtY]: Creating
new call
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: set FILLED
flag for stream 192.168.0.2:7078
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: set FILLED
flag for stream 192.168.0.2:7079
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: set FILLED
flag for stream 192.168.0.2:9078
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: set FILLED
flag for stream 192.168.0.2:9079
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: INFO: [y30aqn3JtY]: offer time
= 0.000899 sec



It dumps out the response with the correctly changed external address
(123.45.67.89):



Apr  6 09:40:10 ip-172-31-26-213 rtpengine: INFO: [y30aqn3JtY]: Replying to
'offer' from 127.0.0.1:63992
Apr  6 09:40:10 ip-172-31-26-213 rtpengine: DEBUG: [y30aqn3JtY]: Response
dump for 'offer' to 127.0.0.1:63992: { "sdp": "v=0#015#012o=vfa117 3467
3657 IN IP4 *123.45.67.89*#015#012s=Talk#015#012c=IN IP4
*123.45.67.89*#015#012b=AS:2500#015#012t=0
0#015#012a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL
voip-metrics#015#012m=audio 11186 RTP/SAVP 96 0 8 101 97#015#012a=rtpmap:96
speex/16000#015#012a=fmtp:96 vbr=on#015#012a=rtpmap:101
telephone-event/16000#015#012a=rtpmap:97
telephone-event/8000#015#012a=sendrecv#015#012a=rtcp:11187#015#012a=crypto:1
AES_CM_128_HMAC_SHA1_80
inline:M4awKdXUI4tjdr2Uy2SwlmZy3+xzw1XWCPd/Pe4d#015#012a=setup:actpass#015#012a=fingerprint:sha-1
1B:29:98:4E:0F:92:9E:F2:A9:02:B8:BC:C8:3E:5F:7F:D0:C6:49:A0#015#012m=video
11218 RTP/SAVP 96#015#012a=rtpmap:96
VP8/90000#015#012a=sendrecv#015#012a=rtcp:11219#015#012a=crypto:1
AES_CM_128_HMAC_SHA1_80
inline:RZuVyT7/JQw8pG1JF9ogj9mfD1s5t+jImPQ9ritH#015#012a=setup:actpass#015#012a=fingerprint:sha-1
1B:29:98:4E:0F:92:9E:F2:A9:02:B8:BC:C8:3E:5F:7F:D0:C6:49:A0#015#012",
"result": "ok" }

However when the packet is sent out of opensips it still has the internal
192.168.0.2 address instead of the external 123.45.67.89 address as I would
expect.

Regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170412/580dba48/attachment.html>