[OpenSIPS-Users] B2B not relaying 180 in prepaid scenario

[Bogdan-Andrei Iancu]

Hi Andreas,

As I don't know of any mechanism to force a ringing in an ongoing call 
by simply using SIP signaling, an alternative is to do inject the 
ringing as media stream - you can use rtpproxy to play a ringing to the 
A-side between the re-INVITE and its 200 OK.

Best regards,

Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

OpenSIPS Bootcamp 2017, Houston, US
   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html

On 07/04/2017 08:00 PM, Andreas Bøckmann wrote:
> Hello Bogdan
>
> It makes sense; to not send them out that is. The A-side has sent 200 
> in reply to re-INVITE and is already "in a call".
>
> Is it braking RFC3261 to send them to the client and is there anything 
> said in regards of how the client must/shall act when receiving 180 
> after 200?
>
> It would make sense to me to let the A-party know the status of 
> "call-progress" during the call (actually both towards mediaserver and 
> later B-party).
>
> How would you suggest solving the case of actually playing back 180 
> for the A-side after hearing the first media?
>
> Using the prepaid scenario example it's waiting for BYE from the 
> mediaserver before re-INVITE and connecting the actual B-party.
> This allows me to force the mediafile to finish playing - something I 
> want it to (not inject media in 183 or similar during ringing).
>
>
> //Andreas
>
>
>
> On Tue, Jul 4, 2017 at 6:43 PM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Andreas,
>
>     Yes, in bridging mode (when one of the party was already connected
>     to a previous entity), the provisional replies are not sent
>     anymore (during the re-INVITE) as make no sense (for the already
>     connected party).
>
>     In your case, once the A side was connected (via 200 OK) to the
>     media server, an incoming 180 on the re-INVITE (while bridging to
>     the B side) will not induce a ringing tone at all.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>        OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com <http://www.opensips-solutions.com>
>
>     OpenSIPS Bootcamp 2017, Houston, US
>        http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>     <http://opensips.org/training/OpenSIPS_Bootcamp_2017.html>
>
>     On 07/04/2017 02:07 PM, Andreas Bøckmann wrote:
>>     Hello
>>
>>     I am playing around with B2B and running OpenSIPS proxy and B2B
>>     on the same VM.
>>     I am triggering prepaid scenario on initial INVITEs for
>>     authenticated clients.
>>
>>     https://www.opensips.org/Documentation/Tutorials-B2BUA#toc13
>>     <https://www.opensips.org/Documentation/Tutorials-B2BUA#toc13>
>>
>>     Now; everything seems to work OK except for the fact that 180 is
>>     not relayed and no ringing is ever heard on the A-side after
>>     listening to Media and while connecting to B-side.
>>
>>     It seems to somehow be swallowed by B2B. It's passed to B2B which
>>     seems to not handle 180 while in bridging scenario?
>>
>>     DBG:tm:local_reply: Passing provisional reply 180 to FIFO application
>>     ....
>>     DBG:b2b_logic:b2b_logic_notify_reply: Received a reply [180]
>>     while in BRIDGING scenario
>>
>>     Even though A-side is connected (after listening to media) it
>>     would make sense to let the A-side play ringing while trying to
>>     reach the B-side.
>>
>>     Any ideas of how I can solve this?
>>
>>     The OpenSIPS log for handling 180 can be found here:
>>     https://pastebin.com/fPVgLrCG <https://pastebin.com/fPVgLrCG>
>>
>>     Thanks a lot for your kind support!
>>
>>     //Andreas
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170706/b47fcf59/attachment.html>