23 Apr
2010
23 Apr
'10
3:10 p.m.
Alex-
On 04/23/2010 06:14 AM, Raphael Coeffic wrote:
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
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.
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. 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?) ?