I am testing the functionality of Fraunhofer Fokus OpenIMS core network with different SIP phones and found out strange behavior of Ekiga, which could be considered as a possible bug.
Ekiga registers and then tries to establish a call.
REGISTER request is the following:
REGISTER sip:open-ims.test SIP/2.0
CSeq: 16 REGISTER
Via: SIP/2.0/UDP 22.214.171.124:5080;branch=z9hG4bK0e6ff04b-80fc-db11-8ff4-000c297175a0;rport
From: <sip:bob open-ims test>;tag=1059f04b-80fc-db11-8ff4-000c297175a0
Call-ID: b427404c-7cfc-db11-8ff4-000c297175a0 oims-vm1
To: <sip:bob open-ims test>
Contact: <sip:bob 193 80 90 168:5080;transport=udp>
This will result in creation of association in OpenIMS HSS between PUI sip:bob open-ims test and PrUI sip:bob 193 80 90 168:5080;transport=udp (latter is specified in Contact).
INVITE sent by Ekiga is the following:
INVITE sip:alice open-ims test SIP/2.0
Date: Wed, 09 May 2007 09:50:51 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP 126.96.36.199:5081;branch=z9hG4bK50a4e570-80fc-db11-8ff4-000c297175a0;rport
From: "Bob Bob" <sip:bob open-ims test>;tag=9086e170-80fc-db11-8ff4-000c297175a0
Call-ID: 4473e170-80fc-db11-8ff4-000c297175a0 oims-vm1
To: <sip:alice open-ims test>
Contact: <sip:bob 193 80 90 168:5081;transport=udp>
OpenIMS creates the PrUI on the base of Via header. This record consists of protocol, host and port and used for fetching the associated PUI.
In our example PrUI constructed like this will be sip:bob 193 80 90 168:5081;transport=udp (note the difference in port number). Of course, no PUI is found and 403 Forbidden response is being sent (please find full trace attached for your information).
I am not fully understand, why Via is used by OpenIMS for constructing the PrUI (as far as I understand, this should be done with Contact header), and I’ll submit a message to OpenIMS list as well. Nevertheless it does not seem reasonable to have several Contact values for one device as RFC 3261 describes Contact header in REGISTER as ultimate destination for requests targeted to registered address-of-record, and Contact header in INVITE as ultimate destination for any subsequent request which could result in establishing a dialog (namely, INVITEs).
Therefore, Ekiga should always keep track of all the URIs in Contact header ever sent to another parties (as these parties could try to connect Ekiga using this URIs) as well as all the URIs from REGISTER requests. I.e. it is not fully correct to consider Contact header as a temporary value valid only during the dialog validity time.
It would be nice if Ekiga developers could pay some attention to this issue.
The information contained in this e-mail message is privileged and