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 <bog...@opensips.org>
Till: OpenSIPS users mailling list <us...@lists.opensips.org>
Kopia: OpenSIPS devel mailling list <devel@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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Users mailing
list
>> us...@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> us...@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
us...@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
