[SR-Users] Recent problem with fix_nated_sdp and kamailio 4.4.4

Daniel-Constantin Mierla miconda at gmail.com
Mon Nov 28 09:54:21 CET 2016


The commit 81df84b is related to tls, so there should be no relation
with nat functions.

Are you using t_suspend()/t_continue() or other async processing functions?

Anyhow, whatever changes you want to be specific for each outgoing
request must be done in a branch_route. request_route changes are
visible to all changes and if you do something again in branch_route or
failure_route, then you will see duplicated operations.

Cheers,
Daniel


On 28/11/2016 09:02, Anthony Messina wrote:
> Prior to the upgrade to Kamailio 4.4.4, I was using 4.4.3 with updates
> through 81df84b from the 4.4 branch and the following fix_nated_sdp
> call worked through the initial INVITE and when a voicemail branch was
> appended from the failure_route.
>
> route[NATMANAGE] {
> ...
>
> # RTPEngine is not needed but if STUN addresses are being used on our
> # internal network, rewrite the addresses to the internal source address
> if(!isbflagset(FLB_RTPENGINE) && has_body("application/sdp")) {
>         if(dst_ip==10.1.1.2 &&
> compare_pure_ips($sel(contact.uri.host), "<EXTERNAL_IP>")) {
>                 fix_nated_sdp("10");
>         }
> }
>
> ...
> }
>
> Since the upgrade to 4.4.4, when the original INVITE fails over to
> voicemail (branch appended), fix_nated_sdp creates the SDP below,
> doubling the replaced IP addresses.  Asterisk replies with 488, as the
> media address is completely invalid.  I need something like the above
> (which worked for the request and the reply) but can't figure out what
> the problem is.
>
> v=0
> o=Zoiper 0 0 IN IP4 10.1.1.18210.1.1.182
> s=Zoiper
> c=IN IP4 10.1.1.18210.1.1.182
> t=0 0
> m=audio 63732 RTP/SAVP 9 3 0 97 101
> a=rtpmap:9 G722/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=30
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
> a=crypto:5 AES_256_CM_HMAC_SHA1_80
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDIGKI2LPOLdNDOcpFdtqu5DQ==
> a=crypto:6 AES_256_CM_HMAC_SHA1_32
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDIGKI2LPOLdNDOcpFdtqu5DQ==
> a=crypto:3 AES_192_CM_HMAC_SHA1_80
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDIGKI2LPOLdNA=
> a=crypto:4 AES_192_CM_HMAC_SHA1_32
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDIGKI2LPOLdNA=
> a=crypto:1 AES_CM_128_HMAC_SHA1_80
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDI
> a=crypto:2 AES_CM_128_HMAC_SHA1_32
> inline:n2C0BcdXOr32BPTEE8pfHII9mamAK566xMNvQIDI
> a=oldmediaip:<EXTERNAL_IP>
> a=oldmediaip:<EXTERNAL_IP>
> a=oldmediaip:<EXTERNAL_IP>
> a=oldmediaip:<EXTERNAL_IP>
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161128/ebc69b74/attachment.html>


More information about the sr-users mailing list