Re: [Ekiga-devel-list] [OpenH323]OPAL SIP - Usage of UDP ports


Thank you for your detailed response.

I'm happy to hear about Presence support. I wish I had more time to work on the SIP stack as well...

I'll be waiting for your commit. Then, I will see what can be done about the REGISTER/INVITE issue.



On 3. Dez 2006, at 17:40, Damien Sandras wrote:

Le dimanche 03 décembre 2006 à 16:06 +0100, Hannes Friederich a écrit :
I have discovered some problems regarding the usage of UDP ports
within the SIP stack:

- There is a REGISTER sequence, sent from e.g. port 5000, which works
- The subsequent INVITE, however, is sent from another port, e.g.
5001, targeted to the same host as the REGISTER went to. Now, no
answer PDU is ever received from the remote party. My suspicion is
that either the server isn't accepting INVITEs from a different port
or there is a stateful Firewall in between.

The opposite direction does not work as well:
There is an INVITE received on the same port as from which the
REGISTER was sent (port 5000). OPAL immediately sends a 180 Trying
from the same port. This PDU must have been received by the server,
as there are no more INVITEs received. Now, OPAL switches ports and
sends 180, 200 OK etc. from a different port. Again, this part never
comes to the remote party, as the remote party sends CANCEL after
some time.

I guess it takes a major re-write of OPAL code, but I think OPAL
should use the same outgoing ports when contacting the same remote
node. This would require that the OpalTransport classes are used on a
per-host basis instead of per-connection basis. Or have I overlooked

I have worked a lot on SIP Presence support, ie adding support for

Imagine you send a REGISTER to, then you send a SUBSCRIBE to
subscribe to the presence of user X and another SUBSCRIBE to subscribe
to the presence of user Y. The old OPAL was using a different "local"
port for each of them. Same story for dialog exchanges using the MESSAGE request. If you had 5 active conversations, and 5 active subscriptions,
it mean 10 OpalTransport classes.

As part of my work on SIP Presence, I have changed that, and I'm using a
transport shared by all "connections" to the same destination, with
proper locking as SUBSCRIBE requests from presence support define a SIP
dialog (and each SUBSCRIBE could have different target addresses).

Anyway, that work could be reused (I guess) for the INVITE mechanism.
However, I will not be able to commit that work before one or two weeks
(I hope I can commit soon though) and it changes parts of the API of
OPAL, needing an adaptation of current programs.
 _      Damien Sandras
//\   Ekiga Softphone :
v_/_ NOVACOM         :
          FOSDEM          :
          SIP Phone       : sip:dsandras ekiga net

---------------------------------------------------------------------- -- Check the FAQ before asking! - fom.cgi
The OpenH323 Project mailing list, using Mailman. To unsubscribe or
change your subscription options, goto
Maintained by Quicknet Technologies, Inc -
---------------------------------------------------------------------- --

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]