Re: [SR-Users] How to define IP Trunk in kamailio

[Iman Mohammadi]

it seem there isnt 5060 on 172.16.15.73, check firewall,iptable and ...

On Tue, May 21, 2019 at 10:59 AM Mary Honey  wrote:

> Thank you for your response
> I saw route[pstn] before and I tried to modify it for routing my call.
> it's done and INVITE request reached to external server and then reached
> to  softphone which external destination defined on it. but Zoiper doesn't
> response INVITE and this request transmitted several times. I don't
> understand what's wrong with my request that Zoiper doesn't accept it.
> pcap over my external server and Zoiper attached here.
>
>
> On Mon, May 20, 2019 at 4:15 PM Iman Mohammadi <
> iman.mohammadi.tele...@gmail.com> wrote:
>
>> Hi
>>
>> It depends on your scenario and purpose, you can do that in scscf and
>> icscf.for example you can see pstn routes in icscf and scscf and even you
>> can define an mmtel in hss for routing your calls by scscf by reading the
>> ifc and spts that scscf gets in saa from hss
>>
>> On Mon, May 20, 2019, 15:08 Mary Honey  wrote:
>>
>>> Hello everyone,
>>>
>>> I install and setup an IMS Network by kamailio-5.2.2 . I have p-cscf,
>>> i-cscf and s-cscf in three different systems . my Hss is Fokus.
>>> Registration and call between subscribers of network work successfully .
>>> now I want to define IP Trunk in my network which can pass external calls
>>> through my IMS network. I don't know how to define IP Trunk and changes in
>>> which element(pcscf, icscf or scscf) should be done.
>>>
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Storing an integer value into AVP from REDIS string

[Stephen Bucklin]

Daniel,
Sorry, I did not see your reply as well. I struggle with mobile email! :-)
Yes, as above I used the s.int but was possibly looking at a more elegantly
constructed methid when moving the value into the avp at the start.
Steve

On Tue, 21 May 2019 at 07:50, Stephen Bucklin 
wrote:

> Hi,
> I would like to set is an an integer. Forgive me as I am on mobile so this
> is from memory. I am getting a string using REDIS something like:
>
> Redis_cmd("dB","GET key:xyz","r")
>
> I now have some string in $redus(r=>value) say
>
> {"this":"that","mum":"3","other":"here"}
>
> I have used the jansson_get to move the value of the specific key into an
> AVP for use. If I move the value 3 that is keyed by "num" from the Jason
> into the AVP it is a string. I can use $avp(val) = $(avp(val){s.int}) and
> that will work but was wondering if there was a more elegant solution to
> this?
> Just finding my way around this new landscape :-)
>
> Steve
>
>
> On Mon, 20 May 2019 at 18:14, Alex Balashov 
> wrote:
>
>> You want to validate that the value is an integer, or coerce the internal
>> type of the AVP to integer?
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>> > On May 20, 2019, at 7:52 AM, Stephen Bucklin 
>> wrote:
>> >
>> > Hi,
>> > Any quick thoughts. I am using a REDIS "GET" to retrieve a JSON obj as
>> a string from REDIS and then the JANSSON get value to extract a key value
>> from the string and pop it into an AVP ($avp(val)) and wish to ensure the
>> value is an integer in the AVP. New to this, be kind :-)
>> > Steve
>> > ___
>> > Kamailio (SER) - Users Mailing List
>> > sr-users@lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Storing an integer value into AVP from REDIS string

[Daniel-Constantin Mierla]

I haven't tried and I am not the developer of jansson module, but of you
control how the json doc is written in redis, then you can try to store
the value as number (not enclosed in quotes) and maybe jansson store its
value directly as int in the kamailio.cfg variable.

Otherwise, using {s.int} is the recommended way. I would just store
first in a $var(x) as string value and then move it to $avp(...)
converted to int.

If you store first to $avp(val) and then do:

$avp(val) = $(avp(val){s.int});

you end up with two $avp(val) -- AVPs work as a multi-value stack, an
assignment adds to the top of the stack. Overall, it should be fine,
this is more like a cosmetic change.

Cheers,
Daniel

On 21.05.19 09:34, Stephen Bucklin wrote:
> Daniel,
> Sorry, I did not see your reply as well. I struggle with mobile email! :-)
> Yes, as above I used the s.int  but was possibly looking
> at a more elegantly constructed methid when moving the value into the
> avp at the start. 
> Steve
>
> On Tue, 21 May 2019 at 07:50, Stephen Bucklin
> mailto:st...@telcoelectronics.uk>> wrote:
>
> Hi,
> I would like to set is an an integer. Forgive me as I am on mobile
> so this is from memory. I am getting a string using REDIS
> something like:
>
> Redis_cmd("dB","GET key:xyz","r")
>
> I now have some string in $redus(r=>value) say 
>
> {"this":"that","mum":"3","other":"here"}
>
> I have used the jansson_get to move the value of the specific key
> into an AVP for use. If I move the value 3 that is keyed by "num"
> from the Jason into the AVP it is a string. I can use $avp(val) =
> $(avp(val){s.int }) and that will work but was
> wondering if there was a more elegant solution to this?
> Just finding my way around this new landscape :-)
>
> Steve
>
>
> On Mon, 20 May 2019 at 18:14, Alex Balashov
> mailto:abalas...@evaristesys.com>> wrote:
>
> You want to validate that the value is an integer, or coerce
> the internal type of the AVP to integer?
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> > On May 20, 2019, at 7:52 AM, Stephen Bucklin
> mailto:st...@telcoelectronics.uk>>
> wrote:
> >
> > Hi,
> > Any quick thoughts. I am using a REDIS "GET" to retrieve a
> JSON obj as a string from REDIS and then the JANSSON get value
> to extract a key value from the string and pop it into an AVP
> ($avp(val)) and wish to ensure the value is an integer in the
> AVP. New to this, be kind :-)
> > Steve
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org 
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Storing an integer value into AVP from REDIS string

[Steve Bucklin]

Daniel,

Thanks, you're a star! I dug into the old stuff that was inserting the 
values in REDIS, and *yes* there it was. The database was set as INT, 
however the php (7) json_encode was encoding all values as a string. 
There is a flag for that function called "JSON_NUMERIC_CHECK" that now 
forces the INT values where needed and the object now is passed as an 
INT, and then by the jansson_get() function to the avp.


Should have thought about that one. Thanks again :-)

Steve

On 21/05/2019 09:19, Daniel-Constantin Mierla wrote:


I haven't tried and I am not the developer of jansson module, but of 
you control how the json doc is written in redis, then you can try to 
store the value as number (not enclosed in quotes) and maybe jansson 
store its value directly as int in the kamailio.cfg variable.


Otherwise, using {s.int} is the recommended way. I would just store 
first in a $var(x) as string value and then move it to $avp(...) 
converted to int.


If you store first to $avp(val) and then do:

$avp(val) = $(avp(val){s.int});

you end up with two $avp(val) -- AVPs work as a multi-value stack, an 
assignment adds to the top of the stack. Overall, it should be fine, 
this is more like a cosmetic change.


Cheers,
Daniel

On 21.05.19 09:34, Stephen Bucklin wrote:

Daniel,
Sorry, I did not see your reply as well. I struggle with mobile 
email! :-)
Yes, as above I used the s.int  but was possibly 
looking at a more elegantly constructed methid when moving the value 
into the avp at the start.

Steve

On Tue, 21 May 2019 at 07:50, Stephen Bucklin 
mailto:st...@telcoelectronics.uk>> wrote:


Hi,
I would like to set is an an integer. Forgive me as I am on
mobile so this is from memory. I am getting a string using REDIS
something like:

Redis_cmd("dB","GET key:xyz","r")

I now have some string in $redus(r=>value) say

{"this":"that","mum":"3","other":"here"}

I have used the jansson_get to move the value of the specific key
into an AVP for use. If I move the value 3 that is keyed by "num"
from the Jason into the AVP it is a string. I can use $avp(val) =
$(avp(val){s.int }) and that will work but was
wondering if there was a more elegant solution to this?
Just finding my way around this new landscape :-)

Steve


On Mon, 20 May 2019 at 18:14, Alex Balashov
mailto:abalas...@evaristesys.com>> wrote:

You want to validate that the value is an integer, or coerce
the internal type of the AVP to integer?

—
Sent from mobile, with due apologies for brevity and errors.

> On May 20, 2019, at 7:52 AM, Stephen Bucklin
mailto:st...@telcoelectronics.uk>> wrote:
>
> Hi,
> Any quick thoughts. I am using a REDIS "GET" to retrieve a
JSON obj as a string from REDIS and then the JANSSON get
value to extract a key value from the string and pop it into
an AVP ($avp(val)) and wish to ensure the value is an integer
in the AVP. New to this, be kind :-)
> Steve
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org

> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] $snd(proto) mapping?

[Andrew Chen]

Hey guys,

Is there a numeric mapping for  $snd(proto)?

Thanks

-- 
Andy Chen
Sr. Telephony Lead Engineer
achen@ fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] How to get started (configuring an interconnection)

[Benoit Panizzon]

Dear Kamailio Users

I might need a bit help with starting.

We are a TSP and at the moment we use a commercial carrier grade voice
switch, which is very VERY inflexible and where bugs we find either
don't get fixed, or only with a large delay.

As everywhere else we embrace opensource and enjoy the possibility to
quickly fix bugs ourselves (we have a software development department)
we are evaluating Kamailio.

Basically, if we have a centralized SIP routing engine, which can record
CDRS for Billing and do some Number Translations (lookup on
external service or database) for (location based emergency numbers,
call forwarding services, ported numbers, call spam blacklisting) we
could do way more than our actual $$$ carrier switch is capable of.
Kamailio sounds like perfect for this task.

First step:

Get a machine up and running with Kamailio and Siremis, done, that was
easy.

Next:

Connect his SIP wise via what I would call a 'SIP carrier
interconnecton', ip based authenticated trunk between our carrier
switch and Kamailio so we can route some number ranges from our carrier
switch to Kamailio and then continue to test with subscribers,
subscriber trunks and all else we need on Kamailio.

I'm quite fluent in Asterisk (our Voicemail and Announcement Services
are based on Asterisk) and SIP and have come across many different PBX,
but after reading parts of the documentation, and trying myself to
understand how Kamailio talks to other SIP endpoints I am a bit at a
loss.

I would have expected that I would configure our carrier switch as
'remote SIP gateway' or whatever it would be called.

But I start fearing, Kamilio works completely differently. So I might
need a bit of pointing the right direction to get started.

I did try with the 'CarrierRoute Management' or 'Dispatcher' functions,
but I only find very little documentation on this.

So how do I get started? How do I, for starters, tell Kamailio what the
Hostname or IP of my Carrier switch is and how do I set a 'default'
call route to this?

Kind regards

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

[JR Richardson]

Hey Folks,

I could use some feedback to see if my mind is right on this topic.I'm
in a discussion with a software Vendor (respectfully unnamed) with
terminal software routing on To: header info. It's my contention any
modern SIP software should use INVITE header to retrieve DID info and
route from there.

My reasoning is due to the To: header should contain the original
intended DID, Extension, Name, AoR or whatever else the original SIP
transaction wanted to contact, but being in a multi-carrier,
multi-hop, call forwarding environment, the INVITE header contains the
hop-to-hop true intention of where the call should route at any given
transaction. So in the case of terminal software the To: header could
likely be irrelevant where as the INVITE header is accurate.

My most recent response from the Vendor suggest I put a SIP Proxy in
front of the terminal software and transform the To: header to
whatever I need for this application. Although I can do this, I'm
concerned with breaking RFC for CANCEL and BYE transaction sent back
from the terminal software that may not be recognized by upstream
origination carriers.

Plus modifying To: header is widely frowned upon by most folks.

Thanks.

JR
-- 
JR Richardson
Engineering for the Masses
Chasing the Azeotrope

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to get started (configuring an interconnection)

[David Villasmil]

If you already setup kamailio, and if I understood what you want, take the
default cfg and uncomment the WITH_PSTN and WITH_IPAUTH defines. They’re
pretty much explained in the cfg.
Whatever you send to kamailio, it tries to find the called number in the
location table (if you enabled WITH_MYSQL), and of it doesn’t find it, it
will forward it to the defined pstn variable.
On the asterisks you need to set your kamailio as the outbound proxy. This
is all for outbound to your provider. They would need to authorize your
kamailio ip for inbound.

For inbound to your asterisks, you need to use as you said, the dispatcher
module. Let us know if you need more help on that.

David

On Tue, 21 May 2019 at 14:14, Benoit Panizzon 
wrote:

> Dear Kamailio Users
>
> I might need a bit help with starting.
>
> We are a TSP and at the moment we use a commercial carrier grade voice
> switch, which is very VERY inflexible and where bugs we find either
> don't get fixed, or only with a large delay.
>
> As everywhere else we embrace opensource and enjoy the possibility to
> quickly fix bugs ourselves (we have a software development department)
> we are evaluating Kamailio.
>
> Basically, if we have a centralized SIP routing engine, which can record
> CDRS for Billing and do some Number Translations (lookup on
> external service or database) for (location based emergency numbers,
> call forwarding services, ported numbers, call spam blacklisting) we
> could do way more than our actual $$$ carrier switch is capable of.
> Kamailio sounds like perfect for this task.
>
> First step:
>
> Get a machine up and running with Kamailio and Siremis, done, that was
> easy.
>
> Next:
>
> Connect his SIP wise via what I would call a 'SIP carrier
> interconnecton', ip based authenticated trunk between our carrier
> switch and Kamailio so we can route some number ranges from our carrier
> switch to Kamailio and then continue to test with subscribers,
> subscriber trunks and all else we need on Kamailio.
>
> I'm quite fluent in Asterisk (our Voicemail and Announcement Services
> are based on Asterisk) and SIP and have come across many different PBX,
> but after reading parts of the documentation, and trying myself to
> understand how Kamailio talks to other SIP endpoints I am a bit at a
> loss.
>
> I would have expected that I would configure our carrier switch as
> 'remote SIP gateway' or whatever it would be called.
>
> But I start fearing, Kamilio works completely differently. So I might
> need a bit of pointing the right direction to get started.
>
> I did try with the 'CarrierRoute Management' or 'Dispatcher' functions,
> but I only find very little documentation on this.
>
> So how do I get started? How do I, for starters, tell Kamailio what the
> Hostname or IP of my Carrier switch is and how do I set a 'default'
> call route to this?
>
> Kind regards
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29
> 
>  Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

[Alex Balashov]

The To header is a cosmetic, purely logical commentary on the intended ultimate 
 destination of the call, and no routing should ever be done on it. The RURI of 
the INVITE is the appropriate vehicle for that.

When dealing with proxies, however, one will encounter from time to time the 
grim reality that there are user agents which expect the To URI and the INVITE 
RURI to be in alignment. For that scenario, you can use ‘uac’ module’s stateful 
rewriting functionally (uac_replace_to()) to modify To with Kamailio in a way 
that displays fidelity and esteem for protocol formalities.

—
Sent from mobile, with due apologies for brevity and errors.

> On May 21, 2019, at 9:32 AM, JR Richardson  wrote:
> 
> Hey Folks,
> 
> I could use some feedback to see if my mind is right on this topic.I'm
> in a discussion with a software Vendor (respectfully unnamed) with
> terminal software routing on To: header info. It's my contention any
> modern SIP software should use INVITE header to retrieve DID info and
> route from there.
> 
> My reasoning is due to the To: header should contain the original
> intended DID, Extension, Name, AoR or whatever else the original SIP
> transaction wanted to contact, but being in a multi-carrier,
> multi-hop, call forwarding environment, the INVITE header contains the
> hop-to-hop true intention of where the call should route at any given
> transaction. So in the case of terminal software the To: header could
> likely be irrelevant where as the INVITE header is accurate.
> 
> My most recent response from the Vendor suggest I put a SIP Proxy in
> front of the terminal software and transform the To: header to
> whatever I need for this application. Although I can do this, I'm
> concerned with breaking RFC for CANCEL and BYE transaction sent back
> from the terminal software that may not be recognized by upstream
> origination carriers.
> 
> Plus modifying To: header is widely frowned upon by most folks.
> 
> Thanks.
> 
> JR
> -- 
> JR Richardson
> Engineering for the Masses
> Chasing the Azeotrope
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

[Benoit Panizzon]

Hi JR

You stumbled of a very serious SIP Problem here I think. I also
fighting with a Carrier Switch Vendor on what the correct way to send
the destination phone number is.

The Problem is, the SIP RFCs involved are not precise enough.

One interpretation of them is, the To: header should never be altered,
no matter if that call got forwarded, because the destination address
of the call is in the invite header.

Another RFC states, that in a scenario with a dynamic subscription, the
content of the Invite Header to the dynamic subscriber has to contain
the contact information user for the registration.

Example:

Register
From: al...@example.com
Contact: foo...@example.com

Now if a call is directed to that subscriber, the Invite which should
be generated would look like:

INVITE: foo...@example.com
From: b...@example.com
To: al...@example.com

Now consider a forwarding scenario without altering the To Heder:

Bob => Charlie (forwarded to Alice)

INVITE: foo...@example.com
From: b...@example.com
To: char...@example.com
Diversion: char...@example.com,reason=busy

Well, as long as you have single extension subscribers, this still
works, as the phone will ring withing checking the content of the
invite or to header.

But now comes the World of SIP Trunk and PBX.

A PBX registers with one Contact Header for one or even multiple DDI
Ranges.

So if the Voice Switch is sending back the Register Contact in the
INVITE, the PBX cannot use this field to determine which extension to
ring.

So it has to use the To: Header.

Well, not in a forwarding scenario, the To: header does not contain a
valid extension, and the PBX will either invoke a catch-all or simple
reply with 404.

So how to work around this?

Well, you cannot send the Registration Contact in your INVITE Request,
but the INVITE has to contain the called extension behind the PBX. All
PBX which I know can work this way, this is even mostly the default.

BUT, if you have an SBC in between, this is getting tricky, as the SBC
usually identifies an dynamic endpoint by the user sent as register
contact and expects the invite to contain that contact.

So well, if so, the SBC can be instructed to copy the To: user to the
Invite User, but again this will fail in forwarded call situations.

So from my point of view, the only way to make this work is to ensure
that the INVITE header, contains the destination phone number and to
ignore the content of the To: header. Of course this makes SBC
implementations very tricky, like then you have to start dynamically
allocating a IP port for every 'trunk' user you have because the SBC
cannot rely on getting the Request Contact in an Invite to a trunk
customer.

But try to persuade commercial vendors to do this right. Even after
they could reproduce and see the problem them self, the reply I got
was: "But we have to rely on the RFC and have implemented this the RFC
way even if it's broken we cannot fix it".

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] $snd(proto) mapping?

[Daniel-Constantin Mierla]

Hello,

is the corresponding values from the c code as defined for PROTO_UDP,
PROTO_TCP, ...

I added in the wiki those values:

  * https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#sndto_name

Cheers,
Daniel

On 21.05.19 15:08, Andrew Chen wrote:
> Hey guys,
>
> Is there a numeric mapping for  $snd(proto)?
>
> Thanks
>
> -- 
> Andy Chen
> Sr. Telephony Lead Engineer
> achen@ fuze.com 
>
>
>
> *Confidentiality Notice: The information contained in this e-mail and any
> attachments may be confidential. If you are not an intended recipient, you
> are hereby notified that any dissemination, distribution or copying of
> this
> e-mail is strictly prohibited. If you have received this e-mail in error,
> please notify the sender and permanently delete the e-mail and any
> attachments immediately. You should not retain, copy or use this e-mail or
> any attachment for any purpose, nor disclose all or any part of the
> contents to any other person. Thank you.*
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

[Daniel Tryba]

On Tue, May 21, 2019 at 03:57:02PM +0200, Benoit Panizzon wrote:
...
> So if the Voice Switch is sending back the Register Contact in the
> INVITE, the PBX cannot use this field to determine which extension to
> ring.
> 
> So it has to use the To: Header.
> 
> Well, not in a forwarding scenario, the To: header does not contain a
> valid extension, and the PBX will either invoke a catch-all or simple
> reply with 404.
> 
> So how to work around this?
> 
> Well, you cannot send the Registration Contact in your INVITE Request,
> but the INVITE has to contain the called extension behind the PBX. All
> PBX which I know can work this way, this is even mostly the default.
> 
> BUT, if you have an SBC in between, this is getting tricky, as the SBC
> usually identifies an dynamic endpoint by the user sent as register
> contact and expects the invite to contain that contact.
...

RFC3327 Path tries to solve this problem. If that "SBC" doesn't support
Path all you can do is send the Contact from the REGISTER and leave it
to the SBC to solve its own problems.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] remove_hf inside of onreply_route

[Володимир Іванець]

Hello!

I was wondering if someone is using remove_hf in onreply_route and if yes
on which Kamailio version? I'm using Kamailio v5.2.1 and as soon as I add
remove_hf function to onreply_route Kamailio will fail to start with
following error messages:

ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
qm_find_free(0x7fc1dc044010, 27120); Free fragment not found!
ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
qm_malloc(0x7fc1dc044010, 27120) called from core: core/io_wait.c:
init_io_wait(524), module: core; Free fragment not found!

Thank you for any suggestions!
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] RTPEngine / Transcoding question

[Carsten Bock]

Hi,

I want to implement selective transcoding, e.g. avoiding Transcoding
between a HD codec (G722) and a non HD Codec (G711).

In case the caller does offer HD codecs, this is fine, e.g.

if(sdp_with_codecs_by_name("G722,OPUS")) {
  rtpengine_offer("codec-transcode=OPUS codec-transcode=G722
codec-transcode=PCMA");
} else {
  rtpengine_manage("codec-transcode=PCMA");
}

Now I have the issue, if the callee only sends me G711, I don't want to
offer G722 or Opus to the caller. However, rtpengine_answer() does not seem
to accept "codec-strip=G722 codec-strip=OPUS", e.g.:

onreply_route() {
  if(!sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
  }
}

As a result, the SDP always contains the transcoding options, e.g. G722 and
OPUS. I always end up in transcoding G722 to G711, which is meaningless in
that case.

Any ideas on how to solve that?
(above examples very simplified)

Thanks,
Carsten
--
Carsten Bock I Managing Director
ng-voice GmbH

Millerntorplatz 1 I 20359 Hamburg I Germany
www.ng-voice.com

Mobile +49 (0)179-20 21 244 I Direct +49 (0)40-52 47 593-40 I Fax +49
(0)40-52 47 593-99

Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock, Dr. David Bachmann
Ust-ID: DE279344284

Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] remove_hf inside of onreply_route

[Daniel-Constantin Mierla]

Hello,

I just tested with latest master and branch 5.2, no issue starting with
remove_hf() in onreply_route[x] or reply_route. Either you have not
enough pkg/shm memory, or there is some other error ending up with those
messages.

Start kamailio with debug=3 and look at all log messages to see what
happens there.

Cheers,
Daniel

On 21.05.19 18:56, Володимир Іванець wrote:
> Hello!
>
> I was wondering if someone is using remove_hf in onreply_route and if
> yes on which Kamailio version? I'm using Kamailio v5.2.1 and as soon
> as I add remove_hf function to onreply_route Kamailio will fail to
> start with following error messages:
>
> ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
> qm_find_free(0x7fc1dc044010, 27120); Free fragment not found!
> ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
> qm_malloc(0x7fc1dc044010, 27120) called from core: core/io_wait.c:
> init_io_wait(524), module: core; Free fragment not found!
>
> Thank you for any suggestions!
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] remove_hf inside of onreply_route

[Володимир Іванець]

Thank you very much!

It turned out that problem was caused by a combination of functions that I
wanted to use together. It was fixed by increasing SHM_MEMORY
and PKG_MEMORY values.

вт, 21 трав. 2019 о 21:10 Daniel-Constantin Mierla  пише:

> Hello,
>
> I just tested with latest master and branch 5.2, no issue starting with
> remove_hf() in onreply_route[x] or reply_route. Either you have not enough
> pkg/shm memory, or there is some other error ending up with those messages.
>
> Start kamailio with debug=3 and look at all log messages to see what
> happens there.
>
> Cheers,
> Daniel
> On 21.05.19 18:56, Володимир Іванець wrote:
>
> Hello!
>
> I was wondering if someone is using remove_hf in onreply_route and if yes
> on which Kamailio version? I'm using Kamailio v5.2.1 and as soon as I add
> remove_hf function to onreply_route Kamailio will fail to start with
> following error messages:
>
> ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
> qm_find_free(0x7fc1dc044010, 27120); Free fragment not found!
> ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
> qm_malloc(0x7fc1dc044010, 27120) called from core: core/io_wait.c:
> init_io_wait(524), module: core; Free fragment not found!
>
> Thank you for any suggestions!
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Richard Fuchs]

On 21/05/2019 11.48, Carsten Bock wrote:

Hi,

I want to implement selective transcoding, e.g. avoiding Transcoding 
between a HD codec (G722) and a non HD Codec (G711).


In case the caller does offer HD codecs, this is fine, e.g.

if(sdp_with_codecs_by_name("G722,OPUS")) {
  rtpengine_offer("codec-transcode=OPUS codec-transcode=G722 
codec-transcode=PCMA");

} else {
  rtpengine_manage("codec-transcode=PCMA");
}

Now I have the issue, if the callee only sends me G711, I don't want 
to offer G722 or Opus to the caller. However, rtpengine_answer() does 
not seem to accept "codec-strip=G722 codec-strip=OPUS", e.g.:


onreply_route() {
  if(!sdp_with_codecs_by_name("G722,OPUS")) {
    rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
  }
}

As a result, the SDP always contains the transcoding options, e.g. 
G722 and OPUS. I always end up in transcoding G722 to G711, which is 
meaningless in that case.


Any ideas on how to solve that?
(above examples very simplified)


All transcoding options must be present in the `offer` - they're ignored 
in the `answer`. (At least in newer versions - older versions did accept 
them in an `answer`, but they didn't do what was expected, which is why 
they were removed in later versions.)


The reason for this is that the callee may send media before the SDP 
from the callee (the answer) is seen. Therefore all transcoding 
decisions must be made at the time of the offer (otherwise you may end 
up switching codecs whenever the answer is seen, which is undesirable). 
So you'll have to figure out a way to decide what you want to do based 
on what you know at the time of the offer.


I'm a bit confused by your example. If you want to avoid transcoding 
between G.722 or Opus, and G.711, why do you want to offer PCMA when the 
caller supports G.722 or Opus? Shouldn't you rather only offer other 
"HD" codecs and strip all non-HD codecs in that case?


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Carsten Bock]

Hi Richard,

Thanks for your reply, understood.

The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be supported by
the callee. G711 is however always supported, that's why I don't want to
strip it. I send the call to our upstream provider; if he sends it to
Telefonica, we get an answer with G722 and G711. If he sends it to Deutsche
Telekom, the answer is only G711. However, we don't know, if it's gonna be
Telefonica or Deutsche Telekom...

I was thinking about avoiding uneccessary RTP traffic (in HD) between
RTPEngine and the device in case of an outbound call. From a signalling
perspective, I get the right result, if I use sdp_remove_codecs() in my
reply. However, that won't work, since the RTP stream sent from RTPEngine
to the device is in HD, regardless of the signalling.

I can live with the status quo.

Thanks again,
Carsten

Richard Fuchs  schrieb am Di., 21. Mai 2019, 23:38:

> On 21/05/2019 11.48, Carsten Bock wrote:
> > Hi,
> >
> > I want to implement selective transcoding, e.g. avoiding Transcoding
> > between a HD codec (G722) and a non HD Codec (G711).
> >
> > In case the caller does offer HD codecs, this is fine, e.g.
> >
> > if(sdp_with_codecs_by_name("G722,OPUS")) {
> >   rtpengine_offer("codec-transcode=OPUS codec-transcode=G722
> > codec-transcode=PCMA");
> > } else {
> >   rtpengine_manage("codec-transcode=PCMA");
> > }
> >
> > Now I have the issue, if the callee only sends me G711, I don't want
> > to offer G722 or Opus to the caller. However, rtpengine_answer() does
> > not seem to accept "codec-strip=G722 codec-strip=OPUS", e.g.:
> >
> > onreply_route() {
> >   if(!sdp_with_codecs_by_name("G722,OPUS")) {
> > rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
> >   }
> > }
> >
> > As a result, the SDP always contains the transcoding options, e.g.
> > G722 and OPUS. I always end up in transcoding G722 to G711, which is
> > meaningless in that case.
> >
> > Any ideas on how to solve that?
> > (above examples very simplified)
>
> All transcoding options must be present in the `offer` - they're ignored
> in the `answer`. (At least in newer versions - older versions did accept
> them in an `answer`, but they didn't do what was expected, which is why
> they were removed in later versions.)
>
> The reason for this is that the callee may send media before the SDP
> from the callee (the answer) is seen. Therefore all transcoding
> decisions must be made at the time of the offer (otherwise you may end
> up switching codecs whenever the answer is seen, which is undesirable).
> So you'll have to figure out a way to decide what you want to do based
> on what you know at the time of the offer.
>
> I'm a bit confused by your example. If you want to avoid transcoding
> between G.722 or Opus, and G.711, why do you want to offer PCMA when the
> caller supports G.722 or Opus? Shouldn't you rather only offer other
> "HD" codecs and strip all non-HD codecs in that case?
>
> Cheers
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Richard Fuchs]

On 21/05/2019 18.42, Carsten Bock wrote:

Hi Richard,

Thanks for your reply, understood.

The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be 
supported by the callee. G711 is however always supported, that's why 
I don't want to strip it. I send the call to our upstream provider; if 
he sends it to Telefonica, we get an answer with G722 and G711. If he 
sends it to Deutsche Telekom, the answer is only G711. However, we 
don't know, if it's gonna be Telefonica or Deutsche Telekom...


I was thinking about avoiding uneccessary RTP traffic (in HD) between 
RTPEngine and the device in case of an outbound call. From a 
signalling perspective, I get the right result, if I use 
sdp_remove_codecs() in my reply. However, that won't work, since the 
RTP stream sent from RTPEngine to the device is in HD, regardless of 
the signalling.


Maybe you want to make your transcoding options also dependent on 
whether G.711 was present in the original offer, and/or in what order 
the codecs were listed? Rtpengine won't do transcoding if both sides 
support the same codec, even if other codec pairings are possible 
(unless `always-transcode` is given). Are you using that option? Are you 
using other options to reorder codecs in the offer? Because normally the 
first supported codec will be used, and rtpengine adds transcoding codec 
offers to the end of the list. So they should only be used if no other 
codec is supported by the callee, unless the callee ignores the listed 
codec preferences, or codecs were reordered, or `always-transcode` was used.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Releasing Kamailio v5.2.3

[Daniel-Constantin Mierla]

Hello,

v5.2.3 will be packaged soon. Till the announcement is out, any commits
to branch 5.2 have to be announced to sr-dev or irc channel to avoid
conflicts.

Cheers,
Daniel

On 15.05.19 09:09, Daniel-Constantin Mierla wrote:
> Hello,
>
> I am considering to release Kamailo v5.2.3 out of latest git branch 5.2
> next week, likely on Wednesday, May 22. As usual, if you are aware of
> issues not reported to the github bug tracker, fill a report there as
> soon as possible to give a chance to be analyzed and fixed. Also, if
> there was a fix for an issue that you were reporting, check to see if it
> was backported to be sure it is not forgotten.
>
> Cheers,
> Daniel
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users