[SR-Users] New SIP INVITE from UAS (new dialogue)

Daniel-Constantin Mierla miconda at gmail.com
Mon Jul 27 09:29:26 CEST 2015


Hello,

uac_req_send() is not creating a request that is available in config
file afterwards -- that function is sending out the request immediately
and that is, the config is processing whatever was there before
uac_req_send().

There are functions to send requests parts of dialog, but not exposed to
config file, there are inside tm module. For example, presence or dialog
modules are using those functions to send NOTIFY or BYE requests, which
need to within dialogs created by SUBSCRIBE or INVITE.

In other words, you need to write some C code to expose those functions
to config file or write a new module in C to implement the functionality
you need, replying internally on tm module (like it is done by presence
or dialog).

Cheers,
Daniel

On 24/07/15 19:28, Joao Alves wrote:
> 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:1000 at 188.165.231.30: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: sr-users at lists.sip-router.org
> 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:sr-users-bounces at lists.sip-router.org] On Behalf Of Daniel Tryba
> Sent: quarta-feira, 22 de Julho de 2015 16:39
> To: sr-users at lists.sip-router.org
> 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 sr-users at lists.sip-router.org 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
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com




More information about the sr-users mailing list