Hi all, I need some help/explanation on a very special point : There is a SIP provider that has a b2bua based on opensip (maybe an old version..) Here is the problematic scenario (view from the pjsua based application - latest version from trunk): Send to Server: INVITE CSeq: 4023 INVITE --- [snip proxy authent] --- Received from Server: SIP/2.0 100 trying -- your call is important to us --- Received from Server: SIP/2.0 183 Session Progress --- Received from Server: SIP/2.0 200 OK >>>> HERE WITH MULTIPLE CODECS --- Send to Server: ACK --- >>>>> pjsua_call.c Updating media session to use only one codec.. RE-INVITE from pjsua --- Send to Server: INVITE CSeq: 4025 INVITE -- (And almost at the same time.... server also want to re invite !) -- Receive from Server: INVITE CSeq: 102 INVITE --- So pjsua reply with a 500 error since it is already re-INVITING... (is that the correct error code?) --- Sent to Server: SIP/2.0 500 Another INVITE transaction in progress CSeq: 102 INVITE Received from Server: [Snip ... Proxy auth for CSeq 4025] Send to Server: INVITE CSeq: 4026 INVITE Received from Server: ACK CSeq: 102 ACK >> TCP transport 172.20.xxx.xxx:51174 is connected to 83.136.xxx.xxx:5060 >>(I don't know why but server seems to change from UDP to TCP... well why not?) Received from tcp Server: SIP/2.0 100 trying -- your call is important to us CSeq: 4026 INVITE Received from tcp Server: SIP/2.0 481 Call/Transaction Does Not Exist CSeq: 4026 INVITE ... And then everything goes wrong and the call is automatically ended. Hope that's clear enough. To sum up : seems that the double INVITE (from pjsua and to pjsua) mess up the server state. So my questions : What should be the behavior of the client in this kind of situation? Is replying 500 the good solution? What should be the behavior of the server? Is somebody aware of this kind of problem on Opensip? and what should I feedback to this SIP provider to allow them to fix the problem? However, I have found a workaround that seems to work for now. As if the sip server replies first, pjsua behaves correctly, and as pjsua is really well coded ;), there is an easy way to delay the re-INVITE. So just by changing pjsua_call.c line 3192, delay from 0.0s to 3.0s I get a 100% call establishment while if it is set to 0.0 (the default code), it is about 10% of call that are correctly established (others are automatically hang up by server cause of the 481 error). (3.0 s is maybe extremely large and perhaps only 1s or lower could be enough... my goal was just to let the server re-invite first) But that's not clean at all. So would like to know what should be the good solution to handle this kind of problem. Seems that other sip client I tried when debugging the issue doesn't try to send a re-INVITE to lock codec (maybe they try later if no re-INVITE from server ... I don't know... but the problem is not present) Regards R?gis
