Hi, Strictly speaking, we should send 491 response instead of 500 to the re-INVITE when we have sent another re-INVITE (code 500 is when we receive re-INVITE while we're processing yet another incoming re-INVITE). This has been fixed in the latest SVN. I don't think the changes from 500 to 491 would make the server behave differently, but you can try. It looks like the server treats the call as disconnected when it receives 500 for the re-INVITE. This is clearly not a correct behavior. If a re-INVITE fails with anything other than 481 and 408, the session should resume to its previous state as if the re-INVITE had not been sent. Best regards, ?Benny 2010/11/30 R?gis Montoya <r3gis.3r at gmail.com>: > ?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 > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
