Hello,
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 193.80.90.168:5080;branch=z9hG4bK0e6ff04b-80fc-db11-8ff4-000c297175a0;rp ort User-Agent: Ekiga/2.0.9 From: <sip:[EMAIL PROTECTED]>;tag=1059f04b-80fc-db11-8ff4-000c297175a0 Call-ID: [EMAIL PROTECTED] To: <sip:[EMAIL PROTECTED]> Contact: <sip:[EMAIL PROTECTED]:5080;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 600 Content-Length: 0 Max-Forwards: 70 This will result in creation of association in OpenIMS HSS between PUI sip:[EMAIL PROTECTED] and PrUI sip:[EMAIL PROTECTED]:5080;transport=udp (latter is specified in Contact). INVITE sent by Ekiga is the following: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Route: <sip:oims-vm2:5060;lr> Date: Wed, 09 May 2007 09:50:51 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP 193.80.90.168:5081;branch=z9hG4bK50a4e570-80fc-db11-8ff4-000c297175a0;rp ort User-Agent: Ekiga/2.0.9 From: "Bob Bob" <sip:[EMAIL PROTECTED]>;tag=9086e170-80fc-db11-8ff4-000c297175a0 Call-ID: [EMAIL PROTECTED] To: <sip:[EMAIL PROTECTED]> Contact: <sip:[EMAIL PROTECTED]:5081;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE 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:[EMAIL PROTECTED]: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. Regards, 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.
ekiga-incorrect.via.and.contact.cap
Description: ekiga-incorrect.via.and.contact.cap
_______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
