[SR-Users] Telefonia ip

[rom ignacio]

friend I am interested in learning more about VoIP or IP telephony, I read a
lot about you and I still have more to read, as it can not released through
theofficial documentation page errors Please let me send them am email,
thanks

I DEVELOP voip server to sip in Venezuela, I need all the help possible.
thanks

*Rommel Malave .M **
* *T.S.U Universitario Extracción y Producción de Gas *
* T.S.U en Informatica***
04148241688
___
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] Manipulate From header

[alex pappas]

Henning hi,

I did looked the trace and the headers were the same.
In Kamailio-1.5.3 it worked. In Kamailio 3.x.x it seems to not behave
properly and I dont understand why since it does not require any special
configuration.

Any other ideas ?

Cheers
Alex



2011/5/23 Henning Westerholt 

> On Friday 20 May 2011, alex pappas wrote:
> > I'm trying to change the From uri and Dsplay but without sucess.
> >
> > My config is as follow:
> >
> > if(dp_translate("",
> > "$avp(s:frm_user_name)/$avp(s:test_frm_user_name)"))  --> i'm sending
> > 2112202701 and I get back corectly 701 {
> > $avp(s:display) = $avp(s:test_frm_user_name);
> > $avp(s:fu_uri) = "sip:" +
> > $avp(s:test_frm_user_name) + "@" + $fd;
> >
> > xlog("alx --- The avp(s:display):
> > $avp(s:display)  avp(s:fu_uri)=$avp(s:fu_uri)  --\n");  --> I
> > see values  701 and sip:701@my_IP_address
> >
> >
> > uac_replace_from("$avp(s:display)","$avp(s:fu_uri)"); Here I log the fu
> > and I see that nothing has changed..
> >
> >  }
>
> Hi Alex,
>
> i guess your changes to the from header are not visible because they are
> not
> applied yet. They should be visible on the message that is send out to the
> network, have you looked to a trace? Otherwise you could use the
> apply_msg_change method, then it should be also visible:
>
> http://www.kamailio.org/docs/modules/3.1.x/modules/textopsx.html#msg_apply_changes
>
> Cheers,
>
> Henning
>
___
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

[SR-Users] Service Execution Time

[Giuseppe Carella]

Hi all,

I'm using kamailio with the dispatcher module.
I would like to know if there are some API to get an average of the service
execution
time. In other words, I need to get the time between sending the request
and
receiving the response for every request, but also to have this values
separate
per server.

I know also that this could be a little heavy for the dispatcher, but for
some
test I need this information.

Your help is kindly appreciated!

Thanks in advance,

Giuseppe
___
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] Wildcard TLS

[Klaus Darilion]

I never used wildcard certificates with Kamailio but I do not see a 
reason why it shouldn't work. Thus, I am quite sure that it will work.


regards
Klaus

On 24.05.2011 22:25, Jon Farmer wrote:

Hi

I am just wondering if it is possible to use a wildcard certificate with TLS.

I have hundreds of customers who are using subdomains of the main
domain name on a virtual PBX platform. i.e if the main domain is
example.org I have customers using

cust1.example.org
cust2.example.org
cust3.example.org
...

I want to start offering TLS on a per customer basis. However I don't
want to have to create a TLS certificate per customer if I don't need
to. So I need to know if I can create a *.example.org certificate and
use that for all customers who want TLS?

Is this possible?

Regards

Jon




___
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] Service Execution Time

[Henning Westerholt]

On Wednesday 25 May 2011, Giuseppe Carella wrote:
> I'm using kamailio with the dispatcher module. 
> I would like to know if there are some API to get an average of the service
> execution  time. In other words, I need to get the time between sending
> the request and receiving the response for every request, but also to have
> this values separate per server.
> 
> I know also that this could be a little heavy for the dispatcher, but for
> some  test I need this information.

Hi Giuseppe,

have you already looked to the "benchmark" module? It can be used to create 
arbitrary timers in the configuration file. If you need to have it per request 
and response, you probably could just include the sending time in a special 
message header in the sent out request. They are several pseudo-variables 
available which contains timestamps in different formats.

If you want to benchmark the complete server, an external probe should be the 
way to go. Just send test requests e.g. with sipp, it can also output the 
response time.

Cheers,

Henning

___
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] 3.1.x and Kamailio compatibility mode

[Henning Westerholt]

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:
> > Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
> > behavior is changed by #!KAMAILIO?
> 
> it is still good to turn on vim syntax highlighting :-) (if you
> installed the files from utils/misc/vim/ in ~/.vim/), otherwise is not
> changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about removing 
this define then if its not necessary anymore for the server?

Cheers,

Henning

___
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] 3.1.x and Kamailio compatibility mode

[Daniel-Constantin Mierla]

On 5/25/11 10:55 AM, Henning Westerholt wrote:

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:

Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
behavior is changed by #!KAMAILIO?

it is still good to turn on vim syntax highlighting :-) (if you
installed the files from utils/misc/vim/ in ~/.vim/), otherwise is not
changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about removing
this define then if its not necessary anymore for the server?
it is not a define like the other #!define, it is matched in the parser 
and an internal value is set.


Probably it can be removed from the code, it should be harmless/useless 
there. But it is rather useful in the default config for syntax 
highlighting, being treated as a comment anyhow -- e.g., like in other 
cases, many c files have the vim formatting commands in comments.


Cheers,
Daniel

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


___
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] app_lua problem setting module parameter

[Henning Westerholt]

On Wednesday 25 May 2011, Bret McDanel wrote:
> In 3.1.1 this worked just fine.  In 3.1.3 it is giving me an error.  I
> am unsure what to check at this point for why it would be failing.  I am
> doing a kamailio -c to validate the config and not actually launching
> the program but I do not think that should cause this.
> 
> modparam("app_lua", "register", "sqlops")
> 
> sqlops.so is loaded.
> 
> if I remove that modparam line the config validates, however the lua
> script would fail because it uses sqlops.
> 
> modules.lst is the same for building.
> 
> While I do not think that it is lua specific, both are using
> liblua5.1.0, one is Ubuntu 11.04 natty (where it fails) and the other is
> Debian wheezy (where its working).

Hi Bret,

this is a really strange behaviour. You probably already checked this, but the 
two server configurations on the respective machines are otherwise identically 
as well? Do you register also other modules (like sr, auth..) to lua, does 
they fail with the same error as well?

> 0(18226) WARNING: 
> [sr_module.c:578]: /usr/local/kamailio/lib64/kamailio/modules/app_lua.so:
> exports dlflags interface is deprecated and it will notbe supported in
> newer versions; consider using mod_register() instead
> 
> 0(18226) :  [cfg.y:3412]: parse error in config file kamailio.cfg,
> line 262, column 41: Can't set module parameter
> 
> As a side note the "notbe supported ..." line is missing a space between
> not and be and a newline at the end.

Thanks, i've fixed this in master and 3.1 branch.

Regards,

Henning

___
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] 3.1.x and Kamailio compatibility mode

[Klaus Darilion]

On 25.05.2011 11:17, Daniel-Constantin Mierla wrote:



On 5/25/11 10:55 AM, Henning Westerholt wrote:

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:

Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
behavior is changed by #!KAMAILIO?

it is still good to turn on vim syntax highlighting :-) (if you
installed the files from utils/misc/vim/ in ~/.vim/), otherwise is not
changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about
removing
this define then if its not necessary anymore for the server?

it is not a define like the other #!define, it is matched in the parser
and an internal value is set.

Probably it can be removed from the code, it should be harmless/useless
there. But it is rather useful in the default config for syntax
highlighting, being treated as a comment anyhow -- e.g., like in other
cases, many c files have the vim formatting commands in comments.


Does the define has to be in the first line of the config?


IMO we should add a comment like:

# Above Kamailio define is only for vim syntax highlighting and
# can be removed.

regards
klaus

___
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] 3.1.x and Kamailio compatibility mode

[Daniel-Constantin Mierla]

On 5/25/11 12:11 PM, Klaus Darilion wrote:



On 25.05.2011 11:17, Daniel-Constantin Mierla wrote:



On 5/25/11 10:55 AM, Henning Westerholt wrote:

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:

Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
behavior is changed by #!KAMAILIO?

it is still good to turn on vim syntax highlighting :-) (if you
installed the files from utils/misc/vim/ in ~/.vim/), otherwise is not
changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about
removing
this define then if its not necessary anymore for the server?

it is not a define like the other #!define, it is matched in the parser
and an internal value is set.

Probably it can be removed from the code, it should be harmless/useless
there. But it is rather useful in the default config for syntax
highlighting, being treated as a comment anyhow -- e.g., like in other
cases, many c files have the vim formatting commands in comments.


Does the define has to be in the first line of the config?


IMO we should add a comment like:

# Above Kamailio define is only for vim syntax highlighting and
# can be removed.
it is not a define, it is a comment. Like any comment, it can be safety 
removed - imo makes no sense to add such note.


Only following tokens are pre-processor directives:
- #!define, #!ifdef, #!ifndef, #!else, #!endif, #!subst

So you can have your:

#!my text here

And it is simply comment. '#!' does not have a special meaning alone. 
'#' has, and it is start of comment line. The parser is working with 
longest match, so if pre-processor directives are not matched, then it 
is a comment line.


Cheers,
Daniel

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


___
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

[SR-Users] Green VoIP - energy efficiency and performaces of v3.0

[Daniel-Constantin Mierla]

Hello,

Jan Janak conducted a very interesting research project regarding energy 
efficiency of VoIP systems during 2010, a collaboration between 
iptel.org and Columbia University.


The team used the source code from sip-router.org GIT repository from 
January 2010, which corresponds to Kamailio (former OpenSER) and SER 
v3.0. The latest stable series v3.1 shares the same internal 
architecture with v3.0.


As part of the research work, Jan could also gather some figures about 
capacity and performances of v3.0 with a quite complex configuration 
file: etc/sip-router-oob.cfg (involving authentication and NAT traversal 
as well).


You can read the paper about energy efficiency at:

- Green VoIP Article: http://asipto.com/u/2j

The draft notes about capacity and performances of v3.0 are available at:

- Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k

Some interesting results:

- one instance of SIP server with 500 000 online users (mixed users – 
behind and not NAT routers) – consumed energy 210W
- one instance of SIP server with 1 000 000 online users (no NAT 
involved) – consumed energy 190W
- on a 32-bit machine with 4GB of memory and with 2.5GB reserved for SIP 
server, the server could support 43 000 simultaneous TLS connections – 
consumed energy 203W
- one SIP server instance with 80 000 permanent TCP connections, the SIP 
server could still handle at least 1000 requests per second and a 
connection arrival rate of 1000 new connections per second, done for 20 
000 new connections. CPU load generated by the SIP server was from 6% to 8%.


I added a new section to the draft notes to list the enhancements done 
for the latest stable release (v3.1.x) that contribute to performance 
improvements, like asynchronous TLS, fine tuning of memory for TLS 
connections and raw UDP sockets.


Cheers,
Daniel

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


___
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] Green VoIP - energy efficiency and performaces of v3.0

[Jeremya]

These figures pale into insignificance compared to the power required
for standard SIP devices - typically 5-8 watts per device multiplied by
the number of devices.

When you factor in Gigabit Ethernet the power ups significantly.

Optimisation at the server level is not significant on any scale.
Optimisation on communications power: i.e. end-devices, DSL & switches
is where the power savings are important.


Daniel-Constantin Mierla wrote:
> Hello,
>
> Jan Janak conducted a very interesting research project regarding
> energy efficiency of VoIP systems during 2010, a collaboration between
> iptel.org and Columbia University.
>
> The team used the source code from sip-router.org GIT repository from
> January 2010, which corresponds to Kamailio (former OpenSER) and SER
> v3.0. The latest stable series v3.1 shares the same internal
> architecture with v3.0.
>
> As part of the research work, Jan could also gather some figures about
> capacity and performances of v3.0 with a quite complex configuration
> file: etc/sip-router-oob.cfg (involving authentication and NAT
> traversal as well).
>
> You can read the paper about energy efficiency at:
>
> - Green VoIP Article: http://asipto.com/u/2j
>
> The draft notes about capacity and performances of v3.0 are available at:
>
> - Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k
>
> Some interesting results:
>
> - one instance of SIP server with 500 000 online users (mixed users –
> behind and not NAT routers) – consumed energy 210W
> - one instance of SIP server with 1 000 000 online users (no NAT
> involved) – consumed energy 190W
> - on a 32-bit machine with 4GB of memory and with 2.5GB reserved for
> SIP server, the server could support 43 000 simultaneous TLS
> connections – consumed energy 203W
> - one SIP server instance with 80 000 permanent TCP connections, the
> SIP server could still handle at least 1000 requests per second and a
> connection arrival rate of 1000 new connections per second, done for
> 20 000 new connections. CPU load generated by the SIP server was from
> 6% to 8%.
>
> I added a new section to the draft notes to list the enhancements done
> for the latest stable release (v3.1.x) that contribute to performance
> improvements, like asynchronous TLS, fine tuning of memory for TLS
> connections and raw UDP sockets.
>
> Cheers,
> Daniel
>


___
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] 3.1.x and Kamailio compatibility mode

[Klaus Darilion]

On 25.05.2011 12:18, Daniel-Constantin Mierla wrote:



On 5/25/11 12:11 PM, Klaus Darilion wrote:



On 25.05.2011 11:17, Daniel-Constantin Mierla wrote:



On 5/25/11 10:55 AM, Henning Westerholt wrote:

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:

Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
behavior is changed by #!KAMAILIO?

it is still good to turn on vim syntax highlighting :-) (if you
installed the files from utils/misc/vim/ in ~/.vim/), otherwise is not
changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about
removing
this define then if its not necessary anymore for the server?

it is not a define like the other #!define, it is matched in the parser
and an internal value is set.

Probably it can be removed from the code, it should be harmless/useless
there. But it is rather useful in the default config for syntax
highlighting, being treated as a comment anyhow -- e.g., like in other
cases, many c files have the vim formatting commands in comments.


Does the define has to be in the first line of the config?


IMO we should add a comment like:

# Above Kamailio define is only for vim syntax highlighting and
# can be removed.

it is not a define, it is a comment. Like any comment, it can be safety
removed - imo makes no sense to add such note.

Only following tokens are pre-processor directives:
- #!define, #!ifdef, #!ifndef, #!else, #!endif, #!subst

So you can have your:

#!my text here

And it is simply comment. '#!' does not have a special meaning alone.
'#' has, and it is start of comment line. The parser is working with
longest match, so if pre-processor directives are not matched, then it
is a comment line.


Sorry for being to unspecified.

The comment "#!KAMILIO" was used to activate the compatibility mode. 
With 3.1 release this is not needed anymore. Thus, I see 2 options:

a) remove it from the default config
b) keep it there (e.g. for people who like vim syntax highlighting) and 
add another comment which explains that the line can safely remove for 
kamailio >= 3.1. Otherwise people like me will be confused and afraid to 
remove the comment.


regards
Klaus

___
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

[SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11

[Iñaki Baz Castillo]

Hi, for those interested in MSRP protocol (instant message sessions
and file transfer for SIP) there are bad news:

Even if there are already clients and servers (MSRP relays o IM
conference servers) implementing the MSRP protocol (RFC 4975 and 4976)
the SIMPLE WG will publish a new draft [*] that breaks these RFC's
just to satisfy big vendors interested in deploying MSRP capable
SBC/ALG boxes (so instead of solving NAT issues with MSRP relays as
RFC 4976 states, they want it to be fixed in the router by doing ugly
ALG, or in a SBC). This is terrible because all the MSRP devices
should implement this new draft in order to interoperate (no backward
compatibility at all). The draft also breaks the security defined in
RFC 4975 (for example, TLS name based authentication cannot work
anymore).

For further information I recommend reading these two posts:

  http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
  
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compatibility

and also these very *hot* mail threads in the SIMPLE maillist:

  http://www.ietf.org/mail-archive/web/simple/current/msg09227.html
  http://www.ietf.org/mail-archive/web/simple/current/msg09229.html



[*] http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11

-- 
Iñaki Baz Castillo


___
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] Green VoIP - energy efficiency and performaces of v3.0

[Henning Westerholt]

On Wednesday 25 May 2011, Jeremya wrote:
> These figures pale into insignificance compared to the power required
> for standard SIP devices - typically 5-8 watts per device multiplied by
> the number of devices.
> 
> When you factor in Gigabit Ethernet the power ups significantly.
> 
> Optimisation at the server level is not significant on any scale.
> Optimisation on communications power: i.e. end-devices, DSL & switches
> is where the power savings are important.

Hi Jeremya,

you're right in this case - given the much higher number of CPE devices in the 
end user hands and especially as most of them use really cheap (also bad) 
power supplies. But in generally optimisations on a server level are also 
important, if you have a few thousand servers than even small amounts fast add 
up. And for the whole internet it already uses siginifcant part of the power, 
close to 10% in the US to some research:

http://hardware.slashdot.org/story/07/09/27/2157230/Internet-Uses-94-of-
Electricity-In-the-US

With regards to the research from Jan, the performance numbers are really 
impressive, great work! 

Cheers,

Henning

___
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] Green VoIP - energy efficiency and performaces of v3.0

[Jeremya]

I should point out that my SIP business is risk-of-life voice services
where I have to arrange to power SIP devices and communications devices
from alternate energy sources for extended periods, so I am intimately
aware of every watt that is used in SIP communications.

My systems use kamailio in embedded servers at very low power. My
constraint is the SIP devices and communications devices that suck up an
order of magnitude more power at each small site - of which I have many.

Jeremya wrote:
> These figures pale into insignificance compared to the power required
> for standard SIP devices - typically 5-8 watts per device multiplied by
> the number of devices.
>
> When you factor in Gigabit Ethernet the power ups significantly.
>
> Optimisation at the server level is not significant on any scale.
> Optimisation on communications power: i.e. end-devices, DSL & switches
> is where the power savings are important.
>
>
> Daniel-Constantin Mierla wrote:
>   
>> Hello,
>>
>> Jan Janak conducted a very interesting research project regarding
>> energy efficiency of VoIP systems during 2010, a collaboration between
>> iptel.org and Columbia University.
>>
>> The team used the source code from sip-router.org GIT repository from
>> January 2010, which corresponds to Kamailio (former OpenSER) and SER
>> v3.0. The latest stable series v3.1 shares the same internal
>> architecture with v3.0.
>>
>> As part of the research work, Jan could also gather some figures about
>> capacity and performances of v3.0 with a quite complex configuration
>> file: etc/sip-router-oob.cfg (involving authentication and NAT
>> traversal as well).
>>
>> You can read the paper about energy efficiency at:
>>
>> - Green VoIP Article: http://asipto.com/u/2j
>>
>> The draft notes about capacity and performances of v3.0 are available at:
>>
>> - Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k
>>
>> Some interesting results:
>>
>> - one instance of SIP server with 500 000 online users (mixed users –
>> behind and not NAT routers) – consumed energy 210W
>> - one instance of SIP server with 1 000 000 online users (no NAT
>> involved) – consumed energy 190W
>> - on a 32-bit machine with 4GB of memory and with 2.5GB reserved for
>> SIP server, the server could support 43 000 simultaneous TLS
>> connections – consumed energy 203W
>> - one SIP server instance with 80 000 permanent TCP connections, the
>> SIP server could still handle at least 1000 requests per second and a
>> connection arrival rate of 1000 new connections per second, done for
>> 20 000 new connections. CPU load generated by the SIP server was from
>> 6% to 8%.
>>
>> I added a new section to the draft notes to list the enhancements done
>> for the latest stable release (v3.1.x) that contribute to performance
>> improvements, like asynchronous TLS, fine tuning of memory for TLS
>> connections and raw UDP sockets.
>>
>> Cheers,
>> Daniel
>>
>> 
>
>
> ___
> 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
>   

___
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] Green VoIP - energy efficiency and performaces of v3.0

[Jeremya]

Hello Henning,

My application is slightly different in that I have hundreds of nodes
each running an instance of Kamailio on embedded servers in a failure
tolerant configuration. This is in a risk-of-life application and each
node has large backup power supplies.

In reality kamailio takes milliwatts of the total load. What sucks power
at each node is the SIP devices, switches, and the CISCO routers foisted
on me by the client.
As an engineer (? I guess I am?) The boring stuff becomes important so
total power draw and life after power failure is very important. Without
the power hungry devices my kamailio systems can stay up for weeks after
power loss. With the SIP devices and routers I'm limited to hours of uptime.

Henning Westerholt wrote:
> On Wednesday 25 May 2011, Jeremya wrote:
>   
>> These figures pale into insignificance compared to the power required
>> for standard SIP devices - typically 5-8 watts per device multiplied by
>> the number of devices.
>>
>> When you factor in Gigabit Ethernet the power ups significantly.
>>
>> Optimisation at the server level is not significant on any scale.
>> Optimisation on communications power: i.e. end-devices, DSL & switches
>> is where the power savings are important.
>> 
>
> Hi Jeremya,
>
> you're right in this case - given the much higher number of CPE devices in 
> the 
> end user hands and especially as most of them use really cheap (also bad) 
> power supplies. But in generally optimisations on a server level are also 
> important, if you have a few thousand servers than even small amounts fast 
> add 
> up. And for the whole internet it already uses siginifcant part of the power, 
> close to 10% in the US to some research:
>
> http://hardware.slashdot.org/story/07/09/27/2157230/Internet-Uses-94-of-
> Electricity-In-the-US
>
> With regards to the research from Jan, the performance numbers are really 
> impressive, great work! 
>
> Cheers,
>
> Henning
>   

___
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] Wildcard TLS

[Iñaki Baz Castillo]

2011/5/24 Jon Farmer :
> I want to start offering TLS on a per customer basis. However I don't
> want to have to create a TLS certificate per customer if I don't need
> to. So I need to know if I can create a *.example.org certificate and
> use that for all customers who want TLS?

Hi Jon, please check RFC 5922 "Domain Certificates in the Session
Initiation Protocol (SIP)" as you don't need a TLS certificate for
each domain you server (this is a common misunderstanding):


7.3.  Client Behavior

   A client uses the domain portion of the SIP AUS to query a (possibly
   untrusted) DNS to obtain a result set, which is one or more SRV and A
   records identifying the server for the domain (see Section 4 for an
   overview).

   The SIP server, when establishing a TLS connection, presents its
   certificate to the client for authentication.  The client MUST
   determine the SIP domain identities in the server certificate using
   the procedure in Section 7.1.  Then, the client MUST compare the
   original domain portion of the SIP AUS used as input to the RFC 3263
   [8] server location procedures to the SIP domain identities obtained
   from the certificate.


7.1.  Finding SIP Identities in a Certificate

   Implementations (both clients and server) MUST determine the validity
   of a certificate by following the procedures described in RFC 5280
   [6].

   [...]

   Given an X.509 certificate that the above checks have found to be
   acceptable, the following describes how to determine what SIP domain
   identity or identities the certificate contains.  A single
   certificate can serve more than one purpose -- that is, the
   certificate might contain identities not acceptable as SIP, domain
   identities and/or might contain one or more identities that are
   acceptable for use as SIP domain identities.

   1.  Examine each value in the subjectAltName field.  The
   subjectAltName field and the constraints on its values are
   defined in Section 4.2.1.6 of RFC 5280 [6].  The subjectAltName
   field can be absent or can contain one or more values.

   [...]

   2.  If and only if the subjectAltName does not appear in the
   certificate, the implementation MAY examine the CN field of the
   certificate.  If a valid DNS name is found there, the
   implementation MAY accept this value as a SIP domain identity.
   Accepting a DNS name in the CN value is allowed for backward
   compatibility, but when constructing new certificates, consider
   the advantages of using the subjectAltName extension field (see
   Section 6).


6.  Certificate Usage by a SIP Service Provider

   It is possible for service providers to continue the practice of
   using existing certificates for SIP usage with the identity conveyed
   only in the Subject field, but they should carefully consider the
   following advantages of conveying identity in the subjectAltName
   extension field:

   o  The subjectAltName extension can hold multiple values, so the same
  certificate can identify multiple servers or sip domains.

   o  There is no fixed syntax specified for the Subject field, so
  issuers vary in how the field content is set.  This forces a
  recipient to use heuristics to extract the identity, again
  increasing opportunities for misinterpretation.


-- 
Iñaki Baz Castillo


___
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] 3.1.x and Kamailio compatibility mode

[Daniel-Constantin Mierla]

On 5/25/11 12:57 PM, Klaus Darilion wrote:



On 25.05.2011 12:18, Daniel-Constantin Mierla wrote:



On 5/25/11 12:11 PM, Klaus Darilion wrote:



On 25.05.2011 11:17, Daniel-Constantin Mierla wrote:



On 5/25/11 10:55 AM, Henning Westerholt wrote:

On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:

Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
behavior is changed by #!KAMAILIO?

it is still good to turn on vim syntax highlighting :-) (if you
installed the files from utils/misc/vim/ in ~/.vim/), otherwise 
is not

changing any kind of proxy behaviour whether it is present or not.

Ok, don't want to neglect the syntax highlighting.. ;-) What about
removing
this define then if its not necessary anymore for the server?
it is not a define like the other #!define, it is matched in the 
parser

and an internal value is set.

Probably it can be removed from the code, it should be 
harmless/useless

there. But it is rather useful in the default config for syntax
highlighting, being treated as a comment anyhow -- e.g., like in other
cases, many c files have the vim formatting commands in comments.


Does the define has to be in the first line of the config?


IMO we should add a comment like:

# Above Kamailio define is only for vim syntax highlighting and
# can be removed.

it is not a define, it is a comment. Like any comment, it can be safety
removed - imo makes no sense to add such note.

Only following tokens are pre-processor directives:
- #!define, #!ifdef, #!ifndef, #!else, #!endif, #!subst

So you can have your:

#!my text here

And it is simply comment. '#!' does not have a special meaning alone.
'#' has, and it is start of comment line. The parser is working with
longest match, so if pre-processor directives are not matched, then it
is a comment line.


Sorry for being to unspecified.

The comment "#!KAMILIO" was used to activate the compatibility mode. 
With 3.1 release this is not needed anymore.


Is this note written somewhere? If yes, then it should be removed, but 
otherwise I see no reason to bother with a comment line in order to add 
more comments.


Cheers,
Daniel


Thus, I see 2 options:
a) remove it from the default config
b) keep it there (e.g. for people who like vim syntax highlighting) 
and add another comment which explains that the line can safely remove 
for kamailio >= 3.1. Otherwise people like me will be confused and 
afraid to remove the comment.


regards
Klaus


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


___
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

[SR-Users] kamailio and radius

[Asun]

Hello 

 

I've installed kamailio 3.1 but It's doesn't Work with radius
authentication. I've followed this manual

http://www.kamailio.org/docs/openser-radius-1.0.x.html  but it does'nt work,
because is for openser not kamailio.

Is there another manual to do this? Anyone have radius authentication with
kamailio? Can anyone help me?

 

Thank you

Asun

___
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] Green VoIP - energy efficiency and performaces of v3.0

[Jan Janak]

On Wed, May 25, 2011 at 06:54, Jeremya  wrote:
> These figures pale into insignificance compared to the power required
> for standard SIP devices - typically 5-8 watts per device multiplied by
> the number of devices.
>
> When you factor in Gigabit Ethernet the power ups significantly.
>
> Optimisation at the server level is not significant on any scale.
> Optimisation on communications power: i.e. end-devices, DSL & switches
> is where the power savings are important.

Sure, the total power consumption of the whole system is dominated by
the power consumption of end-point devices, there's no doubt about
that and the paper says that.

Nevertheless, as an ITSP you are typically paying for the energy
consumed by your servers and in that case knowing what you can expect
and how many servers you need is useful. Modern data-center servers
have significant base-line power consumption and a portion of that
needs to be attributed to the SIP service running on those servers.

-Jan

> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> Jan Janak conducted a very interesting research project regarding
>> energy efficiency of VoIP systems during 2010, a collaboration between
>> iptel.org and Columbia University.
>>
>> The team used the source code from sip-router.org GIT repository from
>> January 2010, which corresponds to Kamailio (former OpenSER) and SER
>> v3.0. The latest stable series v3.1 shares the same internal
>> architecture with v3.0.
>>
>> As part of the research work, Jan could also gather some figures about
>> capacity and performances of v3.0 with a quite complex configuration
>> file: etc/sip-router-oob.cfg (involving authentication and NAT
>> traversal as well).
>>
>> You can read the paper about energy efficiency at:
>>
>> - Green VoIP Article: http://asipto.com/u/2j
>>
>> The draft notes about capacity and performances of v3.0 are available at:
>>
>> - Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k
>>
>> Some interesting results:
>>
>> - one instance of SIP server with 500 000 online users (mixed users –
>> behind and not NAT routers) – consumed energy 210W
>> - one instance of SIP server with 1 000 000 online users (no NAT
>> involved) – consumed energy 190W
>> - on a 32-bit machine with 4GB of memory and with 2.5GB reserved for
>> SIP server, the server could support 43 000 simultaneous TLS
>> connections – consumed energy 203W
>> - one SIP server instance with 80 000 permanent TCP connections, the
>> SIP server could still handle at least 1000 requests per second and a
>> connection arrival rate of 1000 new connections per second, done for
>> 20 000 new connections. CPU load generated by the SIP server was from
>> 6% to 8%.
>>
>> I added a new section to the draft notes to list the enhancements done
>> for the latest stable release (v3.1.x) that contribute to performance
>> improvements, like asynchronous TLS, fine tuning of memory for TLS
>> connections and raw UDP sockets.
>>
>> Cheers,
>> Daniel
>>
>
>
> ___
> 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
>

___
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] Wildcard TLS

[Klaus Darilion]

Inaki - are there any SIP implementations which implemented RFC 5922? I
suspect also Kamailio is not conform.

regards
Klaus

Am 25.05.2011 13:29, schrieb Iñaki Baz Castillo:
> 2011/5/24 Jon Farmer :
>> I want to start offering TLS on a per customer basis. However I don't
>> want to have to create a TLS certificate per customer if I don't need
>> to. So I need to know if I can create a *.example.org certificate and
>> use that for all customers who want TLS?
> 
> Hi Jon, please check RFC 5922 "Domain Certificates in the Session
> Initiation Protocol (SIP)" as you don't need a TLS certificate for
> each domain you server (this is a common misunderstanding):
> 
> 
> 7.3.  Client Behavior
> 
>A client uses the domain portion of the SIP AUS to query a (possibly
>untrusted) DNS to obtain a result set, which is one or more SRV and A
>records identifying the server for the domain (see Section 4 for an
>overview).
> 
>The SIP server, when establishing a TLS connection, presents its
>certificate to the client for authentication.  The client MUST
>determine the SIP domain identities in the server certificate using
>the procedure in Section 7.1.  Then, the client MUST compare the
>original domain portion of the SIP AUS used as input to the RFC 3263
>[8] server location procedures to the SIP domain identities obtained
>from the certificate.
> 
> 
> 7.1.  Finding SIP Identities in a Certificate
> 
>Implementations (both clients and server) MUST determine the validity
>of a certificate by following the procedures described in RFC 5280
>[6].
> 
>[...]
> 
>Given an X.509 certificate that the above checks have found to be
>acceptable, the following describes how to determine what SIP domain
>identity or identities the certificate contains.  A single
>certificate can serve more than one purpose -- that is, the
>certificate might contain identities not acceptable as SIP, domain
>identities and/or might contain one or more identities that are
>acceptable for use as SIP domain identities.
> 
>1.  Examine each value in the subjectAltName field.  The
>subjectAltName field and the constraints on its values are
>defined in Section 4.2.1.6 of RFC 5280 [6].  The subjectAltName
>field can be absent or can contain one or more values.
> 
>[...]
> 
>2.  If and only if the subjectAltName does not appear in the
>certificate, the implementation MAY examine the CN field of the
>certificate.  If a valid DNS name is found there, the
>implementation MAY accept this value as a SIP domain identity.
>Accepting a DNS name in the CN value is allowed for backward
>compatibility, but when constructing new certificates, consider
>the advantages of using the subjectAltName extension field (see
>Section 6).
> 
> 
> 6.  Certificate Usage by a SIP Service Provider
> 
>It is possible for service providers to continue the practice of
>using existing certificates for SIP usage with the identity conveyed
>only in the Subject field, but they should carefully consider the
>following advantages of conveying identity in the subjectAltName
>extension field:
> 
>o  The subjectAltName extension can hold multiple values, so the same
>   certificate can identify multiple servers or sip domains.
> 
>o  There is no fixed syntax specified for the Subject field, so
>   issuers vary in how the field content is set.  This forces a
>   recipient to use heuristics to extract the identity, again
>   increasing opportunities for misinterpretation.
> 
> 

___
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] 3.1.x and Kamailio compatibility mode

[Klaus Darilion]

Am 25.05.2011 14:03, schrieb Daniel-Constantin Mierla:
> 
> 
> On 5/25/11 12:57 PM, Klaus Darilion wrote:
>>
>>
>> On 25.05.2011 12:18, Daniel-Constantin Mierla wrote:
>>>
>>>
>>> On 5/25/11 12:11 PM, Klaus Darilion wrote:


 On 25.05.2011 11:17, Daniel-Constantin Mierla wrote:
>
>
> On 5/25/11 10:55 AM, Henning Westerholt wrote:
>> On Tuesday 24 May 2011, Daniel-Constantin Mierla wrote:
 Is #!KAMAILIO still necessary with Kamailio 3.1.x? If yes, which
 behavior is changed by #!KAMAILIO?
>>> it is still good to turn on vim syntax highlighting :-) (if you
>>> installed the files from utils/misc/vim/ in ~/.vim/), otherwise
>>> is not
>>> changing any kind of proxy behaviour whether it is present or not.
>> Ok, don't want to neglect the syntax highlighting.. ;-) What about
>> removing
>> this define then if its not necessary anymore for the server?
> it is not a define like the other #!define, it is matched in the
> parser
> and an internal value is set.
>
> Probably it can be removed from the code, it should be
> harmless/useless
> there. But it is rather useful in the default config for syntax
> highlighting, being treated as a comment anyhow -- e.g., like in other
> cases, many c files have the vim formatting commands in comments.

 Does the define has to be in the first line of the config?


 IMO we should add a comment like:

 # Above Kamailio define is only for vim syntax highlighting and
 # can be removed.
>>> it is not a define, it is a comment. Like any comment, it can be safety
>>> removed - imo makes no sense to add such note.
>>>
>>> Only following tokens are pre-processor directives:
>>> - #!define, #!ifdef, #!ifndef, #!else, #!endif, #!subst
>>>
>>> So you can have your:
>>>
>>> #!my text here
>>>
>>> And it is simply comment. '#!' does not have a special meaning alone.
>>> '#' has, and it is start of comment line. The parser is working with
>>> longest match, so if pre-processor directives are not matched, then it
>>> is a comment line.
>>
>> Sorry for being to unspecified.
>>
>> The comment "#!KAMILIO" was used to activate the compatibility mode.
>> With 3.1 release this is not needed anymore.
> 
> Is this note written somewhere? If yes, then it should be removed, but
> otherwise I see no reason to bother with a comment line in order to add
> more comments.

Seems like we talk at cross-purposes. I do not care about the default
config anymore - now I know that it is just a comment and I removed it
from my configs.

thanks
Klaus

___
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] Wildcard TLS

[Iñaki Baz Castillo]

2011/5/25 Klaus Darilion :
> Inaki - are there any SIP implementations which implemented RFC 5922? I
> suspect also Kamailio is not conform.

Honestly no idea. I will start playing further with TLS (also TLS
client authentication) soon, but for now I've not too much experience.

-- 
Iñaki Baz Castillo


___
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] Cancel issue

[Carl Wagner]

I am sorry, you are right.   I was looking at rfc3665 Page 71, F10 and 
it did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use 
rfc3261)


The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to 
construct the 200 (OK).



Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in 
the log below?
(I just included interactions between Asterisk and Kamailio as the other 
side of Kamailio looks to be working OK)



== Log ===
U 2011/05/24 15:18:46.871245 asterisk_IP:5060 -> kamailio_IP:5060
INVITE sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: .
Contact: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: Asterisk.
Max-Forwards: 70.
Date: Tue, 24 May 2011 21:18:46 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 238.
.
v=0.
o=root 27806 27806 IN IP4 asterisk_IP.
s=session.
c=IN IP4 asterisk_IP.
t=0 0.
m=audio 12234 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.


U 2011/05/24 15:18:46.874879 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.


U 2011/05/24 15:18:47.088929 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
Record-Route: .
Contact: 
.

To: ;tag=512af75a.
From: 
"+CallingPartyNumber";tag=as4c415d87.

Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: X-Lite release 1104o stamp 56125.
Content-Length: 0.
.


U 2011/05/24 15:18:56.123714 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.


U 2011/05/24 15:18:56.127349 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber" 
;tag=as4c415d87.
To: 
;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.

Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.


U 2011/05/24 15:18:56.310422 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
To: ;tag=512af75a.
From: 
"+CallingPartyNumber";tag=as4c415d87.

Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: X-Lite release 1104o stamp 56125.
Content-Length: 0.
.


U 2011/05/24 15:18:56.311992 asterisk_IP:5060 -> kamailio_IP:5060
ACK sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: ;tag=512af75a.
Contact: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 ACK.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.


U 2011/05/24 15:18:57.134340 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.


U 2011/05/24 15:18:57.136940 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber" 
;tag=as4c415d87.
To: 
;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.

Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.


U 2011/05/24 15:18:58.123319 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber" 
;tag=as4c415d87.

To: .
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.


U 2011/05/24 15:18:58.125872 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber" 
;tag=a

Re: [SR-Users] Cancel issue

[Iñaki Baz Castillo]

2011/5/25 Carl Wagner :
> I am sorry, you are right.   I was looking at rfc3665 Page 71, F10 and it
> did not have a To: tag in the 200 OK to the cancel.
> (I know that rfc3665 is just examples, and when in doubt I should use
> rfc3261)
>
> The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
> construct the 200 (OK).
>
>
> Not sure why Asterisk is not liking the 200 Canceling.
> Does anyone see anything wrong with the Cancel or the 200 Canceling in the
> log below?

Because Asterisk is buggy and expects (wrongly) that the Totag of the
CANCEL must match the Totag of a previously received 1XX response.
This is of course a wrong assumption as there could be diferent 1XX
responses with different Totag (when forking).

I remember that it just occurs if you set Asterisk sip.conf with
pendantic-mode enabled.

Asterisk is buggy.

-- 
Iñaki Baz Castillo


___
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] [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11

[Daniel-Constantin Mierla]

Hello,

for me it is so clear that the newer version is far more better than the 
old one since it will have a greater rfc number. Obvious! I cannot argue 
against it.


Cheers,
Daniel

PS. Guys, before implementing SIP-related RFC N, where N is greater than 
4000, wait until RFC N+3000 is published to see if there will be one 
obsoleting it. If not, you may be safe investing time in it.


On 5/25/11 1:00 PM, Iñaki Baz Castillo wrote:

Hi, for those interested in MSRP protocol (instant message sessions
and file transfer for SIP) there are bad news:

Even if there are already clients and servers (MSRP relays o IM
conference servers) implementing the MSRP protocol (RFC 4975 and 4976)
the SIMPLE WG will publish a new draft [*] that breaks these RFC's
just to satisfy big vendors interested in deploying MSRP capable
SBC/ALG boxes (so instead of solving NAT issues with MSRP relays as
RFC 4976 states, they want it to be fixed in the router by doing ugly
ALG, or in a SBC). This is terrible because all the MSRP devices
should implement this new draft in order to interoperate (no backward
compatibility at all). The draft also breaks the security defined in
RFC 4975 (for example, TLS name based authentication cannot work
anymore).

For further information I recommend reading these two posts:

   http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
   
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compatibility

and also these very *hot* mail threads in the SIMPLE maillist:

   http://www.ietf.org/mail-archive/web/simple/current/msg09227.html
   http://www.ietf.org/mail-archive/web/simple/current/msg09229.html



[*] http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11



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


___
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

[SR-Users] "ACK not received"

[Mokhtar Bengana]

I am trying to forward a DID to a sip account registered to Kamailio.
The call get established with two way audio and Kamailio shows it's
comming from an Asterisk server. However the call get disconnected
each time after 31s. Ngrep is showing "ACK not received" by the
Kamailio test account before the call get disconnected. If Kamailio is
suppose to send an ACK back to the asterisk server to keep the call
up, I am not sure why it's not happening. Or is it the other way
around? I have included the ngrep output. I appreciate any help.



U 2011/05/26 00:27:12.525344 91.121.81.212:5060 -> 192.168.2.4:5060
INVITE sip:t...@sipsoft.dyndns.org SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
From: "3313144859493" ;tag=as6c63c119.
To: .
Contact: .
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Date: Thu, 26 May 2011 00:27:10 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 260.
P-Antisip: forwarded with alias.
P-PMR: mediarelay enabled.
.
v=0.
o=root 10502 10502 IN IP4 91.121.81.212.
s=session.
c=IN IP4 91.121.81.212.
t=0 0.
m=audio 41316 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.


U 2011/05/26 00:27:12.526734 192.168.2.4:5060 -> 91.121.81.212:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
From: "3313144859493" ;tag=as6c63c119.
To: .
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
Server: kamailio (3.1.3 (x86_64/linux)).
Content-Length: 0.
.


U 2011/05/26 00:27:12.527013 192.168.2.4:5060 -> 192.168.2.8:65412
INVITE sip:test@192.168.2.8:65412;rinstance=befda46036a026ac SIP/2.0.
Record-Route: .
Record-Route: .
Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
From: "3313144859493" ;tag=as6c63c119.
To: .
Contact: .
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 68.
Date: Thu, 26 May 2011 00:27:10 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 260.
P-Antisip: forwarded with alias.
P-PMR: mediarelay enabled.
.
v=0.
o=root 10502 10502 IN IP4 91.121.81.212.
s=session.
c=IN IP4 91.121.81.212.
t=0 0.
m=audio 41316 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.


U 2011/05/26 00:27:12.601815 192.168.2.8:65412 -> 192.168.2.4:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
Record-Route: .
Record-Route: .
Contact: .
To: ;tag=1df26a5d.
From: "3313144859493";tag=as6c63c119.
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
User-Agent: X-Lite 4 release 4.0 stamp 58832.
Content-Length: 0.
.


U 2011/05/26 00:27:12.601967 192.168.2.4:5060 -> 91.121.81.212:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
Record-Route: .
Record-Route: .
Contact: .
To: ;tag=1df26a5d.
From: "3313144859493";tag=as6c63c119.
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
User-Agent: X-Lite 4 release 4.0 stamp 58832.
Content-Length: 0.
.


U 2011/05/26 00:27:22.568944 192.168.2.8:65412 -> 192.168.2.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
Record-Route: .
Record-Route: .
Contact: .
To: ;tag=1df26a5d.
From: "3313144859493";tag=as6c63c119.
Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
CSeq: 102 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
Content-Type: application/sdp.
Supported: replaces.
User-Agent: X-Lite 4 release 4.0 stamp 58832.
Content-Length: 371.
.
v=0.
o=- 12950843244293000 1 IN IP4 192.168.2.8.
s=CounterPath X-Lite 4.0.
c=IN IP4 192.168.2.8.
t=0 0.
a=ice-ufrag:b5d539.
a=ice-pwd:00ac4defa17299dce44e27bf54408a4c.
m=audio 54492 RTP/AVP 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=candidate:1 1 UDP 659136 192.168.2.8 54492 typ host.
a=candidate:1 2 UDP 659134 192.168.2.8 54493 typ host.


U 2011/05/26 

Re: [SR-Users] "ACK not received"

[Sergey Okhapkin]

No ACK from caller at 91.121.81.212.

On Wednesday 25 May 2011, Mokhtar Bengana wrote:
> I am trying to forward a DID to a sip account registered to Kamailio.
> The call get established with two way audio and Kamailio shows it's
> comming from an Asterisk server. However the call get disconnected
> each time after 31s. Ngrep is showing "ACK not received" by the
> Kamailio test account before the call get disconnected. If Kamailio is
> suppose to send an ACK back to the asterisk server to keep the call
> up, I am not sure why it's not happening. Or is it the other way
> around? I have included the ngrep output. I appreciate any help.
> 
> 
> 
> U 2011/05/26 00:27:12.525344 91.121.81.212:5060 -> 192.168.2.4:5060
> INVITE sip:t...@sipsoft.dyndns.org SIP/2.0.
> Record-Route: .
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Contact: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: Asterisk PBX.
> Max-Forwards: 69.
> Date: Thu, 26 May 2011 00:27:10 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 260.
> P-Antisip: forwarded with alias.
> P-PMR: mediarelay enabled.
> .
> v=0.
> o=root 10502 10502 IN IP4 91.121.81.212.
> s=session.
> c=IN IP4 91.121.81.212.
> t=0 0.
> m=audio 41316 RTP/AVP 8 101.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
> a=nortpproxy:yes.
> 
> 
> U 2011/05/26 00:27:12.526734 192.168.2.4:5060 -> 91.121.81.212:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> Server: kamailio (3.1.3 (x86_64/linux)).
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:12.527013 192.168.2.4:5060 -> 192.168.2.8:65412
> INVITE sip:test@192.168.2.8:65412;rinstance=befda46036a026ac SIP/2.0.
> Record-Route: .
> Record-Route: .
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Contact: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: Asterisk PBX.
> Max-Forwards: 68.
> Date: Thu, 26 May 2011 00:27:10 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 260.
> P-Antisip: forwarded with alias.
> P-PMR: mediarelay enabled.
> .
> v=0.
> o=root 10502 10502 IN IP4 91.121.81.212.
> s=session.
> c=IN IP4 91.121.81.212.
> t=0 0.
> m=audio 41316 RTP/AVP 8 101.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
> a=nortpproxy:yes.
> 
> 
> U 2011/05/26 00:27:12.601815 192.168.2.8:65412 -> 192.168.2.4:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: X-Lite 4 release 4.0 stamp 58832.
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:12.601967 192.168.2.4:5060 -> 91.121.81.212:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: X-Lite 4 release 4.0 stamp 58832.
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:22.568944 192.168.2.8:65412 -> 192.168.2.4:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> Content-Type: application/sdp.
> Supported: replaces.
> User-Agent: X-Lite 4 release 4.0 stamp 58832.
> Content-Length: 371.
> .
> v

Re: [SR-Users] "ACK not received"

[Alex Balashov]

This kind of ACK is end-to-end, not hop-by-hop, so it should be sent by the 
calling UA (and correctly forwarded by Kamailio).

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

On May 25, 2011, at 9:18 PM, Mokhtar Bengana  wrote:

> I am trying to forward a DID to a sip account registered to Kamailio.
> The call get established with two way audio and Kamailio shows it's
> comming from an Asterisk server. However the call get disconnected
> each time after 31s. Ngrep is showing "ACK not received" by the
> Kamailio test account before the call get disconnected. If Kamailio is
> suppose to send an ACK back to the asterisk server to keep the call
> up, I am not sure why it's not happening. Or is it the other way
> around? I have included the ngrep output. I appreciate any help.
> 
> 
> 
> U 2011/05/26 00:27:12.525344 91.121.81.212:5060 -> 192.168.2.4:5060
> INVITE sip:t...@sipsoft.dyndns.org SIP/2.0.
> Record-Route: .
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Contact: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: Asterisk PBX.
> Max-Forwards: 69.
> Date: Thu, 26 May 2011 00:27:10 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 260.
> P-Antisip: forwarded with alias.
> P-PMR: mediarelay enabled.
> .
> v=0.
> o=root 10502 10502 IN IP4 91.121.81.212.
> s=session.
> c=IN IP4 91.121.81.212.
> t=0 0.
> m=audio 41316 RTP/AVP 8 101.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
> a=nortpproxy:yes.
> 
> 
> U 2011/05/26 00:27:12.526734 192.168.2.4:5060 -> 91.121.81.212:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> Server: kamailio (3.1.3 (x86_64/linux)).
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:12.527013 192.168.2.4:5060 -> 192.168.2.8:65412
> INVITE sip:test@192.168.2.8:65412;rinstance=befda46036a026ac SIP/2.0.
> Record-Route: .
> Record-Route: .
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> From: "3313144859493" ;tag=as6c63c119.
> To: .
> Contact: .
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: Asterisk PBX.
> Max-Forwards: 68.
> Date: Thu, 26 May 2011 00:27:10 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
> Supported: replaces.
> Content-Type: application/sdp.
> Content-Length: 260.
> P-Antisip: forwarded with alias.
> P-PMR: mediarelay enabled.
> .
> v=0.
> o=root 10502 10502 IN IP4 91.121.81.212.
> s=session.
> c=IN IP4 91.121.81.212.
> t=0 0.
> m=audio 41316 RTP/AVP 8 101.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=silenceSupp:off - - - -.
> a=ptime:20.
> a=sendrecv.
> a=nortpproxy:yes.
> 
> 
> U 2011/05/26 00:27:12.601815 192.168.2.8:65412 -> 192.168.2.4:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: X-Lite 4 release 4.0 stamp 58832.
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:12.601967 192.168.2.4:5060 -> 91.121.81.212:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
> CSeq: 102 INVITE.
> User-Agent: X-Lite 4 release 4.0 stamp 58832.
> Content-Length: 0.
> .
> 
> 
> U 2011/05/26 00:27:22.568944 192.168.2.8:65412 -> 192.168.2.4:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
> Record-Route: .
> Record-Route: .
> Contact: .
> To: ;tag=1df26a5d.
> From: "3313144859493";tag=as6c63c119.
> Call-ID: 5e5ba375661c692

Re: [SR-Users] "ACK not received"

[Mokhtar Bengana]

Alex,

If I contact the calling UA 91.121.81.212 and give him my server ip
address and ask him to send me an ACK, he shouldn't have any problems
fulfilling my request? Since I am just testing, is this the best
approach when contacting another provider or is there another formal
way to do it?

Thanks,

On Wed, May 25, 2011 at 8:32 PM, Alex Balashov
 wrote:
> This kind of ACK is end-to-end, not hop-by-hop, so it should be sent by the 
> calling UA (and correctly forwarded by Kamailio).
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 260 Peachtree Street NW
> Suite 2200
> Atlanta, GA 30303
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> Web: http://www.evaristesys.com/
>
> On May 25, 2011, at 9:18 PM, Mokhtar Bengana  
> wrote:
>
>> I am trying to forward a DID to a sip account registered to Kamailio.
>> The call get established with two way audio and Kamailio shows it's
>> comming from an Asterisk server. However the call get disconnected
>> each time after 31s. Ngrep is showing "ACK not received" by the
>> Kamailio test account before the call get disconnected. If Kamailio is
>> suppose to send an ACK back to the asterisk server to keep the call
>> up, I am not sure why it's not happening. Or is it the other way
>> around? I have included the ngrep output. I appreciate any help.
>>
>>
>>
>> U 2011/05/26 00:27:12.525344 91.121.81.212:5060 -> 192.168.2.4:5060
>> INVITE sip:t...@sipsoft.dyndns.org SIP/2.0.
>> Record-Route: .
>> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
>> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
>> From: "3313144859493" ;tag=as6c63c119.
>> To: .
>> Contact: .
>> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
>> CSeq: 102 INVITE.
>> User-Agent: Asterisk PBX.
>> Max-Forwards: 69.
>> Date: Thu, 26 May 2011 00:27:10 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
>> Supported: replaces.
>> Content-Type: application/sdp.
>> Content-Length: 260.
>> P-Antisip: forwarded with alias.
>> P-PMR: mediarelay enabled.
>> .
>> v=0.
>> o=root 10502 10502 IN IP4 91.121.81.212.
>> s=session.
>> c=IN IP4 91.121.81.212.
>> t=0 0.
>> m=audio 41316 RTP/AVP 8 101.
>> a=rtpmap:8 PCMA/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=silenceSupp:off - - - -.
>> a=ptime:20.
>> a=sendrecv.
>> a=nortpproxy:yes.
>>
>>
>> U 2011/05/26 00:27:12.526734 192.168.2.4:5060 -> 91.121.81.212:5060
>> SIP/2.0 100 trying -- your call is important to us.
>> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
>> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
>> From: "3313144859493" ;tag=as6c63c119.
>> To: .
>> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
>> CSeq: 102 INVITE.
>> Server: kamailio (3.1.3 (x86_64/linux)).
>> Content-Length: 0.
>> .
>>
>>
>> U 2011/05/26 00:27:12.527013 192.168.2.4:5060 -> 192.168.2.8:65412
>> INVITE sip:test@192.168.2.8:65412;rinstance=befda46036a026ac SIP/2.0.
>> Record-Route: .
>> Record-Route: .
>> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
>> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
>> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
>> From: "3313144859493" ;tag=as6c63c119.
>> To: .
>> Contact: .
>> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
>> CSeq: 102 INVITE.
>> User-Agent: Asterisk PBX.
>> Max-Forwards: 68.
>> Date: Thu, 26 May 2011 00:27:10 GMT.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
>> Supported: replaces.
>> Content-Type: application/sdp.
>> Content-Length: 260.
>> P-Antisip: forwarded with alias.
>> P-PMR: mediarelay enabled.
>> .
>> v=0.
>> o=root 10502 10502 IN IP4 91.121.81.212.
>> s=session.
>> c=IN IP4 91.121.81.212.
>> t=0 0.
>> m=audio 41316 RTP/AVP 8 101.
>> a=rtpmap:8 PCMA/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=silenceSupp:off - - - -.
>> a=ptime:20.
>> a=sendrecv.
>> a=nortpproxy:yes.
>>
>>
>> U 2011/05/26 00:27:12.601815 192.168.2.8:65412 -> 192.168.2.4:5060
>> SIP/2.0 180 Ringing.
>> Via: SIP/2.0/UDP 192.168.2.4;branch=z9hG4bK33ad.55f7f307.0.
>> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
>> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
>> Record-Route: .
>> Record-Route: .
>> Contact: .
>> To: ;tag=1df26a5d.
>> From: "3313144859493";tag=as6c63c119.
>> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
>> CSeq: 102 INVITE.
>> User-Agent: X-Lite 4 release 4.0 stamp 58832.
>> Content-Length: 0.
>> .
>>
>>
>> U 2011/05/26 00:27:12.601967 192.168.2.4:5060 -> 91.121.81.212:5060
>> SIP/2.0 180 Ringing.
>> Via: SIP/2.0/UDP 91.121.81.212;branch=z9hG4bK33ad.da5ada05.0.
>> Via: SIP/2.0/UDP 188.165.98.47:5060;branch=z9hG4bK60ba8b25;rport=5060.
>> Record-Route: .
>> Record-Route: .
>> Contact: .
>> To: ;tag=1df26a5d.
>> From: "3313144859493";tag=as6c63c119.
>> Call-ID: 5e5ba375661c69273f32a463764879b0@188.165.98.47.
>> CSeq: 102 INVITE.