Ok, good approach. Didn't thought that it was possible with modules. Sounds to be a really clean way to solve this problem indeed. I'll have a closer look to pjsip_module. Thanks ! R?gis On 02/12/2010 12:56, Benny Prijono wrote: > 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 >> > _______________________________________________ > 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
