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

[Damien Sandras <dsandras seconix com>]

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