Is the field "Content-length" a required field in a NOTIFY message? I see that it is part of almost every message from OpenSER except the NOTIFY message. This is causing some issues with Gaim SIMPLe interface which processes the header based on the header string "Content-Length". Note Gaim does not care about the value associated with the header string just the fact that the string "Content-Length" exists. Therefore, since OpenSER isnt sending the string, Gaim is core dumping. FYI on the core dump. Yes, Gaim still has a bug on how it is processing what it sees as unknown SIP messages which actually is causing the core dump, the real problem is the fact that Gaim is processing the header, expecting to see the field "Content-length". So before I report this to Gaim as a bug, I wanted to get insight into whether the field is a required field.
Thanks......
Hi,
Thanks for reporting the problem. It's already fixed on cvs. Let me know if it works for you now.
Anca
Chris Robson wrote:
Is the field "Content-length" a required field in a NOTIFY message? I see that it is part of almost every message from OpenSER except the NOTIFY message. This is causing some issues with Gaim SIMPLe interface which processes the header based on the header string "Content-Length". Note Gaim does not care about the value associated with the header string just the fact that the string "Content-Length" exists. Therefore, since OpenSER isnt sending the string, Gaim is core dumping. FYI on the core dump. Yes, Gaim still has a bug on how it is processing what it sees as unknown SIP messages which actually is causing the core dump, the real problem is the fact that Gaim is processing the header, expecting to see the field "Content-length". So before I report this to Gaim as a bug, I wanted to get insight into whether the field is a required field.
Thanks......
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Anca
Finished some quick test this morning and indeed the CVS pulled this morning (29Nov06) has fixed the problem I was experiencing with the NOTIFY message. So the OpenSER piece to the Gaim SIMPLE client-to-client chat issues is fixed.
Thanks for the help....
Anca Vamanu wrote:
Hi,
Thanks for reporting the problem. It's already fixed on cvs. Let me know if it works for you now.
Anca
Chris Robson wrote:
Is the field "Content-length" a required field in a NOTIFY message? I see that it is part of almost every message from OpenSER except the NOTIFY message. This is causing some issues with Gaim SIMPLe interface which processes the header based on the header string "Content-Length". Note Gaim does not care about the value associated with the header string just the fact that the string "Content-Length" exists. Therefore, since OpenSER isnt sending the string, Gaim is core dumping. FYI on the core dump. Yes, Gaim still has a bug on how it is processing what it sees as unknown SIP messages which actually is causing the core dump, the real problem is the fact that Gaim is processing the header, expecting to see the field "Content-length". So before I report this to Gaim as a bug, I wanted to get insight into whether the field is a required field.
Thanks......
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Take a look at section 7.1 in RFC 3265:
t means that the header SHOULD be included when using UDP (datagram transport), but MUST be included when using TCP or TLS (stream transport).
regards klaus
Chris Robson wrote:
Is the field "Content-length" a required field in a NOTIFY message? I see that it is part of almost every message from OpenSER except the NOTIFY message. This is causing some issues with Gaim SIMPLe interface which processes the header based on the header string "Content-Length". Note Gaim does not care about the value associated with the header string just the fact that the string "Content-Length" exists. Therefore, since OpenSER isnt sending the string, Gaim is core dumping. FYI on the core dump. Yes, Gaim still has a bug on how it is processing what it sees as unknown SIP messages which actually is causing the core dump, the real problem is the fact that Gaim is processing the header, expecting to see the field "Content-length". So before I report this to Gaim as a bug, I wanted to get insight into whether the field is a required field.
Thanks......
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Thanks Klaus, for confirming what I thought, aka, if TCP is the transport then Content-Length "MUST" be used. Also, note I did get a reply from Anca (Voice-system), saying it was fixed in a cvs release (not sure which one yet). Thus I have some new testing to do.
Thanks again....
Klaus Darilion wrote:
Take a look at section 7.1 in RFC 3265:
t means that the header SHOULD be included when using UDP (datagram transport), but MUST be included when using TCP or TLS (stream transport).
regards klaus
Chris Robson wrote:
Is the field "Content-length" a required field in a NOTIFY message? I see that it is part of almost every message from OpenSER except the NOTIFY message. This is causing some issues with Gaim SIMPLe interface which processes the header based on the header string "Content-Length". Note Gaim does not care about the value associated with the header string just the fact that the string "Content-Length" exists. Therefore, since OpenSER isnt sending the string, Gaim is core dumping. FYI on the core dump. Yes, Gaim still has a bug on how it is processing what it sees as unknown SIP messages which actually is causing the core dump, the real problem is the fact that Gaim is processing the header, expecting to see the field "Content-length". So before I report this to Gaim as a bug, I wanted to get insight into whether the field is a required field.
Thanks......
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Chris,
the fix was done in CVS head (where the presence module is).
regards, bogdan
Chris Robson wrote:
Thanks Klaus, for confirming what I thought, aka, if TCP is the transport then Content-Length "MUST" be used. Also, note I did get a reply from Anca (Voice-system), saying it was fixed in a cvs release (not sure which one yet). Thus I have some new testing to do.