|
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;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> 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: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 CSeq: 1 INVITE Via: SIP/2.0/UDP
193.80.90.168:5081;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> 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: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. Regards, Sergey Mikhanov.
The information contained in this e-mail message is privileged and |
Attachment:
ekiga-incorrect.via.and.contact.cap
Description: ekiga-incorrect.via.and.contact.cap