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
