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:[email protected]: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:[email protected]: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 <[email protected]> on behalf of > Yuriy Gorlichenko <[email protected]> > *Sent:* 02 July 2021 10:03 > *To:* Kamailio (SER) - Users Mailing List <[email protected]> > *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, <[email protected] > <mailto:[email protected]>> 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 > * [email protected] <mailto:[email protected]> > 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 > * [email protected] > 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 -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * [email protected] 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
