23 Apr
2010
23 Apr
'10
2:42 p.m.
On 23.04.10 12:50, Alex Balashov wrote:
On 04/23/2010 06:14 AM, Raphael Coeffic wrote:
The session timer is already fully configurable. It was just about
planning the proper hardware ;-)
On 23.04.10 11:58, Alex Balashov wrote:
I would like it to be configurable, personally. My own intent was to
use it every 1-5 minutes, but even 15 minutes would be sufficient from
a practical perspective.
On 04/23/2010 05:18 AM, Raphael Coeffic wrote:
RFC 3261 says on the topic (section 14.1):
"Of course, a UAC MAY send a re-INVITE with no session description, in
which case the first
reliable non-failure response to the re-INVITE will contain the offer
(in this specification, that is a 2xx response)."
On 23.04.10 09:51, Alex Balashov wrote:
> On 04/22/2010 10:01 AM, Stefan Sayer wrote:
> ]
>> clean? I am not so sure any more, trying to hack something
>> together to
>> see where this gets. Is there a clean and simple method to do
>> re-invite
>> from the b2bua, which catches all the possibilities (changed session
>> etc)?
>>
>> e.g., one possibility, reinvite with last SDP from the other side
>
> From my understanding of SSTs, this is the correct approach (last
> known SDP). This has the advantage of not breaking the changes of
> real
> re-INVITEs that actually happened.
>
Sending an empty INVITE has the appeal of working with either side (no
matter with which you begin). With the other, you might have to
remember
which side initiated the last INVITE or UPDATE transaction, and
send the
last positive SDP answer to this side as a re-INVITE. Or am I missing
something?
However, it might happen that the one of the ends does not support
receiving empty INVITEs... (less probable today).
I thought about empty INVITEs first, but my--admittedly naive--reading
of the specs suggests that many endpoints would take the absence of an
SDP offer/answer in a sequential request or reply within the same
session to mean that the media elements of the session have been
rescinded.
If I'm wrong, that would certainly make all
this a lot easier.
So I guess you MAY be wrong ;-)
Another question is: what would be the expire value you would like to
use for SST? This could dramatically change the requirements in terms of
load. Where you thinking about 15 minutes? (sending a re-INVITE approx.
every 7 minutes?) Or do you need a precise billing (maybe minute
based?) ? Right now I have calls that are getting billed for 8
hours but were in
reality 5 minutes and timed out a long time ago.
Ok, so even the standard 60 minutes "expire" would be an improvement ;-)
-Raphael.