On Fri, Jan 30, 2009 at 11:39 AM, Johan Lantz <johan.lantz at genaker.net>wrote: > Hi Benny > Thanks for the reply on switching to tcp, it worked like a charm. For the > record I am quite confident that there is an issue when transmitting large > (2 segment) UDP packages in the 3G network. We tried different operators and > results were unreliable when segmenting UDP. There can be many reasons for > this but it seems as something more then just packet loss since > retransmissions did not work either, however with TCP it works as expected > with the drawback of latency increase. > > Is the latency really observable? And is it not because of the large size of the message which means that the message needs to be transmitted several times as fragments? > I would really like to implement the feature of switching to TCP when > packet size exceeds 1300 bytes but only for Requests not for Responses (the > spec only mentioned Requests). > > You right. Though still there are other scenarios where this switching wouldn't work, for example when the server needs to send large request to NAT'ed client. I have two questions though: > 1. If I only modify the Dest-Uri for an outgoing INVITE it is still sent > over UDP, as you say below this is due to the Route header. I wonder which > would be the appropriate way to handle the route header in a more flexible > way depending on the packet size. It seems to be connected to the pjsua_acc > and I am not sure but inside pjsua_acc_create_uac_contact(..) it seems like > the transport is decided when creating the UAC. Yes, we need the transport info there so that we can put suitable URI in the Contact header for the account. But the actual transport instance to be used to send each message will be determined later when each message is sent. > Is it still possible to modify it dynamically later on at the time when we > know the packet size? > > Maybe. But I don't think this is the right place to look, since this applies to the Contact header of the account, while what you're looking for is to switch the transport to TCP on transaction basis. > 2. Would this be possible to accomplish with a new module overriding > on_tx_request, if so on what level in the stack is it possible to get a > valid size of the message to be transmitted and at the same time inject the > upadated parameters. It feels like the message must have been built but not > sent to a specific transport yet, is this possible to achive in this way, > some pointers in the right direction would be highly appriciated. > > I don't think it's possible to do this with a module, since by the time on_tx_request callback is called, the transport has been selected. The design just doesn't cater this (for now). The place to put your code probably is in pjsip_endpt_send_request_stateless() function in sip_util.c. Here, you will need to encode the message into packet buffer so that you can know the approximate message size. I said it's an approximation, because it's possible that some modules may add headers into the message later in their on_tx_request() callback. You can copy paste the code in mod_on_tx_msg() function in sip_transport.c to encode the message (a much better solution is to add a new tdata API for this). When you determine that the request exceeds some limit, you can manipulate tdata->tp_sel to force TCP to be used. The message Request-URI and Route headers are still left intact though (e.g. no "transport=tcp" parameter will be added), I don't know if this is a good idea or not. The address and transport info in Via will be updated automatically later. I think that should do it. cheers Benny > Have a nice weekend > > Johan > > > Partly quoting Bennys reply. > > "No we don't do automatic switching to TCP. Personally I feel that the RFC > is > a bit too naive in this regard, ignoring scenarios such as NAT where you > can't just send response with TCP back to the client and expect it to just > work. So my take on this is if you think message size is going to cause > problem with UDP, then you should use TCP from the start." > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090131/a9169382/attachment.html>
