osip-dev
[Top][All Lists]
Advanced

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

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


From: Aymeric Moizard
Subject: Re: [osip-dev] RE-INVITE not supported?
Date: Tue, 29 Nov 2016 09:55:55 +0100

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

 

 

 

 

 

 


_______________________________________________
osip-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/osip-dev




--

reply via email to

[Prev in Thread] Current Thread [Next in Thread]