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:[EMAIL PROTECTED] _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list