[SR-Users] [Sems] Solutions to missing BYEs, accounting for them

[Raphael Coeffic]

On 23.04.10 12:50, Alex Balashov wrote:
> On 04/23/2010 06:14 AM, Raphael Coeffic wrote:
>> On 23.04.10 11:58, Alex Balashov wrote:
>>> On 04/23/2010 05:18 AM, Raphael Coeffic wrote:
>>>> 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.
>>>
>> 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)."
>>
>>> 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?) ?
>
> 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.
>
The session timer is already fully configurable. It was just about 
planning the proper hardware ;-)

> 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.