Hi,
Doing further step into this, I have realized that despite the SIP INVITE being
sent, I cannot create/associate a new dialogue or transaction that I'll need
for managing the SIP session.
So following the uac_req_send() I tried to do:
t_newtran();
record_route();
dlg_manage();
if(is_known_dlg()) {
xlog("Request $rm from $ci is in-dialog\n");
}
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=972 a=24 n=uac_req_send
9(44916) DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac:
next_hop=<sip:[email protected]:12060;rtcweb-breaker=no;transport=udp;ws-src-ip=81.84.0.236;ws-src-port=1025;ws-src-proto=ws>
9(44916) DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 39161
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=973 a=24 n=t_newtran
9(44916) DEBUG: tm [t_lookup.c:1312]: t_newtran(): DEBUG: t_newtran: msg id=1
, global msg id=0 , T on entrance=0xffffffffffffffff
9(44916) ERROR: tm [t_lookup.c:453]: t_lookup_request(): ERROR: TM module:
t_lookup_request: too few headers
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=974 a=24 n=record_route
9(44916) ERROR: <core> [parser/parse_from.c:53]: parse_from_header():
ERROR:parse_from_header: bad msg or missing FROM header
9(44916) ERROR: rr [record.c:407]: record_route(): From parsing failed
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=976 a=24 n=dlg_manage
9(44916) ERROR: dialog [dlg_handlers.c:1561]: dlg_manage(): bad TO header
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=985 a=16 n=if
9(44916) exec: *** cfgtrace:request_route=[SIP_INVITE]
c=[/etc/kamailio/kamailio.cfg] l=977 a=24 n=is_known_dlg
9(44916) ERROR: dialog [dlg_handlers.c:652]: pre_match_parse(): bad request or
missing CALLID/TO hdr :-/
Am I doing something wrong here, as it seems the headers fields are just being
"hardcoded" on the SIP INVITE are not updated on the context for that new
outbound session (and thus causing the typical dialogue/transaction functions
to fail...).
I realized already from one early comment I got from Alex Balashov that this is
not a typical usecase for kamailio (being a sip proxy), but is this a show
stopper?
Thanks,
Joao
-----Original Message-----
From: Joao Alves
Sent: quarta-feira, 22 de Julho de 2015 17:02
To: [email protected]
Subject: RE: [SR-Users] New SIP INVITE from UAS (new dialogue)
Hi Daniel,
Yes, you're right. It was fragmented at UDP level. I've repeated with TCP as
transport and the SDP is complete.
Thanks again,
Joao
-----Original Message-----
From: sr-users [mailto:[email protected]] On Behalf Of
Daniel Tryba
Sent: quarta-feira, 22 de Julho de 2015 16:39
To: [email protected]
Subject: Re: [SR-Users] New SIP INVITE from UAS (new dialogue)
On Wednesday 22 July 2015 14:01:02 Joao Alves wrote:
> In relation with the SDP size, I originally just compared with the
> source one (see attached). What I just did was to double check using
> an online tool and confirmed that the original has 1266 bytes (as also
> indicated by the Content's length) while the one sent has only 1077 bytes.
I saw the capture after my message. The message is fragmented and not shown
correctly in the capture. There shouldn't be any problem (unless there are
network issues between you and destination).
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
