[OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy

[Ruud Klaver]

Hi Jeff,

On 17 Jul 2009, at 22:49, Jeff Pyle wrote:

> Let's try it with the attachment this time...

That usually helps. ;)

> On 7/17/09 4:48 PM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:
>
>> Hi Ruud,
>>
>> Sorry for any confusion.  I've attached fresh traces, including a  
>> full ngrep
>> and mediaproxy relay and dispatcher logs.
>>
>> This is an inbound call from PSTN gateway to Asterisk (with  
>> reinvites) to
>> Opensips with Mediaproxy to the callee endpoint.  I have a single
>> engage_media_proxy() at the initial invite.
>>
>>
>> - Jeff
>>
>>
>>
>>
>> On 7/16/09 4:15 AM, "Ruud Klaver" <ruud at ag-projects.com> wrote:
>>
>>> Hi Jeff,
>>>
>>> I've just been scrutinizing your SIP trace, as you still haven't
>>> provided me with mediaproxy-relay debug output. What happens when  
>>> the
>>> SDP offerer comes with a new ip/port combination for a particular
>>> stream is that mediaproxy allocates a new set of ports for this
>>> internally. You can see that this happens by the fact that for the  
>>> re-
>>> invite, the RTP port in the modified SDP is different. This means  
>>> that
>>> both endpoints actually should start sending to a new destination  
>>> as a
>>> result of the re-INVITE exchange. If they do, the previous RTP
>>> exchange and the next one can never actually "cross wires".

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.

So in a sense it's asterisk that's confused by its own re-INVITE, not  
mediaproxy...

Ruud Klaver
AG Projects