19 Jun
2015
19 Jun
'15
10:53 a.m.
Hi,
What would be the best way to generate and send an INVITE message generated by the
Kamailio server. This would be for a new dialog session, UAS initiated (e.g. to make a
click 2 call like service).
I've tried the $uac_req(method)="INVITE"; uac_req_send(); but didn't
work. I gather something would be needed first to open the dialogue before doing it but
couldn't find it on the dialogue module.
Thanks,
Joao Alves
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
19 Jun
19 Jun
3:27 p.m.
Hello Joao,
As a general rule, speaking broadly and methodologically, Kamailio - as
a SIP proxy - is not a good vehicle for the initiation of calls, since
it cannot, itself, be a party to a dialog. Synthesising an INVITE using
uac_req_send() isn't going to work because there's no second party to
the dialog. Where will the replies to the INVITE go? Kamailio itself
cannot be a party.
There are, nevertheless, the ways to initiate a call from Kamailio using
the 'dialog' module. The most straightforward is probably the
'dlg_bridge' / 'dlg.bridge' (MI and RPC respectively) commands, which
can be called externally to Kamailio,
http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3756384
or internally from route script, via the dlg_bridge() command:
http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3698368
The general idea here is that an INVITE is initiated to one party and
then that party is REFER'd out to another party. REFER is a SIP method
that is commonly used for unattended transfers and call forwarding. You
can read more about it here:
https://www.ietf.org/rfc/rfc3515.txt
Of course, for it to work, party #1 has to support REFER.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
4:30 p.m.
Hi Alex,
I do realize Kamailio to be a SIP proxy and, as you said, Kamailio may not be the best
place to do a HTTP <> SIP gateway. I start to realize as time goes by...:)
However, at least managing incoming SIP sessions and converting those to HTTP using
http_query() although didn't go very smooth, but at the end, results are quite
positive.
Now was starting doing the other direction HTTP=> SIP and using xhttp_reply() noticed
was not so much available to start a dialogue and hence this email - as new starter in
kamailio there are many modules and functions that not aware of and this asking to the
expert's community.
Tell me one thing. If was not a SIP INVITE but just a SIP INFO or SIP MESSAGE (since are
stateless), would it be easier to do?
I'll be off next week, but I'll comeback to this the week after.
All inputs are welcome!
Thanks
Joao
-----Original Message-----
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: sexta-feira, 19 de Junho de 2015 20:28
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] New SIP INVITE from UAS (new dialogue)
Hello Joao,
As a general rule, speaking broadly and methodologically, Kamailio - as a SIP proxy - is
not a good vehicle for the initiation of calls, since it cannot, itself, be a party to a
dialog. Synthesising an INVITE using
uac_req_send() isn't going to work because there's no second party to the dialog.
Where will the replies to the INVITE go? Kamailio itself cannot be a party.
There are, nevertheless, the ways to initiate a call from Kamailio using the
'dialog' module. The most straightforward is probably the 'dlg_bridge' /
'dlg.bridge' (MI and RPC respectively) commands, which can be called externally to
Kamailio,
http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3756384
or internally from route script, via the dlg_bridge() command:
http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3698368
The general idea here is that an INVITE is initiated to one party and then that party is
REFER'd out to another party. REFER is a SIP method that is commonly used for
unattended transfers and call forwarding. You can read more about it here:
https://www.ietf.org/rfc/rfc3515.txt
Of course, for it to work, party #1 has to support REFER.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
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
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
5:11 p.m.
On 06/19/2015 04:30 PM, Joao Alves wrote:
Tell me one thing. If was not a SIP INVITE but just a
SIP INFO or SIP
MESSAGE (since are stateless), would it be easier to do?
Yes, those would be more viable.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
22 Jul
22 Jul
8:37 a.m.
Hi again,
Following up on this and having done some further tests, I was finally able to generate a
SIP INVITE request using the following command sequence on the command file.
$uac_req(method)="INVITE";
$uac_req(ruri)=$shv(userAcontact);
$uac_req(turi)="sip:1000@decasa.website";
$uac_req(furi)="sip:1001@decasa.website";
$uac_req(callid)=$var(call_id);
$uac_req(hdrs)="Contact: <sip:1001@151.236.52.84:5060;transport=udp\r\n";
$uac_req(hdrs)="Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE\r\n";
$uac_req(hdrs)="Content-Type: application/sdp\r\n";
$uac_req(body)=$var(offer);
uac_req_send();
I've attached the trace collected on the client side. Transaction/dialogue wise seems
to have the correct behavior, however I found two blocking issues which are causing the
SIP INVITE to be rejected with a 400 "bad request" error code.
The first, it seems we cannot send more than one header on the SIP INVITE. That is I need
to add the "Contact", "Allow" and "Content-Type" fields, but
only the last one is inserted, which is the "Content-Type". If I marked it as a
comment (with #), them the "Allow" is included instead.
The second issue is related with the inclusion of SDP offer on the body of the message.
Since this SDP is quite a long one(1266 bytes) it is being truncated.
I'm currently using kamailio 4.3.0.
Thanks,
Joao
-----Original Message-----
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: sexta-feira, 19 de Junho de 2015 22:11
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] New SIP INVITE from UAS (new dialogue)
On 06/19/2015 04:30 PM, Joao Alves wrote:
Tell me one thing. If was not a SIP INVITE but just a
SIP INFO or SIP
MESSAGE (since are stateless), would it be easier to do?
Yes, those would be more viable.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
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
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
8:58 a.m.
On Wednesday 22 July 2015 12:37:58 Joao Alves wrote:
The first, it seems we cannot send more than one
header on the SIP INVITE.
That is I need to add the "Contact", "Allow" and
"Content-Type" fields, but
only the last one is inserted, which is the "Content-Type". If I marked it
as a comment (with #), them the "Allow" is included instead.
A quick solution could be:
$uac_req(hdrs)="Contact:..\r\nAllow:..\r\nContent-type: application/sdp\r\n";
The second issue is related with the inclusion of SDP
offer on the body of
the message. Since this SDP is quite a long one(1266 bytes) it is being
truncated.
Where? How did you check this?
10:01 a.m.
Hi Daniel,
For the first issue, your solution did work!
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.
Many Thanks,
Joao
-----Original Message-----
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel Tryba
Sent: quarta-feira, 22 de Julho de 2015 13:58
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] New SIP INVITE from UAS (new dialogue)
On Wednesday 22 July 2015 12:37:58 Joao Alves wrote:
The first, it seems we cannot send more than one
header on the SIP INVITE.
That is I need to add the "Contact", "Allow" and
"Content-Type"
fields, but only the last one is inserted, which is the
"Content-Type". If I marked it as a comment (with #), them the
"Allow" is included instead.
A quick solution could be:
$uac_req(hdrs)="Contact:..\r\nAllow:..\r\nContent-type: application/sdp\r\n";
The second issue is related with the inclusion of SDP
offer on the
body of the message. Since this SDP is quite a long one(1266 bytes) it
is being truncated.
Where? How did you check this?
_______________________________________________
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
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
11:39 a.m.
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).
12:02 p.m.
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@lists.sip-router.org] On Behalf Of Daniel Tryba
Sent: quarta-feira, 22 de Julho de 2015 16:39
To: sr-users(a)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(a)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
24 Jul
24 Jul
1:28 p.m.
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@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(a)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@lists.sip-router.org] On Behalf Of Daniel Tryba
Sent: quarta-feira, 22 de Julho de 2015 16:39
To: sr-users(a)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(a)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
27 Jul
27 Jul
3:29 a.m.
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@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(a)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@lists.sip-router.org] On Behalf Of Daniel Tryba
Sent: quarta-feira, 22 de Julho de 2015 16:39
To: sr-users(a)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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3448
days inactive
3486
days old
10 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel Tryba -
Daniel-Constantin Mierla -
Joao Alves