You are right! There are actually 2 issues with pjsip:
- UDP6 transport does not support DNS lookups. Thus you must set an
outboundproxy with IPv6 address
- pjsua API does not handle IPv6 media (SDP)
As Qjsimple is based on pjsip's pjsua API QjSimple of course has the
same issue.
regards
klaus
Am 21.04.2011 14:05, schrieb Pavel Segeč:
> Klaus,
>
> still the same,
>
> here is a log when UDP is used, there is only A record resolving
>
> QjSimple: starting initialization/registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: registration_enabled=TRUE
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
> QjSimple: Info: on_reg_state_slot called
> QjSimple: Info: on_reg_state_slot: status=502
> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway
> QjSimple: Info: on_reg_state_slot called
> QjSimple: Info: on_reg_state_slot: status=502
> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway
>
> and here when UDP6
>
> QjSimple: starting initialization/registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP6 transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: registration_enabled=TRUE
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
>
> there is no DNS at all
>
> pavel
>
>
>> -----Original Message-----
>> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-
>> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion
>> Sent: Thursday, April 21, 2011 1:27 PM
>> To: sr-users(a)lists.sip-router.org
>> Subject: Re: [SR-Users] Ipv6 SIP UA
>>
>> Pavel, I have updated QjSimple to latest pjsip version (0.8.10). It
>> would be great if you can test again. If the problem still exists I will
>> post a bug report for pjsip.
>>
>> http://www.ipcom.at/fileadmin/ipcom/files/qjsimple/QjSimple-0.6.6.zip
>>
>> regards
>> Klaus
>>
>> Am 21.04.2011 10:10, schrieb Pavel Segeč:
>>> Hi Klaus,
>>>
>>> I'm testing your QJSimple client and I'm observing following problems.
>> In a IPv4 environments (win 7/32 or 64bit), the client is using a
>> classical DNS resolving with SRV and so on, and I'm able to register.
>> But inside of the IPV6 environment (IPv4 disabled), when UDP transport
>> is used, the client is making just the A DNS record resolving on my
>> domain name, not SRV at all.
>>>
>>> Here is debug log:
>>>
>>> QjSimple: starting registration ...
>>> QjSimple: initializing SIP stack ...
>>> QjSimple: pjsua_create succeeded ...
>>> QjSimple: "qjsimple" memory pool created ...
>>> QjSimple: DLL loaded ...
>>> QjSimple: GetNetworkParams found ...
>>> QjSimple: GetNetworkParams done ...
>>> QjSimple: cfg.nameserver_count=0
>>> QjSimple: pjsua_init succeeded ...
>>> QjSimple: pjsip_endpt_register_module succeeded ...
>>> QjSimple: adding UDP transport ...
>>> QjSimple: pjsip_endpt_register_module succeeded ...
>>> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
>>> QjSimple: publish_enabled=FALSE
>>> QjSimple: pjsua_acc_add succeeded ...
>>> QjSimple: finished intializing SIP stack, start pjsua ...
>>> QjSimple: initializing SIP stack ... done
>>> QjSimple: Info: on_reg_state_slot called
>>> QjSimple: Info: on_reg_state_slot: status=502
>>> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway
>>>
>>> When I setup as the transport protocol UDP6 there is no actions at
>> all, no dns, no sip, he re is debug log
>>>
>>> QjSimple: starting registration ...
>>> QjSimple: initializing SIP stack ...
>>> QjSimple: pjsua_create succeeded ...
>>> QjSimple: "qjsimple" memory pool created ...
>>> QjSimple: DLL loaded ...
>>> QjSimple: GetNetworkParams found ...
>>> QjSimple: GetNetworkParams done ...
>>> QjSimple: cfg.nameserver_count=0
>>> QjSimple: pjsua_init succeeded ...
>>> QjSimple: pjsip_endpt_register_module succeeded ...
>>> QjSimple: adding UDP6 transport ...
>>> QjSimple: pjsip_endpt_register_module succeeded ...
>>> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
>>> QjSimple: publish_enabled=FALSE
>>> QjSimple: pjsua_acc_add succeeded ...
>>> QjSimple: finished intializing SIP stack, start pjsua ...
>>> QjSimple: initializing SIP stack ... done
>>>
>>> regards
>>>
>>> pavel
>>>
>>>> -----Original Message-----
>>>> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-
>>>> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion
>>>> Sent: Wednesday, April 20, 2011 12:49 PM
>>>> To: sr-users(a)lists.sip-router.org
>>>> Subject: Re: [SR-Users] Ipv6 SIP UA
>>>>
>>>>
>>>>
>>>> Am 20.04.2011 11:01, schrieb Pavel Segeč:
>>>>> Hi,
>>>>>
>>>>> yes I can agree now, linphone is working well, qjsimple has some
>>>> problem
>>>>
>>>> If you find some problems (except that it does not work over TCL/TLS:
>>>> http://trac.pjsip.org/repos/ticket/1127) please let me know.
>>>>
>>>> klaus
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057
>>>> (20110420) __________
>>>>
>>>> Tuto spravu preveril ESET NOD32 Antivirus.
>>>>
>>>> http://www.eset.sk
>>>>
>>>>
>>>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
>>>> (20110420) __________
>>>>
>>>> Tuto spravu preveril ESET NOD32 Antivirus.
>>>>
>>>> http://www.eset.sk
>>>>
>>>
>>>
>>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
>> (20110420) __________
>>>
>>> Tuto spravu preveril ESET NOD32 Antivirus.
>>>
>>> http://www.eset.sk
>>>
>>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6060
>> (20110421) __________
>>
>> Tuto spravu preveril ESET NOD32 Antivirus.
>>
>> http://www.eset.sk
>>
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6060 (20110421) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
I'm using Kamailio 3.1
I have a custom routing statement called MYROUTE which is placed like
this:
route { ... route (MYROUTE); route (RELAY);}
Inside MYROUTE I do some custom SQL checking that basically selects
the least cost provider for the ongoing call. The MYROUTE routine sets
the $rU, $rd and $rp variables in case a provider has been found for
the dialed number or fails with Sip code 404.
All this works perfectly, except in my database I also have an
alternate provider that I only wish to use as backup in case the main
provider returns a 5XX code.
How do I get Kamailio to try the second provider after the first one
failed ?
So far I've tried setting up a t_on_failure() command & routine that
picks up the backup provider from the database and sets $rU, $rd
margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;">
0(11460) DEBUG: [parser/msg_parser.c:167]: get_hdr_field: cseq :
0(11460) DEBUG: [parser/msg_parser.c:201]: DEBUG: get_hdr_body :
content_length=0 0(11460) DEBUG: [parser/msg_parser.c:103]: found
end of header 0(11460) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards
header not found! 0(11460) DEBUG: [parser/parse_to.c:174]: DEBUG:
add_param: tag=4a2aab60 0(11460) DEBUG: [parser/parse_to.c:803]:
end of header reached, state=29 0(11460) DEBUG: siputils
[checks.c:76]: totag found 0(11460) DEBUG: rr [loose.c:108]: No
Route headers found 0(11460) DEBUG: rr [loose.c:910]: There is no
Route HF
I believe the problem is that t_on_failure() does not keep all the
proper data associated with the call and that's why it fails. Maybe
t_on_failure isn't the right command to use here after all (?).
So to resume. Here's what I wish to achieve:
1 Call comes through2. Goes through MYROUTE where a provider is
selected3. Call is attempted through provider found in #24. If call
fails , select another provider5. Call is attempted through provider
found in #4
Thanks!
I'm using Kamailio 3.1
I have a custom routing statement called MYROUTE which is placed like
this:
route { ... route (MYROUTE); route (RELAY);}
Inside MYROUTE I do some custom SQL checking that basically selects
the least cost provider for the ongoing call. The MYROUTE routine sets
the $rU, $rd and $rp variables in case a provider has been found for
the dialed number or fails with Sip code 404.
All this works perfectly, except in my database I also have an
alternate provider that I only wish to use as backup in case the main
provider returns a 5XX code.
How do I get Kamailio to try the second provider after the first one
failed ?
So far I've tried setting up a t_on_failure() command & routine that
picks up the backup provider from the database and sets $rU, $rd
margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;">
0(11460) DEBUG: [parser/msg_parser.c:167]: get_hdr_field: cseq :
0(11460) DEBUG: [parser/msg_parser.c:201]: DEBUG: get_hdr_body :
content_length=0 0(11460) DEBUG: [parser/msg_parser.c:103]: found
end of header 0(11460) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards
header not found! 0(11460) DEBUG: [parser/parse_to.c:174]: DEBUG:
add_param: tag=4a2aab60 0(11460) DEBUG: [parser/parse_to.c:803]:
end of header reached, state=29 0(11460) DEBUG: siputils
[checks.c:76]: totag found 0(11460) DEBUG: rr [loose.c:108]: No
Route headers found 0(11460) DEBUG: rr [loose.c:910]: There is no
Route HF
I believe the problem is that t_on_failure() does not keep all the
proper data associated with the call and that's why it fails. Maybe
t_on_failure isn't the right command to use here after all (?).
So to resume. Here's what I wish to achieve:
1 Call comes through2. Goes through MYROUTE where a provider is
selected3. Call is attempted through provider found in #24. If call
fails , select another provider5. Call is attempted through provider
found in #4
Thanks!
Hello,
I want to announce Jason Penton as a new registered developer, with
write access to GIT repository - his username id is 'jason.penton'.
Jason already submitted an IMS-related module that Carsten added to his
IMS branch in the last days, therefore expect contributions from Jason
in the IMS extensions.
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Pavel, I have updated QjSimple to latest pjsip version (0.8.10). It
would be great if you can test again. If the problem still exists I will
post a bug report for pjsip.
http://www.ipcom.at/fileadmin/ipcom/files/qjsimple/QjSimple-0.6.6.zip
regards
Klaus
Am 21.04.2011 10:10, schrieb Pavel Segeč:
> Hi Klaus,
>
> I'm testing your QJSimple client and I'm observing following problems. In a IPv4 environments (win 7/32 or 64bit), the client is using a classical DNS resolving with SRV and so on, and I'm able to register. But inside of the IPV6 environment (IPv4 disabled), when UDP transport is used, the client is making just the A DNS record resolving on my domain name, not SRV at all.
>
> Here is debug log:
>
> QjSimple: starting registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
> QjSimple: initializing SIP stack ... done
> QjSimple: Info: on_reg_state_slot called
> QjSimple: Info: on_reg_state_slot: status=502
> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway
>
> When I setup as the transport protocol UDP6 there is no actions at all, no dns, no sip, he re is debug log
>
> QjSimple: starting registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP6 transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
> QjSimple: initializing SIP stack ... done
>
> regards
>
> pavel
>
>> -----Original Message-----
>> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-
>> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion
>> Sent: Wednesday, April 20, 2011 12:49 PM
>> To: sr-users(a)lists.sip-router.org
>> Subject: Re: [SR-Users] Ipv6 SIP UA
>>
>>
>>
>> Am 20.04.2011 11:01, schrieb Pavel Segeč:
>>> Hi,
>>>
>>> yes I can agree now, linphone is working well, qjsimple has some
>> problem
>>
>> If you find some problems (except that it does not work over TCL/TLS:
>> http://trac.pjsip.org/repos/ticket/1127) please let me know.
>>
>> klaus
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057
>> (20110420) __________
>>
>> Tuto spravu preveril ESET NOD32 Antivirus.
>>
>> http://www.eset.sk
>>
>>
>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
>> (20110420) __________
>>
>> Tuto spravu preveril ESET NOD32 Antivirus.
>>
>> http://www.eset.sk
>>
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 (20110420) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
>
Hi,
and the IMS Boghe client can be used for IPv6 call testing too.
pavel
> -----Original Message-----
> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-
> bounces(a)lists.sip-router.org] On Behalf Of Pavel Segeč
> Sent: Thursday, April 21, 2011 10:10 AM
> To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List'
> Subject: Re: [SR-Users] Ipv6 SIP UA
>
> Hi Klaus,
>
> I'm testing your QJSimple client and I'm observing following problems.
> In a IPv4 environments (win 7/32 or 64bit), the client is using a
> classical DNS resolving with SRV and so on, and I'm able to register.
> But inside of the IPV6 environment (IPv4 disabled), when UDP transport
> is used, the client is making just the A DNS record resolving on my
> domain name, not SRV at all.
>
> Here is debug log:
>
> QjSimple: starting registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
> QjSimple: initializing SIP stack ... done
> QjSimple: Info: on_reg_state_slot called
> QjSimple: Info: on_reg_state_slot: status=502
> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway
>
> When I setup as the transport protocol UDP6 there is no actions at all,
> no dns, no sip, he re is debug log
>
> QjSimple: starting registration ...
> QjSimple: initializing SIP stack ...
> QjSimple: pjsua_create succeeded ...
> QjSimple: "qjsimple" memory pool created ...
> QjSimple: DLL loaded ...
> QjSimple: GetNetworkParams found ...
> QjSimple: GetNetworkParams done ...
> QjSimple: cfg.nameserver_count=0
> QjSimple: pjsua_init succeeded ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: adding UDP6 transport ...
> QjSimple: pjsip_endpt_register_module succeeded ...
> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp
> QjSimple: publish_enabled=FALSE
> QjSimple: pjsua_acc_add succeeded ...
> QjSimple: finished intializing SIP stack, start pjsua ...
> QjSimple: initializing SIP stack ... done
>
> regards
>
> pavel
>
> > -----Original Message-----
> > From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-
> > bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion
> > Sent: Wednesday, April 20, 2011 12:49 PM
> > To: sr-users(a)lists.sip-router.org
> > Subject: Re: [SR-Users] Ipv6 SIP UA
> >
> >
> >
> > Am 20.04.2011 11:01, schrieb Pavel Segeč:
> > > Hi,
> > >
> > > yes I can agree now, linphone is working well, qjsimple has some
> > problem
> >
> > If you find some problems (except that it does not work over TCL/TLS:
> > http://trac.pjsip.org/repos/ticket/1127) please let me know.
> >
> > klaus
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> > sr-users(a)lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057
> > (20110420) __________
> >
> > Tuto spravu preveril ESET NOD32 Antivirus.
> >
> > http://www.eset.sk
> >
> >
> > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
> > (20110420) __________
> >
> > Tuto spravu preveril ESET NOD32 Antivirus.
> >
> > http://www.eset.sk
> >
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
> (20110420) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059
> (20110420) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
__________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 (20110420) __________
Tuto spravu preveril ESET NOD32 Antivirus.
http://www.eset.sk
Am 20.04.2011 11:01, schrieb Pavel Segeč:
> Hi,
>
> yes I can agree now, linphone is working well, qjsimple has some problem
If you find some problems (except that it does not work over TCL/TLS:
http://trac.pjsip.org/repos/ticket/1127) please let me know.
klaus
looks like core stats counts xmlrpc requests served by
route [xmlrpc_requests]
as unsupported_methods.
is there anything a user can do about it or is it a bug that should be
fixed?
-- juha
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