Saul, can we contribute code back to the project if we solve this problem in the source?
Thanks Daniel On Thursday 8 March 2012 at 21:45, Daniel Nihlén wrote: > 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
