[OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Sat Nov 3 06:39:22 CET 2012

Hi ALL,

According to 14.1 and 14.2 of RFC 3261 after receiving 491 the UAC will retry again after 2.1-4.0 seconds if it owns the CALL-ID or 0.0.-2.0 if not.

So 
If UAS have an ongoing in-dialog ping and receive another one let it send 491 and drop the request (the end point will retry it later).

// Binan.

________________________________
 Från: Bogdan-Andrei Iancu <bogdan at opensips.org>
Till: OpenSIPS users mailling list <users at lists.opensips.org> 
Kopia: OpenSIPS devel mailling list <devel at lists.opensips.org> 
Skickat: torsdag, 1 november 2012 12:02
Ämne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Hi Dan,

Well, as Ovidiu said, it is prone. BUT, this is not something particular 
to re-INVITE, but to whatever in-dialog pinging you may have from a 
mid-proxy.

On the other hand, as Ryan pointed out here, the need to check the 
dialog health from proxy side, without relying on special end-UA 
features (like SST), is really critical.

So, I see two approaches:
     1) either simply live with the fact that races may occure and calls 
may be dropped during a re-INVITE, but at least is a clear drop /cut
     2) theoretically we can try to address the race at dialog modules 
level : (a) If you have ongoing in-dialog transaction, do not do your 
ping , (b) if you have an ongoing in-dialog ping and receive another 
in-dilog request from end point, try to delay it until your pinging is 
done.....just some ideas....

Regards,

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

On 10/31/2012 09:03 PM, Dan Pascu wrote:
> On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:
>
>> Hi Saul,
>>
>> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan).
>>     1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation)
>>     2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations
>>     3) open to other suggestions....
> I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it.
>
> I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction.
>
>> About the GRUU stuff, could you detail a bit :D ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote:
>>> Hi,
>>>
>>> On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!.
>>>>
>>>> So, I will here the starting points, for both release planing and release content.
>>>>
>>>>
>>>> Content
>>>> -------
>>>> What was done:
>>>>         http://www.opensips.org/Main/Ver190#toc2
>>>> What is planned:
>>>>         http://www.opensips.org/Main/Ver190#toc9
>>>> Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10)
>>>>
>>>>
>>>> Planing
>>>> -------
>>>> Release candidate:
>>>>     second half of January 2012, depending on the progress with the items to be done.
>>>> Testing phase:
>>>>     1 month allocated (it may be extended if critical problems show up)
>>>> Stable release:
>>>>     second half of February (after the testing phase is done).
>>>>
>>>>
>>>> Once again, your feedback on these matters is important to us.
>>>>
>>> I'll edit the wiki with the items we've been working on for presence.
>>>
>>> Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time.
>>>
>>> Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-)
>>>
>>> Keep up the good work guys!
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Saúl Ibarra Corretgé
>>> AG Projects
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121102/3c1070fe/attachment.htm>