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

[Jeff Brower]

Alex-

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

I apologize in advance for getting in the middle of this and possibly suggesting
something simplistic that either won't work or isn't what you guys need.

But... is it being considered to add functionality to rtpproxy so it can send
something asynchronously to Kamailio which either sends BYEs or does something to
cause the endpoints to do so?  Currently, as far as I know, rtpproxy only responds to
commands from nathelper; i.e. every command is initiated by nathelper who expects a
response.

I ask for two reasons:

  -rtpproxy is the natural place to detect RTP
   time-outs

  -rtpproxy eventually has to support other async
   notifications (such as SRTP key requests, see
   my previous e-mail)

-Jeff