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

[Aymeric Moizard]

On Mon, 13 Oct 2003, Stefan Fritzsche wrote:

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

I have never used this hook because I know there are
problem with it.... For example, many 200ok from
different sources might be forwarded to the original
sender: but the first one is handled by the statefull
transactions and the other ones are not. This is the
same for retransmissions of 200ok: the retransmissions
are not handled statefully.

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

this is why i have implemented the NAT capabilities
in the sfp module directly.

> 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)?

right!

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

The best idea is proabably to modify the core application
and makes a new option that would enable the kind of
modification you need to be done. (just look for the
point where partysip is trying to forward 200ok ->all
occurence should be in sfp.c)

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

Have you tried the latest (something like 2.0.1?)

I'm working on improving a lot partysip by reimplementing
the sfp.c file as a state machine and removing the uap
module (merged in sfp)

I have successfully run it this w-e. The final idea
is to improve robustness and capability to do
forking or sequential forwarding. Another improvement
that is in my TODO list is to improve the latency
of partysip (what you need!)

On latency, I have worked on a new timer interface
in osip2 this month. This is already available
in the CVS and the new interface could be used
to react more quickly to osip events.

I'll probably create a new CVS branch for this
new partysip (2.1.X) version. Are you familiar
with CVS and CVS branch?

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

If you want to work on such developpement, the only
way for you is to use the CVS version else I'll
never be able to merge your change!!

Watch on CVS link:
 savannah.gnu.org/projects/osip
 savannah.gnu.org/projects/partysip

Aymeric

> 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! +++