[OpenSIPS-Users] RE-INVITEs being sent to original contact doesn't properly adjust RTP ports on transfer?

[Tyler Merritt]

Just an update on this: it's ridiculously hard. 

We've done some major surgery on the route logic, and at this point I have the strange condition where opensips seems to be sending multiple ACKs to the carrier on a single reINVITE. The carrier should be sending us two invites - one for each leg of the call (because we are transferring the call into a DID we own).

I am tcpdumping the packets and we have tons of these ACKs flying all directions. 

I still have to make a mod based on the to domain of the first ACK, but I don't think that is going to clear everything up all at once. 

Why would we generate multiple ACKs?  Some loop in my routing logic?

Sent from my iPhone 4 

On Feb 4, 2011, at 22:34, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:

> Hi Tyler,
> 
> So ngrep-ing on proxy, you do not see the second re-INVITE (which leads to one way audio)....A possibility is that the re-INVITE may by-pass your opensips. Do you do record-routing also for sequential requests ? There are some bogus UAC/UAS that continuously update the route set, even after the dialog was setup. So maybe the first re-InVITE works ok as you correctly do RR for initial INVITE, but second re-INVITE fails because UAC/UAS expect RR on first re-INVITE too....
> 
> Just a supposition
> 
> Regards,
> Bogdan
> 
> Tyler Merritt wrote:
>> Hi,
>> 
>> We've got three parties for this example:  A, B, C
>> 
>> A - Asterisk end-point Polycom
>> 
>> B - Asterisk end-point Polycom
>> 
>> C - Outside end-point Uniden
>> 
>> OpenSIPs sits in front of the Asterisk servers and communicates with a carrier C5 switch directly (same local area network inside a lab facility)
>> 
>> A calls C - call completes - talk, no issues.
>> 
>> C presses the transfer button, which is a flash-hook putting A on hold.  C dials B.
>> 
>> B answers the call - both parties talk.
>> 
>> C presses the flash-hook button again in order to complete the transfer.
>> 
>> A can hear B - B cannot hear A.
>> 
>> The RTP debug from Asterisk shows that RTP packets from B are still going to C.
>> 
>> B didn't get the RE-INVITE apparently - but I cannot figure out where the packet is.  It's not showing up in OpenSIPs sip_trace, and it's definitely not getting to Asterisk.
>> 
>> I don't have control of the Carrier-side C5 to check, and they have been slow to provide me with a wireshark trace.  
>> Is there anything else I could do in OpenSIPs to determine if the RE-INVITE is not being handled properly besides what I've already mentioned?
>> 
>> Thanks in advance.
>> 
>> Tyler
> 
> -- 
> Bogdan-Andrei Iancu
> OpenSIPS Event - expo, conf, social, bootcamp
> 2 - 4 February 2011, ITExpo, Miami,  USA
> OpenSIPS solutions and "know-how"
>