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

[Alex Balashov]

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.

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.

-- 
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/