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

[Hannes Friederich <hannesf ee ethz ch>]

Damien,

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.

Thanks!

Hannes

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
> > well.
> > - 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
> > something?
>
> I have worked a lot on SIP Presence support, ie adding support for
> SUBSCRIBE, PUBLISH, NOTIFY and so on in OPAL.
>
> Imagine you send a REGISTER to ekiga.net, 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
> (o-
> //\   Ekiga Softphone : http://www.ekiga.org/
> v_/_ NOVACOM         : http://www.novacom.be/
>           FOSDEM          : http://www.fosdem.org/
>           SIP Phone       : sip:dsandras ekiga net
>
>
> ---------------------------------------------------------------------- 
> --
> Check the FAQ before asking! - http://www.openh323.org/~openh323/ 
> fom.cgi
> The OpenH323 Project mailing list, using Mailman. To unsubscribe or
> change your subscription options, goto
> http://www.openh323.org/mailman/listinfo/openh323
> Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
> ---------------------------------------------------------------------- 
> --