Hi,
When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g:
OPTIONS sip:192.168.51.1:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0. Route: <something>
Should be branch=z9hG4bK<something> instead of branch=0, right? When a reply comes back, like this...
SIP/2.0 100 Trying. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0;rport=5062. From: sip:pinger@<something>
... then kamailio logs this:
INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via
The full debug log looks like this:
DEBUG: <core> [parser_helpers.c:196]: path for branch: 'sip:lb@127.0.0.1:5060;lr;received=sip:192.168.51.1:5060' DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> DEBUG: <core> [parser/msg_parser.c:644]: status: <100> DEBUG: <core> [parser/msg_parser.c:646]: reason: <Trying> DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <0>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <5062>; state=16 DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG: <core> [receive.c:145]: After parse_msg... DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [23]; uri=[sip:192.168.51.1:5060] DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:192.168.51.1:5060#015#012] DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <OPTIONS> DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 DEBUG: <core> [parser/msg_parser.c:103]: found end of header INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)
Thanks, Andreas
On 04/20/2011 04:47 PM, Andreas Granig wrote:
Hi,
When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g:
OPTIONS sip:192.168.51.1:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0. Route:<something>
Hello
Check the syn_branch global parameter... must be 1 i think so that it creates a SIP 2.0 compliant branch. The default is imho bad and I will change it soon.
Marius
Should be branch=z9hG4bK<something> instead of branch=0, right? When a reply comes back, like this...
SIP/2.0 100 Trying. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0;rport=5062. From: sip:pinger@<something>
... then kamailio logs this:
INFO:<core> [forward.c:786]: broken reply to forward - no 2nd via
The full debug log looks like this:
DEBUG:<core> [parser_helpers.c:196]: path for branch: 'sip:lb@127.0.0.1:5060;lr;received=sip:192.168.51.1:5060' DEBUG:<core> [parser/msg_parser.c:640]: SIP Reply (status): DEBUG:<core> [parser/msg_parser.c:642]: version:<SIP/2.0> DEBUG:<core> [parser/msg_parser.c:644]: status:<100> DEBUG:<core> [parser/msg_parser.c:646]: reason:<Trying> DEBUG:<core> [parser/parse_via.c:1287]: Found param type 232,<branch> =<0>; state=6 DEBUG:<core> [parser/parse_via.c:1287]: Found param type 235,<rport> = <5062>; state=16 DEBUG:<core> [parser/parse_via.c:2300]: end of header reached, state=5 DEBUG:<core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG:<core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG:<core> [receive.c:145]: After parse_msg... DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff DEBUG:<core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG:<core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field:<To> [23]; uri=[sip:192.168.51.1:5060] DEBUG:<core> [parser/msg_parser.c:189]: DEBUG: to body [sip:192.168.51.1:5060#015#012] DEBUG:<core> [parser/msg_parser.c:167]: get_hdr_field: cseq<CSeq>:<1>
<OPTIONS> DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) DEBUG:<core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 DEBUG:<core> [parser/msg_parser.c:103]: found end of header INFO:<core> [forward.c:786]: broken reply to forward - no 2nd via DEBUG:<core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)
Thanks, Andreas
Hi,
On 04/20/2011 04:05 PM, Juha Heinanen wrote:
for rfc3261 compliance, it needs to be 0. see 'about syn_branch' sr-users thread.
That's my understanding now also, however it doesn't fix the (cosmetical - at least for me) branch=0 issue with locally generated OPTIONS requests in the nathelper module:
OPTIONS sip:192.168.51.1:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0
Andreas
Andreas Granig writes:
That's my understanding now also, however it doesn't fix the (cosmetical
- at least for me) branch=0 issue with locally generated OPTIONS
requests in the nathelper module:
OPTIONS sip:192.168.51.1:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0
ok, i haven't used those and didn't know that branch=0 doesn't fix the issue there. in order to save cpu cycles, by suggestion was to use a constant rfc3261 compliant branch value instead of 0.
-- juha
Am 20.04.2011 16:41, schrieb Juha Heinanen:
Andreas Granig writes:
That's my understanding now also, however it doesn't fix the (cosmetical
- at least for me) branch=0 issue with locally generated OPTIONS
requests in the nathelper module:
OPTIONS sip:192.168.51.1:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0
ok, i haven't used those and didn't know that branch=0 doesn't fix the issue there. in order to save cpu cycles, by suggestion was to use a constant rfc3261 compliant branch value instead of 0.
I think a constant branch wouldn't be RFC 3261 compliant
klaus
Klaus Darilion writes:
I think a constant branch wouldn't be RFC 3261 compliant.
perhaps not, but at least it is harder to detect non-compliant than 0 when use of 0 has been justified by need to save cpu cycles.
in my opinion, default should be rfc3261 compliant branch value.
-- juha
-
Andreas Granig -
Juha Heinanen -
Klaus Darilion -
marius zbihlei