15 Jan
2015
15 Jan
'15
3:39 p.m.
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;
}
...