Hello,
I am testing a cellphone software that registers with an Asterisk server through an outbound proxy (Kamailio+rtpproxy). I am capturing network traffic using wireshark and i notice that the SIP Register message from the cellphone has an extra byte in the Content-Length header, which causes Kamailio to discard the message with the following error output :
- ERROR:core:parse_content_length: parse error near char [13][^M] - ERROR:core:get_hdr_field: bad content_length header
Could it be that this byte was appended somewhere downstream(possibly at the wireless router..) or can i be sure that the byte was added during SIP Message construction by the cellphone software ?
Thanks in advance, Vikram.
El Martes, 9 de Febrero de 2010, Vikram Ragukumar escribió:
Could it be that this byte was appended somewhere downstream(possibly at the wireless router..) or can i be sure that the byte was added during SIP Message construction by the cellphone software ?
You cannot know it by just inspecting the request. You could be behind a fu***** SIP-ALG enabled router rewritting SIP requests "to fix the NAT".
You can get more information here: http://www.voip-info.org/wiki/view/Routers+SIP+ALG
To detect if you router has SIP-ALG enabled you can try various options:
1) Ensure you are not using STUN in your client so the request arriving to the proxy should contain client private address in Via and Contact header.
2) Try an utility I coded which detects if a host is behind a SIP-ALG enabled router: http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector
Iñaki,
Thank you for your response.
You could be behind a fu***** SIP-ALG enabled router rewritting SIP requests "to fix the NAT". To detect if you router has SIP-ALG enabled you can try various options:
- Ensure you are not using STUN in your client so the request arriving to the
proxy should contain client private address in Via and Contact header.
I have checked the Via and Contact headers and they do contain the client private address. I am using an SMC7004VWBR wireless router thats about 8 years old. I have checked all the router settings and do not see any option to enable/disable SIP ALG, so i presume the router is not capable of rewriting SIP headers.
I will try your program out as another method of confirmation of the router's SIP ALG capability.
I have found that this anomaly (extra byte in Contact-Length header)occurs only while sending to the proxy on a specific port(5060). By changing the port on which the proxy listens(7160), the Contact-length header field is ok.
Is there a list of routers out there that we know for sure that are not SIP ALG capable ?
Once again, thanks for you suggestions. Regards, Vikram.
Am 10.02.2010 02:15, schrieb Vikram Ragukumar:
Iñaki,
Thank you for your response.
You could be behind a fu***** SIP-ALG enabled router rewritting SIP requests "to fix the NAT". To detect if you router has SIP-ALG enabled you can try various options:
- Ensure you are not using STUN in your client so the request
arriving to the proxy should contain client private address in Via and Contact header.
I have checked the Via and Contact headers and they do contain the client private address. I am using an SMC7004VWBR wireless router thats about 8 years old. I have checked all the router settings and do not see any option to enable/disable SIP ALG, so i presume the router is not capable of rewriting SIP headers.
I will try your program out as another method of confirmation of the router's SIP ALG capability.
I have found that this anomaly (extra byte in Contact-Length header)occurs only while sending to the proxy on a specific port(5060). By changing the port on which the proxy listens(7160), the Contact-length header field is ok.
This would indicate a SIP ALG.
Klaus
Is there a list of routers out there that we know for sure that are not SIP ALG capable ?
Once again, thanks for you suggestions. Regards, Vikram.
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hello,
Just following up. Here is a link to a screen capture from Wireshark that shows the extra byte in the Content Length header field of the Register message.
http://signalogic.com/images/SMC7004VWBR_UDP_payload_with_SIP_message_gets_m...
We use an SMC7004VWBR router, but tech support at SMC said the router does not support SIP. Has anybody else seen a router make such a mod to a SIP message ?
Thanks and Regards, Vikram.
Vikram Ragukumar wrote:
Iñaki,
Thank you for your response.
You could be behind a fu***** SIP-ALG enabled router rewritting SIP requests "to fix the NAT". To detect if you router has SIP-ALG enabled you can try various options:
- Ensure you are not using STUN in your client so the request
arriving to the proxy should contain client private address in Via and Contact header.
I have checked the Via and Contact headers and they do contain the client private address. I am using an SMC7004VWBR wireless router thats about 8 years old. I have checked all the router settings and do not see any option to enable/disable SIP ALG, so i presume the router is not capable of rewriting SIP headers.
I will try your program out as another method of confirmation of the router's SIP ALG capability.
I have found that this anomaly (extra byte in Contact-Length header)occurs only while sending to the proxy on a specific port(5060). By changing the port on which the proxy listens(7160), the Contact-length header field is ok.
Is there a list of routers out there that we know for sure that are not SIP ALG capable ?
Once again, thanks for you suggestions. Regards, Vikram.
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Jueves, 11 de Febrero de 2010, Vikram Ragukumar escribió:
Hello,
Just following up. Here is a link to a screen capture from Wireshark that shows the extra byte in the Content Length header field of the Register message.
http://signalogic.com/images/SMC7004VWBR_UDP_payload_with_SIP_message_gets_ modified.jpg
We use an SMC7004VWBR router, but tech support at SMC said the router does not support SIP. Has anybody else seen a router make such a mod to a SIP message ?
I don't know that router but have dealed with other SMC routers and they *do* include SIP-ALG built-in, and the worst: it cannot be dissabled in any way!
Check at this page (the list of SIP-ALG routers): http://www.voip-info.org/wiki/view/Routers+SIP+ALG
So, if I understand correctly the Content-Length has the form: Content-Length: 0 0 ???
Iñaki-
El Jueves, 11 de Febrero de 2010, Vikram Ragukumar escribió:
Hello,
Just following up. Here is a link to a screen capture from Wireshark that shows the extra byte in the Content Length header field of the Register message.
http://signalogic.com/images/SMC7004VWBR_UDP_payload_with_SIP_message_gets_ modified.jpg
We use an SMC7004VWBR router, but tech support at SMC said the router does not support SIP. Has anybody else seen a router make such a mod to a SIP message ?
I don't know that router but have dealed with other SMC routers and they *do* include SIP-ALG built-in, and the worst: it cannot be dissabled in any way!
Check at this page (the list of SIP-ALG routers): http://www.voip-info.org/wiki/view/Routers+SIP+ALG
Yes we have seen that page, but it does not mention the SMC7004VWBR specifically. If it did we could send it to SMC tech support.
So, if I understand correctly the Content-Length has the form: Content-Length: 0 0
Yes. An extra zero (0x30).
-Jeff
El Jueves, 11 de Febrero de 2010, Jeff Brower escribió:
So, if I understand correctly the Content-Length has the form: Content-Length: 0 0
Could you check SIP traces into the same LAN (to avoid the possible SIP ALG)?
-
Iñaki Baz Castillo -
Jeff Brower -
Klaus Darilion -
Vikram Ragukumar