Hi,
[Note I posted this yesterday from the wrong email address.]
I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth().
The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier.
kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth.
My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage().
I can see that the NATMANAGEr test for nat_uac_test("8") is true, and rtpengine_manage() s being called. But the outgoing SDP is not changed.
Thanks for any hints!
Paul
====================
Extract of kamailio.cfg
failure_route[TRUNKAUTH] {
if (t_is_canceled()) {
exit;
}
route(NATMANAGE);
xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb");
if(t_check_status("401|407")) {
# $avp(auser) = "test";
# $avp(apass) = "test";
# $avp(apass) = "36d0a02793542b4961e8348347236dbf";
if (uac_auth()) {
t_relay();
}
exit;
}
}
You won't see proper $mb after rtpengine changes in that way. $mb will be rewritten on the latest stage of packet processing. See sngrep or wireshark or either use read_sdp_pv / write_sdp_pv
Also our can use apply_message_changes before log, but I would not recommend to do so if this is a production under load.
On Fri, 2 Jul 2021, 10:28 Paul Smith, paul.smith@claritytele.com wrote:
Hi,
[Note I posted this yesterday from the wrong email address.]
I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth().
The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier.
kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth.
My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage().
I can see that the NATMANAGEr test for nat_uac_test("8") is true, and rtpengine_manage() s being called. But the outgoing SDP is not changed.
Thanks for any hints!
Paul
====================
Extract of kamailio.cfg
failure_route[TRUNKAUTH] {
if (t_is_canceled()) { exit; } route(NATMANAGE); xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb"); if(t_check_status("401|407")) { # $avp(auser) = "test"; # $avp(apass) = "test"; # $avp(apass) = "36d0a02793542b4961e8348347236dbf"; if (uac_auth()) { t_relay(); } exit; }}
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Thanks, I am seeing the same behaviour in sngrep. The second INVITE with auth has incorrect SDP.
Initial INVITE sent to Supplier has correct SDP but no auth as expected.
Second INVITE sent to Supplier has reverted to the original SDP as sent from my phone, but has got the valid auth. I expect to see the SDP "fixed" and same as the first INVITE.
INVITE sip:+3531246****@outbound.voxbone.com:5060 SIP/2.0 Record-Route: sip:34.142.2****;lr;ftag=xgbjwzf22q;nat=yes Via: SIP/2.0/UDP 34.142.2*****:5060;branch=z9hG4bK809b.231d7fff2bdce55a1a947307855d425c.0 v: SIP/2.0/UDP 192.168.68.113:5060;received=78.32.132.180;branch=z9hG4bK-6ttot8sa8aax;rport=38468 f: "voxboneGW" sip:+353******@34.1******;tag=xgbjwzf22q t: sip:00353124*****@34.14*******;user=phone i: 313632353134373536333537383634-z8yg9p65vbrf CSeq: 1 INVITE Max-Forwards: 69 User-Agent: snom725/8.9.3.60 m: sip:+35312678673@192.168.68.113:5060;line=79fr6o6f;alias=78.32.132.180~38468~1;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600 Min-SE: 90 Authorization: Digest username="************",realm="34.1*****",nonce="*****************",uri="sip:00353124*****@34.14******;user=phone",response="********" algorithm=MD5 c: application/sdp l: 1611
v=0 o=root 26854354 26854354 IN IP4 34.1**** s=call c=IN IP4 34.142.29.106 t=0 0 m=audio 30000 RTP/AVP 9 0 8 3 99 112 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:99 G726-32/8000 a=rtpmap:112 AAL2-G726-32/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:30001 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:it3HWB/M7eeDc3LvQmB+THFQeiR0nEURqScfnNoy a=crypto:2 AEAD_AES_256_GCM inline:pMqHMoWzb3xt9mlYSI2FZNlrK/X1lx1/U+TBk7XeHBauSe2IyWScSXZVTu8 a=crypto:3 AEAD_AES_128_GCM inline:4i9e+Ytn4jowBQRHtjxsxVl2uj22pgOhh/sI3w a=crypto:4 AES_256_CM_HMAC_SHA1_80 inline:VxvnS5sJYYrjXtPgi3v12kEV6gV9lJ4re/JSEO8FT18tVJMoIzmSje95HefAcw a=crypto:5 AES_256_CM_HMAC_SHA1_32 inline:NOpu3IsMJuDnPS6DketG/RO+w1mKJD/rdzRENVEF+Fnndez5Vu/yRK/Wr/Va2A a=crypto:6 AES_192_CM_HMAC_SHA1_80 inline:Rwnar613nUJLVJsYLPEFLP75dXb1bM607IbOw2lwop2wMDdRG4Y a=crypto:7 AES_192_CM_HMAC_SHA1_32 inline:hPEp3Nzl0tGuCI84Wk+cj6fTClM+3Nd5cryDSMEpKtiRImyKeiU a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:PEPvkt5duD33hu1zFtiH+iU8z0L6fnJ8ascFg5H6 a=crypto:9 F8_128_HMAC_SHA1_80 inline:BMXOw0RQWKwaq9BC1p5+Q92z7TOQiv8jF1/6ND9V a=crypto:10 F8_128_HMAC_SHA1_32 inline:Ee7vaANwfj97CPdqtFbBfjDhAd5t7Coi0z4UjOPU a=crypto:11 NULL_HMAC_SHA1_80 inline:afMj9BI7C6MC7E4NB56n8A/BxQumLBJg1j2FECYA a=crypto:12 NULL_HMAC_SHA1_32 inline:fNyMLrqdc+ffmGRnmp0BTkv7wvN48CTRWWJmctCH a=setup:actpass a=fingerprint:sha-256 C3:76:76:64:C3:7E:3C:B5:47:1A:D6:44:B6:CD:BF:0E:C7:77:43:08:D6:EA:D6:39:33:3C:BA:21:FF:89:82:E7
========================================================================== INVITE sip:00353124*****@34.1*****;user=phone SIP/2.0 v: SIP/2.0/UDP 192.168.68.113:5060;branch=z9hG4bK-6ttot8sa8aax;rport f: "voxboneGW" sip:+35312******@34.1****;tag=xgbjwzf22q t: sip:00353124*****@34.1*****;user=phone i: 313632353134373536333537383634-z8yg9p65vbrf CSeq: 1 INVITE Max-Forwards: 70 User-Agent: snom725/8.9.3.60 m: sip:+35312678673@192.168.68.113:5060;line=79fr6o6f;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600 Min-SE: 90 Authorization: Digest username="*****",realm="*****",nonce="Y*******",uri="sip:003531******@34.14****;user=phone",response="**********" algorithm=MD5 c: application/sdp l: 487
v=0 o=root 26854354 26854354 IN IP4 192.168.68.113 s=call c=IN IP4 192.168.68.113 t=0 0 m=audio 10742 RTP/AVP 9 0 8 3 99 112 18 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:it3HWB/M7eeDc3LvQmB+THFQeiR0nEURqScfnNoy a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:99 G726-32/8000 a=rtpmap:112 AAL2-G726-32/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Yuriy Gorlichenko ovoshlook@gmail.com Sent: 02 July 2021 10:03 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] UAC_AUTH with RTPEngine NAT
You won't see proper $mb after rtpengine changes in that way. $mb will be rewritten on the latest stage of packet processing. See sngrep or wireshark or either use read_sdp_pv / write_sdp_pv
Also our can use apply_message_changes before log, but I would not recommend to do so if this is a production under load.
On Fri, 2 Jul 2021, 10:28 Paul Smith, <paul.smith@claritytele.commailto:paul.smith@claritytele.com> wrote:
Hi,
[Note I posted this yesterday from the wrong email address.]
I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth().
The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier.
kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth.
My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage().
I can see that the NATMANAGEr test for nat_uac_test("8") is true, and rtpengine_manage() s being called. But the outgoing SDP is not changed.
Thanks for any hints!
Paul
====================
Extract of kamailio.cfg
failure_route[TRUNKAUTH] {
if (t_is_canceled()) {
exit;
}
route(NATMANAGE);
xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb");
if(t_check_status("401|407")) {
# $avp(auser) = "test";
# $avp(apass) = "test";
# $avp(apass) = "36d0a02793542b4961e8348347236dbf";
if (uac_auth()) {
t_relay();
}
exit;
}
}
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
assuming your config is similar to default one in terms of nat processing, do you engage the branch_route before relaying again in failure_route?
Cheers, Daniel
On 02.07.21 11:44, Paul Smith wrote:
Thanks, I am seeing the same behaviour in sngrep. The second INVITE with auth has incorrect SDP.
Initial INVITE sent to Supplier has correct SDP but no auth as expected.
Second INVITE sent to Supplier has reverted to the original SDP as sent from my phone, but has got the valid auth. I expect to see the SDP "fixed" and same as the first INVITE.
INVITE sip:+3531246****@outbound.voxbone.com:5060 SIP/2.0 Record-Route: sip:34.142.2****;lr;ftag=xgbjwzf22q;nat=yes Via: SIP/2.0/UDP 34.142.2*****:5060;branch=z9hG4bK809b.231d7fff2bdce55a1a947307855d425c.0 v: SIP/2.0/UDP 192.168.68.113:5060;received=78.32.132.180;branch=z9hG4bK-6ttot8sa8aax;rport=38468 f: "voxboneGW" sip:+353******@34.1******;tag=xgbjwzf22q t: sip:00353124*****@34.14*******;user=phone i: 313632353134373536333537383634-z8yg9p65vbrf CSeq: 1 INVITE Max-Forwards: 69 User-Agent: snom725/8.9.3.60 m: sip:+35312678673@192.168.68.113:5060;line=79fr6o6f;alias=78.32.132.180~38468~1;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600 Min-SE: 90 Authorization: Digest username="************",realm="34.1*****",nonce="*****************",uri="sip:00353124*****@34.14******;user=phone",response="********" algorithm=MD5 c: application/sdp l: 1611 v=0 o=root 26854354 26854354 IN IP4 34.1**** s=call c=IN IP4 34.142.29.106 t=0 0 m=audio 30000 RTP/AVP 9 0 8 3 99 112 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:99 G726-32/8000 a=rtpmap:112 AAL2-G726-32/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:30001 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:it3HWB/M7eeDc3LvQmB+THFQeiR0nEURqScfnNoy a=crypto:2 AEAD_AES_256_GCM inline:pMqHMoWzb3xt9mlYSI2FZNlrK/X1lx1/U+TBk7XeHBauSe2IyWScSXZVTu8 a=crypto:3 AEAD_AES_128_GCM inline:4i9e+Ytn4jowBQRHtjxsxVl2uj22pgOhh/sI3w a=crypto:4 AES_256_CM_HMAC_SHA1_80 inline:VxvnS5sJYYrjXtPgi3v12kEV6gV9lJ4re/JSEO8FT18tVJMoIzmSje95HefAcw a=crypto:5 AES_256_CM_HMAC_SHA1_32 inline:NOpu3IsMJuDnPS6DketG/RO+w1mKJD/rdzRENVEF+Fnndez5Vu/yRK/Wr/Va2A a=crypto:6 AES_192_CM_HMAC_SHA1_80 inline:Rwnar613nUJLVJsYLPEFLP75dXb1bM607IbOw2lwop2wMDdRG4Y a=crypto:7 AES_192_CM_HMAC_SHA1_32 inline:hPEp3Nzl0tGuCI84Wk+cj6fTClM+3Nd5cryDSMEpKtiRImyKeiU a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:PEPvkt5duD33hu1zFtiH+iU8z0L6fnJ8ascFg5H6 a=crypto:9 F8_128_HMAC_SHA1_80 inline:BMXOw0RQWKwaq9BC1p5+Q92z7TOQiv8jF1/6ND9V a=crypto:10 F8_128_HMAC_SHA1_32 inline:Ee7vaANwfj97CPdqtFbBfjDhAd5t7Coi0z4UjOPU a=crypto:11 NULL_HMAC_SHA1_80 inline:afMj9BI7C6MC7E4NB56n8A/BxQumLBJg1j2FECYA a=crypto:12 NULL_HMAC_SHA1_32 inline:fNyMLrqdc+ffmGRnmp0BTkv7wvN48CTRWWJmctCH a=setup:actpass a=fingerprint:sha-256 C3:76:76:64:C3:7E:3C:B5:47:1A:D6:44:B6:CD:BF:0E:C7:77:43:08:D6:EA:D6:39:33:3C:BA:21:FF:89:82:E7
========================================================================== INVITE sip:00353124*****@34.1*****;user=phone SIP/2.0 v: SIP/2.0/UDP 192.168.68.113:5060;branch=z9hG4bK-6ttot8sa8aax;rport f: "voxboneGW" sip:+35312******@34.1****;tag=xgbjwzf22q t: sip:00353124*****@34.1*****;user=phone i: 313632353134373536333537383634-z8yg9p65vbrf CSeq: 1 INVITE Max-Forwards: 70 User-Agent: snom725/8.9.3.60 m: sip:+35312678673@192.168.68.113:5060;line=79fr6o6f;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600 Min-SE: 90 Authorization: Digest username="*****",realm="*****",nonce="Y*******",uri="sip:003531******@34.14****;user=phone",response="**********" algorithm=MD5 c: application/sdp l: 487 v=0 o=root 26854354 26854354 IN IP4 192.168.68.113 s=call c=IN IP4 192.168.68.113 t=0 0 m=audio 10742 RTP/AVP 9 0 8 3 99 112 18 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:it3HWB/M7eeDc3LvQmB+THFQeiR0nEURqScfnNoy a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:99 G726-32/8000 a=rtpmap:112 AAL2-G726-32/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
*From:* sr-users sr-users-bounces@lists.kamailio.org on behalf of Yuriy Gorlichenko ovoshlook@gmail.com *Sent:* 02 July 2021 10:03 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] UAC_AUTH with RTPEngine NAT You won't see proper $mb after rtpengine changes in that way. $mb will be rewritten on the latest stage of packet processing. See sngrep or wireshark or either use read_sdp_pv / write_sdp_pv
Also our can use apply_message_changes before log, but I would not recommend to do so if this is a production under load.
On Fri, 2 Jul 2021, 10:28 Paul Smith, <paul.smith@claritytele.com mailto:paul.smith@claritytele.com> wrote:
Hi, [Note I posted this yesterday from the wrong email address.] I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth(). The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier. kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth. My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage(). I can see that the NATMANAGEr test for nat_uac_test("8") is true, and rtpengine_manage() s being called. But the outgoing SDP is not changed. Thanks for any hints! Paul ==================== Extract of kamailio.cfg failure_route[TRUNKAUTH] { if (t_is_canceled()) { exit; } route(NATMANAGE); xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb"); if(t_check_status("401|407")) { # $avp(auser) = "test"; # $avp(apass) = "test"; # $avp(apass) = "36d0a02793542b4961e8348347236dbf"; if (uac_auth()) { t_relay(); } exit; } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Daniel-Constantin Mierla -
Paul Smith -
Yuriy Gorlichenko