[Partysip-dev] problems: SFP-callbacks and mysterious delays

[Stefan Fritzsche]

Hello Partysip-mailing-list !

I have a couple of problems, so I will explain 'em
step by step.

Problem 1:
==========

I want to redirect the RTP-packets of a phone-call
towards a dynamically-configured UDP-bridge. In 
order to do so, I have to manipulate the SDP-payloads
of a phone-call, so that each client sends its RTP-
trafic towards the UDP-bridge.

Therefore I wrote a plugin that installs callback-
functions for the corresponding SIP-messages:
  1. INVITE as IMP-hook         (manipulating SDP,
                             configuring UDP-bridge)
  2. 200-OK as SFP-snd-hook (manipulating SDP,
                             configuring UDP-bridge)
  3. BYE    as IMP-hook     (no SDP-mainpulation,
                             configuring UDP-bridge)

The problem is, that the 200-OK-hook is not called,
for retransmitted 200-OK-messages. This occurs with
some user-agents, if the caller, does not confirm
the 200-OK with an ACK-request within 500ms.

This is bad, because the plugin cannot manipulate the
SDP-payload of the retransmitted 200-OK-message, which
will indicate a wrong IP:port-adress to the callee.

So, am I right that none of these functions will be
called twice (or more-times), for retransmitted
messages (e.g. in the case of timeouts)?

If yes, is there any chance to install callbacks that
will catch every message, even if retransmitted?

(If not, i think about patching the UDP-plugin in order
to hook every (retransmitted) outgoing message at very
low-level ... ugly, I know.)


Problem 2:
==========

The problem of retransmitted INVITE-200-OK-messages
occurs (with some user-agents) if the confirming
ACK-request is not send to the callee within 500 ms.

Therefore I used ethereal to see what's going on at
my network, and I saw, that the partysip-server
forwards the INVITE-200-OK with a delay of 450 to
500 ms. (Although partysip runs on a 1 Giga-Hz-PIII)
The same delay occurs for the forwarded RINGING-message,
too. But a delayed RINGING-message is not as bad as the
delayed 200-OK-message.

After that, I run partysip without my plugin, and also
tested different versions of partysip (0.5.5, 0.5.6 and
0.6.0), but the delay always occurs at the same 
positions (before the forwarded 180-RINGING and the
forwarded INVITE-200-OK).
In contrast to that, the INVITE-, BYE- and BYE-OK-
messages get forwarded without such a big delay
(one or two milli-second or even less).

So, is this a problem of the SFP-module (especially
of the partysip-0.x.x series), or have I done something
wrong ?
At the moment I cannot test this with partysip-2.0.1
because I cannot download libosip-2 (because the gnu-
mirrors say that the files are not avaiable during
authenticity-confirmation an will be uploaded
Real Soon Now - RSN).


Best regards
Stefan Fritzsche


PS: The attachment carries a summary of what ethereal
captured. This means, an example without retransmitted
messages but, you can see the delay (e.g. about 492 ms
for the forwarded INVITE-200-OK).
(partysip 0.6.0 with two kphone 3.1 user-agents and
record-route enabled everywhere)

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

frowarding-delays.txt
Description: Text document