That's also a solution, but I prefer not dropping the 183 :)
Daniel's (the other one ;-)) suggestion was the solution in the end:
if(subst("/^o=somestuff ([0-9]+) ([0-9]+) IN IP4 (.*)$/o=somestuff \1 \1 IN IP4 \3/")) { xlog("L_INFO", "Fixed Asterisk incorrect version number in SDP"); msg_apply_changes(); } rtpproxy_answer("wrei");
Now it's looking OK:
v=0 o=tismi 895007076 895007076 IN IP4 185.X.X.X s=XXXXX c=IN IP4 185.X.X.X t=0 0 m=audio 39250 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=sdpmangled:yes
Matthias
On 01/15/2015 03:29 PM, Daniel Tryba wrote:
On Thursday 15 January 2015 13:38:00 Matthias van der Vlies wrote:
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
Sounds familiar (the Ericsson is the troublemaker), my solution was to upgrade to asterisk 11.x. But since patching is not possible, I assume upgrading is neither. A workaround was to drop the 183 message in kamailio to Ericsson:
onreply_route[MANAGE_REPLY] { xlog("incoming reply\n"); if(status=~"[12][0-9][0-9]") route(NATMANAGE);
if(status=="183") { drop; }...