Hi Any thoughts on this one?
Thanks Daniel Nihlén On Thursday 23 February 2012 at 11:17, Daniel Nihlén wrote: > Hi, thanks for looking into this. > > I have isolated only a failing call and here is ngrep trace and cleaner > syslog (this is not the same call as the previous trace). > > 1. Call is started with caller remote 0.0.0.0:50594 > 2. MediaProxy sets that caller remote to 80.72.7.144:50594 when RTP is > received. > 3. ACK for reINVITE changes caller remote to 80.72.7.188:14284. > 4. RTP is received from 80.72.7.188:14284 to MediaProxy. > 5. No media is sent to 80.72.7.188:14284 from MediaProxy (MediaProxy > continues to send to 80.72.7.144:50594 for the duration of the call). > 6. After the call, the stats for MediaProxy says 'caller_remote': > '80.72.7.144:50594' (i would like it to say 80.72.7.188:14284). > > Ngrep: > http://dl.dropbox.com/u/1798100/m2/1305_ngrep_cleaned.txt > > Syslog for both openSIPS and MediaProxy: > http://dl.dropbox.com/u/1798100/m2/1305_syslog_clean_2.txt > > Thanks > Daniel Nihlén > > On Thursday 9 February 2012 at 10:26, Saul Ibarra Corretge wrote: > > > Hi, > > > > On Feb 7, 2012, at 1:34 PM, Daniel Nihlén wrote: > > > > > Hi everyone, > > > > > > We are having some trouble with MediaProxy when SDP info (contact address > > > and port) is changed in ACK for a reINVITE. It’s an AS (Broadworks) that > > > sends INVITE that media should be proxied for. First the call is > > > initiated with media on hold then an ACK of a reINVITE sets new media > > > address and unholds the call. > > > > > > The problem is that MediaProxy seems to have locked to the address where > > > it first received media and ignores media from the address that the > > > reINVITE changes to. > > > > > > Scenario is (SDP in INVITE/200 ok; 80.72.7.144 is the MediaProxy): > > > 1. Call is started on hold: > > > (audio) 0.0.0.0:50026 ON HOLD (RTP: Unknown, RTCP: Unknown) <-> > > > 80.72.7.144:50212 <-> 80.72.7.144:50214 <-> 130.244.51.60:19642 (RTP: > > > Unknown, RTCP: Unknown) > > > > > > > > > 2. RTP traffic is received on 80.72.7.144:50212 I guess MediaProxy > > > 'locks' to that peer address: > > > debug: Got traffic information for stream: (audio) 0.0.0.0:50026 ON HOLD > > > (RTP: 80.72.7.145:50026, RTCP: Unknown) <-> 80.72.7.144:50212 <-> > > > 80.72.7.144:50214 <-> 130.244.51.60:19642 (RTP: Unknown, RTCP: Unknown) > > > > > > 3. reINVITE (no SDP in INVITE) changes media parameters in ACK (and > > > unHolds the stream) 0.0.0.0:50026 is replaced with 80.72.7.188:13708. > > > debug: Got initial answer from caller for stream: (audio) > > > 80.72.7.188:13708 (RTP: 80.72.7.145:50026, RTCP: Unknown) <-> > > > 80.72.7.144:50212 <-> 80.72.7.144:50214 <-> 130.244.51.60:19642 (RTP: > > > Unknown, RTCP: Unknown) > > > > > > 4. RTP traffic is recived from the last address set in SDP. > > > Feb 7 00:38:47 sbc-media04 media-relay[10580]: debug: Got traffic > > > information for stream: (audio) 80.72.7.188:13708 (RTP: > > > 80.72.7.145:50026, RTCP: Unknown) <-> 80.72.7.144:50212 <-> > > > 80.72.7.144:50214 <-> 130.244.51.60:19642 (RTP: 130.244.51.60:19642, > > > RTCP: Unknown) > > > > > > MediaProxy never sends any RTP to 80.72.7.188:13708 but instead continues > > > to send RTP to 80.72.7.145:50026 even after reINIVTE. > > > > > > Any way to get MediaProxy to unlock/forget that it has locked an address > > > for a stream? > > > > > > Full trace is at http://dl.dropbox.com/u/1798100/callconly/index.html > > > The media proxy output is at > > > http://dl.dropbox.com/u/1798100/603_media04_log.txt > > > > > > > > > > > > I tried to follow the traces you provided, but it's quite hard since there > > are other messages interleaved. Anyway, AFAIS MediaProxy did correctly set > > the relaying path after the ACK for the re-INVITE: > > > > Feb 7 00:38:49 sbc-media04 media-relay[10580]: debug: Got traffic > > information for stream: (audio) 80.72.7.188:13708 (RTP: 80.72.7.145:50026, > > RTCP: Unknown) <-> 80.72.7.144:50212 <-> 80.72.7.144:50214 <-> > > 130.244.51.60:19642 (RTP: 130.244.51.60:19642, RTCP: 130.244.51.60:19643) > > > > Perhaps I missed something, but the trace wasn't very clear :-S In case you > > still have the problem, can you provide a SIP trace in ngrep format, the > > mediaproxy and OpenSIPS logs (combined) for a single call? > > > > > > Regards, > > > > -- > > Saúl Ibarra Corretgé > > AG Projects > > > > > > > > > > > > > > _______________________________________________ > > Users mailing list > > [email protected] (mailto:[email protected]) > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
