Re: [osip-dev] RE-INVITE not supported?

[IMS]

Hi Aymeric,

Thank you for your response,

I will contact MITEL and go back to you if I get something interesting.

Sebastien

------------------------------------------

Hi Sebastien!

 

It looks like you are receiving an INVITE before getting a final answer

to the initial INVITE (and even before the dialog is established, because

there is no provisionnal answer received).

 

The rfc3325, I think, doesn't allow at all such behavior. Ie, it would break

rfc3261, the sip standard behavior.

 

According to me, such INVITE is definitly not allowed before the 200 ok

is received by A.

 

As INVITE doesn't contains SDP, I would add that it should not be sent/received

before the ACK is processed. SDP negotiation would overlap with new SDP

negotiation.

 

I do think exosip behavior is correct here: a 481 seems appropriate...

 

If I missed anything, let me know!

 

Regards

Aymeric

 

2016-11-28 13:10 GMT+01:00 IMS <address@hidden>:

Hi,

 

This is my situation.

I have a voip application registered on a MITEL system (MI voice 5000).

When the app try to call, I have an error from the libexosip part.

 

A (192.168.1.207) send an INVITE to the SERVER B (192.168.1.235)

B reply by 100 TRYING

B send the INVITE with the description:

 

Message Header

Via: SIP/2.0/UDP 192.168.1.235;branch=z9hG4bK8e38.bb4fc25cfd4a85cd4276fa7e91a41c41.0

Via: SIP/2.0/UDP 127.0.0.1:5070;branch=z9hG4bK_1_6987f0a7_ctxe_00001102_uumid_1eb31edb;no_sdp=yes

From: "Home" <sip:address@hidden>;tag=2124649361_nab_00D0_isp_0083_cco_39D9_igo_795B_mgt_FFFF

To: " Home " <sip:address@hidden>;tag=2124649361

Call-ID: 1466811287

CSeq: 1 INVITE

Contact: <sip:address@hidden:5060;ctxe=00001102>

Max-Forwards: 15

P-Asserted-Identity: "JohnDoe" <sip:address@hidden>

Privacy: none

User-Agent: A5000 R6.2 SP1 /C400 FRA

Content-Length: 0

 

I can see the error message: ERROR: Existing To-Tag in new INVITE -> reject with 481

 

I know libexosip can support RE-INVITE (in case of hold-on for example) but in this case if I don’t make a mistake we are in a situation described by the RFC 3325 for privacy API.

Does the libexosip should support this case or RFC (maybe in the latest releases)?

Could someone tells me if the INVITE received from the server is authorized (before an ACK)?

 

I take a look to the code of the file udp.c and I think the object exosip_dialog_t does not exist or is not initialized in the function eXosip_process_newrequest() => the function eXosip_process_reinvite is not treated and the eXosip_process_new_invite fails because of the tag in the INVITE ! is it right?

 

Thank for any help.

 

Sebastien