Helmut Wolf wrote: > Hi Benny, > > I think I have found the bug. > > tdata->msg->body->print_body = generic_print_body(pjsip_msg_body *, char *, unsigned int) > > In generic_print_body(): > > Size = 442, body->len = 485 --> Because size < body->len the function doesn't copy the body and returns 0 which is the body length > in pjsip_msg_print(). I think generic_print_body() in this case must return -1, so pjsip_msg_print() returns -1 and mod_on_tx_msg() > then returns PJSIP_EMSGTOOLONG. Argh, I forgot about this function. I was looking at pjsip_print_text_body() which does the same thing, and couldn't find anything wrong with it. Thanks for the find. I removed generic_print_body() and replaced it with pjsip_print_text_body() in http://www.pjsip.org/trac/ticket/397 > I have tested it changing the return value to -1 in generic_print_body() and it seems to work. When receiving too big msg I get an > pj log " tsx009F3A2C Failed to send Request msg INVITE/cseq=2 (tdta009F19A8)! err=171023 (Message too long (PJSIP_EMSGTOOLONG))" and > 500 Internal Server Error is sended back. After increasing PJSIP_MAX_PKT_LEN to 3000 it works fine. > > Can I get problems (maybe with the stack) if PJSIP_MAX_PKT_LEN and PJ_LOG_MAX_SIZE are 3000 ? Is it better if > PJ_LOG_USE_STACK_BUFFER is 0 ? If so, can this decrease the performance ? The only problem with large packet size is with UDP fragmentation in the router. I found several NAT/home routers won't forward UDP packets with size >= 1500. Other than this there shouldn't be any problems in pjsip. We can only set PJ_LOG_USE_STACK_BUFFER to zero if the application is single threaded. In most modern OS'es stack size should be big enough for this use (IIRC it's ~2GB on WinNT) so it shouldn't be a problem for the buffer. regards, -benny > Best regards, > Helmut
