Hi guys,
I'm trying to setup a Call Forward No Reply with Kamailio and I've run into this problem (that was expected):
When A INVITEs B, B replies with 183 and some SDP. B doesn't answer so Kamailio triggers the timeout and sends the INVITE TO C. C replies with 200 OK and some SDP, but A side drops the call as the media session doesn't match with the expected one.
To solve it, I'm trying to send to A an UPDATE before relaying the 200 OK from C. I tried to use UAC module (uac_req_send + $uac_req) but I don't see how I can UPDATE the existing dialog. uac_req_send seems to try to setup a new dialog always. Is there a way to indicate to uac_req_send that I wan't to use the existing dialog? Or maybe there is another mechanism I can use to send the UPDATE inside the dialog?
Regards, Alfonso.
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.
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 abalashov@evaristesys.com 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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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:carsten@ng-voice.com
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 alfonso.pinto@gmail.com:
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 abalashov@evaristesys.com 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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 carsten@ng-voice.com 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:carsten@ng-voice.com
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 alfonso.pinto@gmail.com:
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 <
abalashov@evaristesys.com>
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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 alfonso.pinto@gmail.com 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 carsten@ng-voice.com 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:carsten@ng-voice.com
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 alfonso.pinto@gmail.com:
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 <
abalashov@evaristesys.com>
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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Abdul Basit -
Alex Balashov -
Alfonso Pinto -
Carsten Bock