Hi, Tested with your changes, and the remote server is pleased with your modification! Call is not dropped anymore by the server (even with a 0 delay before resending invite). So excellent ! :). However as you said, there is a problem with their server since, indeed, 500 should not disconnect the call. I'll report them the problem (for this sip provider I've good contacts so that I can report them the problem easily ;) ... ) Thanks a lot for the fix ! On 02/12/2010 12:27, Benny Prijono wrote: > 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 >> > _______________________________________________ > 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
