20 Apr
2011
20 Apr
'11
3:47 p.m.
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
20 Apr
20 Apr
3:52 p.m.
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
4:36 p.m.
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
4:41 p.m.
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
5:20 p.m.
Am 20.04.2011 16:41, schrieb Juha Heinanen:
Andreas Granig writes:
I think a constant branch wouldn't be RFC 3261 compliant
klaus
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.
5:22 p.m.
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
4762
days inactive
4762
days old
6 comments
4 participants
participants (4)
-
Andreas Granig -
Juha Heinanen -
Klaus Darilion -
marius zbihlei