Hello!
After proxying a REGISTER from a WebRTC client to our SIP backend, the backend starts sending keepalives. Every 30 seconds I get a log entry in Kamailio saying: "INFO: stun [kam_stun.c:169]: stun_parse_header(): INFO: stun_parse_header: incomplete header of STUN message".
Here's one such packet:
No. Time Source Destination Protocol Length Info 1 0.000000 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy UDP 60 5060 ? 15060 Len=4
Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: JuniperN_4f:3f:f0 (40:a6:77:4f:3f:f0), Dst: 02:81:64:58:cf:d1 (02:81:64:58:cf:d1) Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: yyy.yyy.yyy.yyy 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 32 Identification: 0x5bf5 (23541) Flags: 0x4000, Don't fragment Time to live: 56 Protocol: UDP (17) Header checksum: 0x2fc3 [validation disabled] [Header checksum status: Unverified] Source: xxx.xxx.xxx.xxx Destination: yyy.yyy.yyy.yyy User Datagram Protocol, Src Port: 5060, Dst Port: 15060 Source Port: 5060 Destination Port: 15060 Length: 12 Checksum: 0xfa28 [unverified] [Checksum Status: Unverified] [Stream index: 0] Data (4 bytes)
0000 00 00 00 00 .... Data: 00000000 [Length: 4]
I found this in kam_stun.c:
static int stun_parse_header(struct stun_msg* req, USHORT_T* error_code) {
if (sizeof(req->hdr) > req->msg.buf.len) { /* the received message does not contain whole header */ LOG(L_INFO, "INFO: stun_parse_header: incomplete header of STUN message\n"); /* Any better solution? IMHO it's not possible to send error response * because the transaction ID is not available. */ return FATAL_ERROR; } ...
Could someone please explain what's wrong?
Med vennlig hilsen Pan B. Christensen Utvikler
Phonect AS Brugata 19, PB 9156 Grønland, N-0133 Oslo, Norway E-post: pan.christensen@phonect.nomailto:pan.christensen@phonect.no Mobil: 41 88 88 00
[cid:image007.png@01D3A0E8.376921D0] http://www.phonect.no/ [facebook_2]https://www.facebook.com/phonectno [LinkedIn_logo_initials (1)] https://www.linkedin.com/company/44983?trk=tyah&trkInfo=clickedVertical%3Acompany%2CentityType%3AentityHistoryName%2CclickedEntityId%3Acompany_company_44983%2Cidx%3A0
Hello,
you can ignore those messages, they are info level, so for a quick fix you can decrease the debug value not to get them printed. These packets are the udp nat keepalives.
For the future, I just pushed a patch to silent such cases via commit:
- https://github.com/kamailio/kamailio/commit/7e08fc8d2b74657d6e6171effbab2770...
You can eventually use the patch in your local copy, I plan to I backport as well, but it would be good if you can test and report that all goes fine with the patch, I don't have any easy option to test it right now.
Cheers, Daniel
On 29.05.18 11:31, Pan Christensen wrote:
Hello!
After proxying a REGISTER from a WebRTC client to our SIP backend, the backend starts sending keepalives. Every 30 seconds I get a log entry in Kamailio saying: “INFO: stun [kam_stun.c:169]: stun_parse_header(): INFO: stun_parse_header: incomplete header of STUN message”.
Here's one such packet:
No. Time Source Destination Protocol Length Info
1 0.000000 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy UDP 60 5060 ? 15060 Len=4
Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: JuniperN_4f:3f:f0 (40:a6:77:4f:3f:f0), Dst: 02:81:64:58:cf:d1 (02:81:64:58:cf:d1)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: yyy.yyy.yyy.yyy
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 32
Identification: 0x5bf5 (23541)
Flags: 0x4000, Don't fragment
Time to live: 56
Protocol: UDP (17)
Header checksum: 0x2fc3 [validation disabled]
[Header checksum status: Unverified]
Source: xxx.xxx.xxx.xxx
Destination: yyy.yyy.yyy.yyy
User Datagram Protocol, Src Port: 5060, Dst Port: 15060
Source Port: 5060
Destination Port: 15060
Length: 12
Checksum: 0xfa28 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Data (4 bytes)
0000 00 00 00 00 ....
Data: 00000000
[Length: 4]
I found this in kam_stun.c:
static int stun_parse_header(struct stun_msg* req, USHORT_T* error_code)
{
if (sizeof(req->hdr) > req->msg.buf.len) {
/* the received message does not contain whole header */
LOG(L_INFO, "INFO: stun_parse_header: incomplete header of STUN message\n");
/* Any better solution? IMHO it's not possible to send error response
* because the transaction ID is not available.
*/
return FATAL_ERROR;
}
…
Could someone please explain what’s wrong?
Med vennlig hilsen *Pan B. Christensen* Utvikler
Phonect AS Brugata 19, PB 9156 Grønland, N-0133 Oslo, Norway E-post: pan.christensen@phonect.no mailto:pan.christensen@phonect.no Mobil: 41 88 88 00
cid:image007.png@01D3A0E8.376921D0 http://www.phonect.no/
facebook_2 https://www.facebook.com/phonectno LinkedIn_logo_initials (1) https://www.linkedin.com/company/44983?trk=tyah&trkInfo=clickedVertical%3Acompany%2CentityType%3AentityHistoryName%2CclickedEntityId%3Acompany_company_44983%2Cidx%3A0
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Dear Daniel.
Thanks for your quick reply and fix.
The proper solution for us is to make the backend stop sending keepalives as they are not needed in this case. I've asked our supplier about this as I couldn't find an option for it. I'm assuming that the backend incorrectly detects NAT and then automatically sends these packets.
I'm not a C programmer, but the fix looks good to me.
With kind regards Pan B. Christensen Developer Phonect AS
Hello,
traffic from webrtc endpoints is always considered to be like from behind the nat, because javascript in browser cannot get the local IP, so it uses a fake one.
Cheers, Daniel
On 29.05.18 14:21, Pan Christensen wrote:
Dear Daniel.
Thanks for your quick reply and fix.
The proper solution for us is to make the backend stop sending keepalives as they are not needed in this case. I’ve asked our supplier about this as I couldn’t find an option for it. I’m assuming that the backend incorrectly detects NAT and then automatically sends these packets.
I’m not a C programmer, but the fix looks good to me.
With kind regards *Pan B. Christensen* Developer Phonect AS
-
Daniel-Constantin Mierla -
Pan Christensen