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

[Ryan Bullock]

On Wed, Oct 31, 2012 at 12:15 PM, Ovidiu Sas <osas at voipembedded.com> wrote:

> On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu <dan at ag-projects.com> 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.
>
> Yes, it is prone to race conditions :(
> The UAS should detect such race and reply with 491 Request Pending in
> order to clear out this race, but I wonder how many SIP implementation
> are implementing this properly:
> https://tools.ietf.org/html/rfc3261#section-21.4.27
> https://tools.ietf.org/html/rfc3261#section-14.2
>
>
In my experience, very few implementations handle a negative response to a
re-INVITE well  (491 included).

These would make pinging a bit more complicated but may help avoid races:

1.  Have the ping aware of when the last INVITE was seen in the dialog
(sent from anyone) and only issue its own re-INVITE if it has not seen an
INVITE for X seconds in the dialog. Perhaps X could be a lower value if the
previous re-INVITE had a negative reply (many clients locally end the call
when they receive a negative reply to an INVITE, but may not issue a BYE).
Add a little session timer awareness and you may be able to avoid most
races.

2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping
every minute, but you also want to see a re-INVITE every 15 minutes. This
could allow quick detection for clients that support OPTION properly and
the re-INVITE would help detect dead calls when the client is a bit buggy.

The  various implementations for re-INVITE and OPTION support make this an
interesting problem.


_______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121031/25f036be/attachment-0001.htm>