[OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy

[Ruud Klaver]

Hi Jeff,

On 21 Jul 2009, at 17:17, Jeff Pyle wrote:

> Hi Ruud,
>
> On 7/20/09 6:29 AM, "Ruud Klaver" <ruud at ag-projects.com> wrote:
>
>> What I said is still valid, both endpoints SHOULD start sending to  
>> the
>> new ip/port destination after the re-INVITE transaction has finished.
>> Looking at the mediaproxy logs you sent, all is fine up to the point
>> where the caller is about to receive the 200 OK for the re-INVITE.
>> After it did receive it, mediaproxy-relay display the following line:
>>
>> debug: Got traffic information for stream: (audio) 44.55.66.30:13504
>> (RTP: 22.33.44.82:28140, RTCP: Unknown) <-> 22.33.44.89:16392 <->
>> 22.33.44.89:16394 <-> 33.44.55.122:17328 (RTP: 33.44.55.122:17328,
>> RTCP: Unknown)
>>
>> You can see that the relay got RTP from the caller side from the old
>> ip/port, that is the asterisk box, while in the re-INVITE it proposed
>> to change this to 44.55.66.30:13504. This must mean that asterisk
>> takes the ip/port from the 200 OK, which is newly allocated on the
>> relay, and starts sending to this directly. What should have happened
>> is that asterisk informs the endpoint (through its own re-INVITE?)
>> that of the new port/ip so that this endpoint could send to it
>> directly, without asterisk sending to it first. Because asterisk did
>> start sending to it itself, the relay locks in the source ip/port for
>> this stream and will ignore other UDP traffic sent to this port.
>
> It took me a few more test calls and a lot of crunch time to wrap my  
> mind
> around what you had said.
>
> I believe I've finally found what you're talking about.  In another  
> call, I
> saw in a media capture the Asterisk box had "dribbled" about 8 RTP  
> packets
> to the new, post-reINVITE ip/port on the relay before its RTP stops  
> and the
> PSTN gateway's RTP starts.  But, as you've mentioned, by this time  
> it's too
> late because the relay has locked in the Asterisk box's IP/port and  
> the PSTN
> gateway RTP is ignored.  I imagine this is because of the processing  
> lag in
> the reinvite on the PSTN gateway-side of the Asterisk box.

Perhaps it's because it does the proxy-side re-INVITE first, using the  
UDP ip/port it knows from the RTP stream it's relaying, and only then  
sends a re-INVITE on the PSTN gateway side, continuing to relay the  
RTP packets to the new mediaproxy port in the meantime.

Is there any particular reason why you need Asterisk inbetween? In any  
case, I suppose you could disable re-INVITEs in asterisk. The  
implementation of it seems to be a bit of a hack.

>> So in a sense it's asterisk that's confused by its own re-INVITE, not
>> mediaproxy...
>
> Yes.  Indeed it does.  Imagine that.
>
> Thanks for your help.
>
>
> - Jeff
>


It's an interesting case, but I hope you can deal with it somehow.

Ruud Klaver
AG Projects