Thanks Bogdan, I set up an account and opened a ticket as you requested. Let me know if you need any other info.
Tony Ward -----Original Message----- From: Bogdan-Andrei Iancu [mailto:[email protected]] Sent: Friday, March 07, 2014 5:12 AM To: OpenSIPS users mailling list; Tony Ward Subject: Re: [OpenSIPS-Users] B2BUA REFER scenario Hello Tony, That's definitely a good idea that must be considered - of course, such a change is not trivial, but I will open a TODO ticket on the GitHub tracker. Or if you have a github account, it will be wonderful if you could open the bug report. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.03.2014 21:04, Tony Ward wrote: > Thanks for explaining this, Bogdan. > > I'm curious, though - would things work better if the late-SDP > negotiation were done the other way around i.e., since call3 is a new > call it could take longer for setup to occur, and during this time call1 > times out. If we were to send the initial INVITE to call3, get the > OK+SDP from call3, then invite+SDP call1, perhaps it would respond > OK+more > quickly since the call is already set up, and when it does we can send > ACK+SDP to call3 to complete the transfer. This may also provide the > ability in the future to avoid disconnecting call1 leg to the IVR so > that it can be retained in the event call3 fails. > > Just a thought... > Tony Ward > > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:[email protected]] > Sent: Thursday, March 06, 2014 12:13 PM > To: OpenSIPS users mailling list; Tony Ward > Subject: Re: [OpenSIPS-Users] B2BUA REFER scenario > > Hello Tony, > > You may consider this a side effect of how the OpenSIPS B2BUA works. > As we want to be transparent from media point of view, OpenSIPS does > not get involved into SDP negotiation -> it is transparent, passing > the SDPs between the end points. This is mainly based on the late-SDP > negotiation > - and combining this with normal SDP negation may lead into ACK delays. > > In this particular case the ACK for Call1 is delaied because the B2BU > is waiting for the 200 OK on Call3 - because the SDP from the 200 OK > in > Call3 must be pushed in the ACK for Call1 (to allow direct SDP > negotiation between the end points involved in call1 and call3). So > the ACK for call1 will be delayed until Call3 gets answered - there is > no work around this at this point. In most of the cases the UA are a > bit flexible in waiting for ACK, like at least performing 200OK > retransmission (as per RFC3261). I would say your PSTN device is a bit > picky ;) when comes to firing the BYE in 6 sec (no retransmission, > short period of time). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 05.03.2014 20:06, Tony Ward wrote: >> Hello, >> I currently have this configuration: >> PSTN <====> SIP/ALG Router <====> OpenSips 1.10 <====> IVR OpenSips >> has a single IP on the private network. >> >> I have configured opensips using top hiding in the dialog module and > it >> works fine for calls to ptsn and calls from pstn. >> I have also configured opensips using B2BUA top hiding and it also > works >> fine for calls to ptsn and calls from pstn. >> >> Now I want to test B2BUA REFER scenario (where calls from PSTN are >> answered by IVR, then IVR does a REFER to another PSTN number). >> >> When the IVR sends REFER the call is dropped after .6 seconds. The > flow >> that I've seen in the trace is below: >> PSTN opensips IVR >> invite+SDP (Call1) ----> | >> <----- Trying (Call1) | >> | invite+SDP (Call2)-----> >> | <----- OK+SDP (Call2) >> <----- OK+SDP (Call1) | >> Ack (Call1) ----> | >> | ACK (Call2) -----> >> >> <Ivr dialog take place here> >> >> | <----- REFER (Call2) >> <----- Invite (Call1) | >> | Accepted (Call2) -----> >> | BYE (Call2) -----> >> Trying (Call1) ----> | >> OK+SDP (Call1) ----> | >> <----- Invite+SDP(Call3)| >> | <----- OK (Call2) >> Trying (Call3) -----> | >> OK+SDP (Call1) -----> | >> OK+SDP (Call1) -----> | >> >> <0.6 seconds elapse here> >> >> Bye (Call1) -----> | >> <----- OK (Call1) | >> <----- Cancel (Call3) | >> OK (Call3) -----> | >> Req Termd (Call3) ----->| >> <----- Ack (Call3) | >> >> It looks as though the PSTN times out waiting for an ACK after >> sending >> OK+SDP(Call1) a couple times and then waiting .6 seconds. >> The question is - what should the flow look like? According to this >> post: > http://lists.opensips.org/pipermail/users/2012-April/021352.html, >> things appear to be working as expected up to the point where we > receive >> Trying (Call3). Should I be seeing the OK+SDP from call 3 next? >> I'd like to troubleshoot further but I'm not sure where to look. >> >> Thanks! >> Tony >> >> >> _______________________________________________ >> Users mailing list >> [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 > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
