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

[Tyler Merritt]

Well now I've made further changes and it appears that the carrier must be
doing some late night maintenance - because I'm getting 0 replies to my 200
OKs now - so Asterisk just continues to re-generate them endlessly.


On Wed, Feb 9, 2011 at 7:20 PM, Tyler Merritt <tmerritt at fonality.com> wrote:

> 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"
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110209/afbb2f7b/attachment.htm>