sr-users

sr-users@lists.kamailio.org

49 participants
37556 discussions

UDP-TCP bridging in-dialog SUBSCRIBE
by Dan Christian Bogos 12 Nov '14

12 Nov '14

Hey Guys, I have the following scenario: UA1 (UDP) -> Kamailio Proxy -> (TCP) UA2 As per the signaling sample, I would expect that in-dialog SUBSCRIBEs are bridged between UDP and TCP network but for some reason this does not happen (the subscribe comes in over UDP and leaves still over UDP although tcp is present in the route headers). Are we somehow forced to mangle contact header and add transport parameter to it or the record-route headers should serve for this purpose? Any tip would be highly appreciated. Ta, DanB Bellow the traces for initial SUBSCRIBEs as well as in-dialog ones (info mangled to protect privacy). ##################################### Normally routed request (non-dialog one, correctly bridged) ##################################### """ # U 2014/11/12 19:04:51.293887 pub_ip_ua:54705 -> pub_ip_ep:5060 SUBSCRIBE sip:user1@fakedomain.com:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK1114302228. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062>. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.295706 pub_ip_ep:34052 -> 192.168.51.168:5060 [AP] SUBSCRIBE sip:user1@192.168.51.168:5060;transport=tcp SIP/2.0. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062;alias=pub_ip_ua~54705~1>. Accept: application/dialog-info+xml. Max-Forwards: 65. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.300350 192.168.51.168:5060 -> pub_ip_ep:34052 [AP] SIP/2.0 202 Accepted. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0;rport=34052. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user1@192.168.51.168:5060>. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. . ## U 2014/11/12 19:04:51.300745 pub_ip_ep:5060 -> pub_ip_ua:54705 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user1@192.168.51.168:5060>. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. """ ###################### NOT BRIDGED, IN-DIALOG requests: ###################### """ # U 2014/11/12 19:46:18.448550 pub_ip_ua:54705 -> pub_ip_ep:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK459444805. Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1902678123. To: <sip:user1@fakedomain.com>;tag=2518urgZJFet. Call-ID: 2104228355. CSeq: 3 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062>. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # U 2014/11/12 19:46:18.449161 pub_ip_ep:5060 -> 192.168.51.168:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP pub_ip_ep;branch=z9hG4bK7de2.a9aed4070706f93b25b4d2d3d7963a19.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK459444805. From: "user2" <sip:user2@fakedomain.com>;tag=1902678123. To: <sip:user1@fakedomain.com>;tag=2518urgZJFet. Call-ID: 2104228355. CSeq: 3 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062;alias=pub_ip_ua~54705~1>. Proxy-Authorization: Digest username="user2", realm="fakedomain.com", nonce="VGOr71RjqsMDoDyEqMnELO4fotFJLYhV", uri="sip:user1@192.168.51.168:5060", response="12fbfa50428b37bd55dbb4b51f8d5cba", algorithm=MD5. Accept: application/dialog-info+xml. Max-Forwards: 65. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. """

2 1

TLS/TCP sipping
by Petr Wozniak 11 Nov '14

11 Nov '14

Hello, Base on my testing OPTION pings can be sent only to UDP nated clients. So it is impossible with kamailio to send OPTION pings to TCP/TLS nated clients? I found doc for some version of nathelper module where the natping _tcp parameter can be set by modparam("nathelper", "natping_tcp", 1) Unfortunately, this parameter cannot be used in default nathelper module in kamailio 4.2.(doc is probably from OpenSIPS) I would like to send OPTION pings to TLS nated and individualy selected user agents. Does exist some possibility to do it with kamailio 4.2? If not by default does exist the possibility to compile and build kamailio with the nathelper module mentioned above (with natping_tcp parameter)? Or does exist some other solution? Thank you in advance Petr

1 0

Kamailio v4.2.1 Released
by Daniel-Constantin Mierla 11 Nov '14

11 Nov '14

Hello, Kamailio SIP Server v4.2.1 stable release is out. This is a maintenance release of the latest stable branch, 4.2, that includes fixes since release of v4.2.0. There is no change to database schema or configuration language structure that you have to do on installations of v4.2.0. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.2.1. For more details about version 4.2.1 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2014/11/kamailio-v4-2-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

header manipulation in locally generated SIP OPTIONS requests
by Klaus Feichtinger 11 Nov '14

11 Nov '14

Hello, does kamailio offer any possibility for adding / replacing SIP headers in locally built SIP requests? In detail: SIP OPTIONS requests that are built by the DISPATCHER module for probing the configured targets. I have to extend these messages with "Accept" SIP header fields (which are marked with m* in RFC3261 - so they SHOULD be present), as the dispatcher target is requiring this information for answering these requests.... The event_route is principally accepting the append_hf() function and is adding the configured header fields. But the answer to that request (which is including these additional header fields) is confusing the dispatcher module. Dispatcher module is reacting with this ERROR message: DEBUG: dispatcher [dispatch.c:2406]: probing set #1, URI sip:10.10.10.10 DEBUG: dispatcher [dispatch.c:2345]: OPTIONS-Request was finished with code 500 (to , group 1) ERROR: dispatcher [dispatch.c:2358]: Setting the state failed (, group 1) When I comment the textops functions out again and use the original OPTIONS messages, dispatcher is happy and knows the states of the probed targets. Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests? kr Klaus

3 4

Releasing v4.2.1
by Daniel-Constantin Mierla 11 Nov '14

11 Nov '14

Hello, I am considering to release first minor version out of branch 4.2 as v4.2.1 next week, by Tuesday or Wednesday. If there is any comment regarding it, write to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

1 1

ALIAS_DB replacing From and Contact fields
by Martin Schiøtz 11 Nov '14

11 Nov '14

Hi I'm using the ALIAS_DB module. username = 101 alias_username = 44444444 (fictive public phone number) 'alias_db_lookup("dbaliases")' is working fine for incoming calls from PSTN. Calling 44444444 R-URI is replaced with 101 SIP uri. But when 101 is calling to a PSTN number how do I replace the From and Contact fields with 44444444? Cheers, Martin

1 0

RTP end points
by Javier Ricke 10 Nov '14

10 Nov '14

i used asterisk, and install kamailio for traffic RTP can be send between end points, and do not have to go through RTP proxy, any work this form?, and client behind to NAT.. regards!

2 2

beginner's problem with sipping
by Petr Wozniak 10 Nov '14

10 Nov '14

Dear sr-users, I am beginner and apologize for bothering you with such a trivial problem. I would like to test sip UDP and TCP keepalive pinging. Kamailio and client are on the same network (192.168.1.44 and 192.168.1.20) that implies not behind NAT. So in kamailio.cfg I have set modparam("nathelper", "ping_nated_only", 0) My simple kamailio.cfg please you find enclosed. >From logfiles on client's side implies that neither UDP nor OPTIONS pings are sending from kamailio. If somebody would be so kind to help me I will be very glad. Thank you in advance Regards Petr

2 3

Counting xavp stack
by Alex Balashov 10 Nov '14

10 Nov '14

It would be great if there were some way to count the depth of a stack of XAVPs, e.g. $xavp(root=>num) = 1; $xavp(root[0]=>num) = 2; $xavp(root[0]=>num) = 3; ... $var(depth) = $(xavp(root=>num){avp.count}); Right now, the only way to do this that I know of is something like: $var(i) = 0; while(defined $xavp(root[$var(i)]=>num)) $var(i) = $var(i) + 1; $var(i) = $var(i) - 1; Is there a secret I don't know about? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

2 2

Setting up a IMS Server Platform using Kamailio 4.2.x code
by Austin Einter 10 Nov '14

10 Nov '14

Hi All Last few days we have tried to setup Kamailio for IMS server setup. We have not been successful. Now we are planning to use Kamailio 4.2.0 code base (Latest) to setup Kamailio IMS setup. I am looking for a link/document, that gives proper step by step instructions how to setup Kamailio as IMS servers (P-CSCF, I-CSCF and S-CSCF). Can somebody kindly provide the official link or any other working link, that I can follow to setup P-CSCF, I-CSCF ,S-CSCF and HSS. Many thanks Austin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users