If you want to make workaround for this problem, you could plug-in a pjsip_module, with a correct priority (see doc), and add "transport=tcp" parameter to the Contact URI of the incoming 200/OK response. Please see PJSIP Developer's Guide PDF for more info about pjsip_module. ?-Benny 2010/12/2 R?gis Montoya <r3gis.3r at gmail.com>: > ?Tried to dive into the code. > > Seems the final thing that make pjsip stop using tcp transport is : > dlg_update_routeset in pjsip/sip_dialog.c line 1649. > > > There is an interesting comment on the code : > /* Freeze the route set only when the route set comes in 2xx response. > ? ? * If it is in 1xx response, prepare to recompute the route set when > ? ? * the 2xx response comes in. > ? ? * > ? ? * There is a debate whether route set should be frozen when the dialog > ? ? * is established with reliable provisional response, but I think > ? ? * it is safer to not freeze the route set (thus recompute the route set > ? ? * upon receiving 2xx response). Also RFC 3261 says so in 13.2.2.4. > ? ? * > ? ? * The pjsip_method_creates_dialog() check protects from wrongly > ? ? * freezing the route set upon receiving 200/OK response for PRACK. > ? ? */ > > After a quick read of the RFC, indeed, server should reply us with a correct > Route or accept our UDP ACK. > I don't understand well why it's defined like that in RFC (or why it's not > precised that we should reply an tcp request with a tcp ack even if route is > not specified and if we keep talking with the same server). > > (Just for info, that confirm it's the cause of the problem, if I just > prevent from route-set resetting here - returning before route rewritting in > this method - call continues over TCP and remote server is happy :) .... ) > > So... it's probably a problem with the server at this point. > > However, could it be possible we find a workaround to be compatible with > this kind of server (and keep using tcp)? > I did try sending to the TCP uri instead of having proxy set to route over > TCP; but no luck ! > > Besides if I try to register in TCP and then call in UDP on their servers, > they just reply me with a 404 cause (I think) they consider I'm not > registered as a valid user for UDP (it's pbxes.org... I assume that they use > a widely used server so maybe worth to have a compatibility option?). > > > > Regards, > R?gis > > > On 01/12/2010 01:05, R?gis Montoya wrote: >> >> ?Hi, >> >> Me again with another issue on re-INVITEs from server. >> >> This one is different from my previous mail. >> >> To sum up this problem : seems that if configured to use TCP, if server >> send a OK with multiple codecs, pjsip replies the ACK to 200 OK using UDP >> !!! :S >> >> Quick overview of what is observed in logs (tested on a fresh and clean >> built from the latest trunk using pjsua-app ... and reproduced also on my >> project) : >> >> > INVITE to <sip:*43 at pbxes.org> using tcp (sip proxy for this account has >> > the ;transport=tcp) >> < 407 Proxy Authentication Required (TCP) >> > ACK (TCP) >> > INVITE (TCP) >> < 100 Trying (TCP) >> < 200 OK (TCP) // multiple codecs here >> > ACK (UDP !!!!!) >> < 200 OK (TCP) .... >> //// the server didn't take our request into account since it doesn't know >> that we also can do UDP I think >> > ACK (UDP).... >> [and looping ...] >> Same thing if I try to send BYE... pjsip send over UDP and server ignore >> that ! >> >> If I do a previous test with UDP enabled everything will go fine and the >> server will continue using UDP... >> But if no UDP were done before server doesn't take our ACK into account. >> You could argue that server should not ignore our request using UDP >> however.... however I don't think that anyway that's correct to send the ACK >> using TCP while : >> * We are receiving from TCP >> * Account is configured to use sip proxy with ;transport=tcp.... >> >> I did try to attach the account to the TCP transport but no more luck (and >> there is strange behavior with TCP + account attach transport + contact >> rewriting, but I think that's another thing and as this method is never used >> by pjsip-apps, I don't think that's a good idea anyway). >> >> So let me know if I can provide you more detailed logs. But that's quietly >> easy to reproduce using a pbxes.org account, trying to register on TCP. >> Even if you tried on UDP before, you'll get the ACK sent over UDP - you'll >> not notice any "visible" bad behavior since in this case server doesn't >> ignore UDP requests, but I think that replying on UDP is not what is >> expected, isn't it? >> >> 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 >
