[Ekiga-devel-list] Ekiga INVITE requests are rejected by OpenIMS P-CSCF



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


Via: SIP/2.0/UDP;branch=z9hG4bK0e6ff04b-80fc-db11-8ff4-000c297175a0;rport

User-Agent: Ekiga/2.0.9

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>


Expires: 600

Content-Length: 0

Max-Forwards: 70


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

Route: <sip:oims-vm2:5060;lr>

Date: Wed, 09 May 2007 09:50:51 GMT


Via: SIP/2.0/UDP;branch=z9hG4bK50a4e570-80fc-db11-8ff4-000c297175a0;rport

User-Agent: Ekiga/2.0.9

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>


Content-Type: application/sdp

Content-Length: 370

Max-Forwards: 70


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.



Sergey Mikhanov.

The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents thereof.

Attachment: ekiga-incorrect.via.and.contact.cap
Description: ekiga-incorrect.via.and.contact.cap

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