Well, we faced the same issue of call drop when we play announcement over 183 and then handover call to B party when it come online on voip push notification.
Telcos have more rigid systems. Resolution was introducing B2BUA for topo-hiding in the path IMS (A party) and VoIP service (B & C party). Check tags of to and from headers of your call traces. That will give you clue. -- regards, abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445 On 30 April 2018 at 14:59, Alfonso Pinto <[email protected]> wrote: > Hi Carsten, > > I was thinking about the same, but I need to convince people to add > another component in the media path, they may be bit reluctant, but the > idea is great. > In the meantime, I was able to trick the phones to react how I want > playing with precondition and 100rel, for now it's acceptable in our > environment. > > Thanks for your answer. > Regards, > Alfonso. > > On Fri, Apr 27, 2018 at 9:39 AM, Carsten Bock <[email protected]> > wrote: > >> Hi, >> >> likely, the best solution is here to use RTPEngine, so the IP/Port >> stays identical for each request... i've tested it with various VoLTE >> phones and various PCRF's. >> >> Thanks, >> Carsten >> -- >> >> Carsten Bock >> CEO (Geschäftsführer) >> >> ng-voice GmbH >> Millerntorplatz 1 >> 20359 Hamburg / Germany >> >> http://www.ng-voice.com >> mailto:[email protected] >> >> Office +49 40 5247593-40 >> Fax +49 40 5247593-99 >> >> Sitz der Gesellschaft: Hamburg >> Registergericht: Amtsgericht Hamburg, HRB 120189 >> Geschäftsführer: Carsten Bock >> Ust-ID: DE279344284 >> >> Hier finden Sie unsere handelsrechtlichen Pflichtangaben: >> http://www.ng-voice.com/imprint/ >> >> >> 2018-04-26 15:59 GMT+02:00 Alfonso Pinto <[email protected]>: >> > Hi Alex, >> > >> > Thanks for your answer. I was thinking more or less the same, but it >> seems I >> > oversimplified the example and was missing an important point. >> > This is IMS, so in the middle there are a lot more in the middle. It >> seems >> > that this behaviour is normal when precondition is set and the only way >> to >> > avoid the network to release the call on A side is to send the update. >> > I've seen that in Kamailio 5 a new function was included in TM: >> > https://www.kamailio.org/docs/modules/5.1.x/modules/tm.html# >> tm.f.t_uac_send >> > In the code it looks like it's trying to use the current dialog, but >> that >> > gives me doubts about CSEQ handling on the other side. >> > >> > Anyway, I will try unless someone is faster replying saying it doesn't >> work >> > :) >> > >> > Thanks, >> > Alfonso. >> > >> > On Thu, Apr 26, 2018 at 2:37 PM, Alex Balashov < >> [email protected]> >> > wrote: >> >> >> >> I would instead redirect my focus to why A is dropping the call in this >> >> situation. It shouldn't be doing that. >> >> >> >> Per the standards, the first SDP answer must be the final SDP answer >> >> (absent an update or reinvite) *of that endpoint*. There's no rule >> saying >> >> that must be true of the dialog as a whole. >> >> >> >> -- Alex >> >> >> >> -- >> >> Sent via mobile, please forgive typos and brevity. >> >> >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> > >> > >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
