[SR-Users] Changing SDP with subst after rtpproxy_answer corrupts SDP

[Daniel-Constantin Mierla]

Hello,

use msg_apply_changes() from textops modules in between the changes done
to sdp.

No time to check the code, so I am not sure at this moment if can be
done inside the onreply_route[x], which is executed by tm, but should be
possible in core reply_route - -there you can make a filter and detect
it is sdp, do the subst, apply the changes, then let the rtpproxy in
onreply_route[x] like now.

Cheers,
Daniel

On 15/01/15 13:38, Matthias van der Vlies wrote:
> Dear all,
>
> I have an on-reply route that needs to change the SDP version for the
> reply coming in. The use case is that I have a mobile originated call
> and there is some Ericsson switch that doesn't like it when the SDP
> version is updated (in this case by asterisk) although nothing has
> changed to the actual SDP (183 session progress and then OK.)  Funny
> thing is that Asterisk will actually drop a call if it receives a
> re-INVITE with same version... That's why they invented
> ignoresdpversion, but now it's the other way around.... :)
>
> Mobile phone -> Ericsson MSC -> ACME packet -> (18X.4X.XXX.XX)
> Kamailio (10.41.0.21) -> Asterisk
>
> The issue is that the asterisk sends a reply 200 OK, with an updated
> version because it already sent SDP for 183 session progress. This can
> be patched in asterisk, but in my scenario I can unfortunately not do
> that. Thus trying to fix this on Kamailio.
>
> I am able to 'fix' this currently by performing a subst on the sdp
> owner variable:
>
> onreply_route[WITHSDP] {
>         if (has_body("application/sdp")) {
>                 if(ds_is_from_list()) {
>                         rtpproxy_answer("wrei");
>                       *if(subst("/^o=someowner ([0-9]+) ([0-9]+) IN
> IP4 (.*)$/o=someowner \1 \1 IN IP4 \3/")) {*
>                                xlog("L_INFO", "Fixed Asterisk
> incorrect version number in SDP");
>                        }
>                        # tried the answer here as well, but that
> corrupts it even more
>                 }
>                 else {
>                         rtpproxy_answer("wrie");
>                 }
>         }
>         exit;
> }
>
> However this corrupts the SDP:
>
> v=0
> o=tismi 652858233 652858233 IN IP4 10.41.0.21*18X.4X.XXX.XX*
> s=Some server
> c=IN IP4 18X.4X.XXX.XX
> t=0 0
> m=audio 57644 RTP/AVP 8 0 18 3 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:3 GSM/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> a=nortpproxy:yes
>
> When I do not substitute the SDP looks perfectly fine and the external
> address shows as the IN IP4. But of course the version is incremented:
>
> v=0
> o=tismi 1606876535 *1606876536* IN IP4 *18X.4X.XXX.XX*
> s=Some server
> c=IN IP4 18X.4X.XXX.XX
> t=0 0
> m=audio 55410 RTP/AVP 8 0 18 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> a=sdpmangled:yes
>
>
> The ericsson is now accepting this (although it's corrupt, I know....
> probably the ACME doing something funky with it), but it causes issues
> with another unknown piece of equipment that fails on parsing the
> session owner. I hope there is something wrong with my subst, but I'm
> afraid I can not do this from the on_reply route because SDP is only
> updated once it finishes?
>
> I know it's dangerous to alter the session version like this, so I
> made sure the Asterisk will never send a re-INVITE. Now I need a way
> to not corrupt the o=
>
> Kind regards,
>
> Matthias van der Vlies
>
>
>
>
> _______________________________________________
> 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

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