Re: [SR-Users] VERY IMPORTANT: deciding when to remove the MI code

2016-12-02 Thread ycaner 
Hello
Carrier route module doesnt have RPC command., we need to add it 
Cheers.



--
View this message in context: 
http://sip-router.1086192.n5.nabble.com/VERY-IMPORTANT-deciding-when-to-remove-the-MI-code-tp153719p153773.html
Sent from the Users mailing list archive at Nabble.com.

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Send SIP Info within a dialog using $uac_req(method)="INFO"

2016-12-02 Thread Jonathan Hunter 
Hi Daniel,


I can see when people are using curl they can define content-type ;


--header 'Content-Type: application/json'

However is this  possible within the jsonrpc_exec command, as this seems to set 
the body.


Can you define the Content-Type before firing the command?


Thanks


Jon



From: sr-users  on behalf of Jonathan 
Hunter 
Sent: 01 December 2016 16:12
To: Kamailio SER - Users Mailing List; mico...@gmail.com
Subject: Re: [SR-Users] Send SIP Info within a dialog using 
$uac_req(method)="INFO"


Hi Daniel,

I am trying tm.t_uac_start and its stating Content-Type Missing, I have tried 
to add to params but it doesnt like it, where should it be defined?

Command below;


jsonrpc_exec('{"jsonrpc":"2.0","method":"tm.t_uac_start","params": ["INFO", 
"$dlg(to_uri)",".",".","From:$var(testjon)\r\n","To:$var(testjon2)\r\n","Contact:$var(testjon4)\r\n","Content-Type:
 application/json\r\n","Content-Length: 0\r\n"]}');

And logs;

Dec  1 16:09:15 POC_ProxyA /usr/sbin/kamailio[11883]: INFO:

Re: [SR-Users] [sr-dev] VERY IMPORTANT: deciding when to remove the MI code

2016-12-02 Thread Daniel-Constantin Mierla 
On 02/12/2016 11:21, Alex Hermann wrote:
> On donderdag 1 december 2016 15:17:18 CET Daniel-Constantin Mierla wrote:
>> RPC is the alternative, a more standardized
>> concept, with better structured format.
> Before removing MI and letting everyone move to RPC, it might be wise to go 
> over all RPC interfaces and fix them to be neat , sane and somewhat 
> consistent. 
> For example, there are still interfaces coding arrays as hashes with multiple 
> identically named fields (htable.dump is one i recently ran into) . There is 
> no 
> language and/or JSON/XML library i know of that can properly handle those 
> (most of them will just end up with the last entry).

In such case the value can be constructed as an array. And I think
leaving it at the free will means it won't happen -- we aimed at this
since 2008 more or less. Hopefully there are only of few cases that need
fixes and can be done while testing 5.0.

But for htable there should not be more than one item with the same
name, so such situation should not be for htable.dump. Can you give an
example that you encountered, how do you set two items with same name?

Cheers,
Daniel


-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] VERY IMPORTANT: deciding when to remove the MI code

2016-12-02 Thread Alex Hermann 
On donderdag 1 december 2016 15:17:18 CET Daniel-Constantin Mierla wrote:
> RPC is the alternative, a more standardized
> concept, with better structured format.

Before removing MI and letting everyone move to RPC, it might be wise to go 
over all RPC interfaces and fix them to be neat , sane and somewhat consistent. 
For example, there are still interfaces coding arrays as hashes with multiple 
identically named fields (htable.dump is one i recently ran into) . There is no 
language and/or JSON/XML library i know of that can properly handle those 
(most of them will just end up with the last entry).
-- 
Alex Hermann

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] VERY IMPORTANT: deciding when to remove the MI code

2016-12-02 Thread Juha Heinanen 
Daniel-Constantin Mierla writes:

> Can you find that discussion in the archive? Open an item on bug tracker
> and add the link to the discussion there, so we don't forget about it.

Done, Juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dual Stack Environments

2016-12-02 Thread Daniel-Constantin Mierla 
Hello,


On 02/12/2016 03:40, Colin Morelli wrote:
> Hey all, Sorry for two questions out at the same time! I'm using
> kamailio in front of FS, and I'm about to enable IPv6, but I have a
> question that I'm not entirely clear on. What's the proper way to
> forward traffic using the same interface that it came in on?
> Specifically, if a client connects to kamailio on IPv6, it should
> connect to FS on IPv6, so that FS knows to advertise its v6 address in
> the SDP. The same should be true for v4. Is this possible?
Kamailio tries to use the socket where the request was received for
sending out as well. So it should just work in most of the case.

Anyhow, you can test the address family for received request:

if(af==INET6) {
  # force an ipv6 socket
  # set $du to an ipv6 address
} else {
  # force an ipv4 socket
  # set $du to an ipv4 address
}

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] VERY IMPORTANT: deciding when to remove the MI code

2016-12-02 Thread Daniel-Constantin Mierla 


On 02/12/2016 00:24, Juha Heinanen wrote:
> Brandon Armstead writes:
>
>> +1 - I'm all for cleaning up any technical debt and moving on with more
>> normalized concept.
> I'm also in favor of getting rid on MI interface. I'm myself relying
> only on one MI command (pua_publish) for which an RPC command does not
> exist (or did not exist last time when I checked).
>
> Some years ago I tried to implement RPC version of pua_publish, but was
> not able to get the call back working correctly.  I also sent some
> messages including a piece of code to the dev list, but it was a dead
> end then.
>
> Very nice if pua.publish would see a day of light again.
Can you find that discussion in the archive? Open an item on bug tracker
and add the link to the discussion there, so we don't forget about it.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users