Re: [SR-Users] Maintenance work on kamailio.org - Wed, Dec 17

[Daniel-Constantin Mierla]

Hello,

a reminder of the schedule maintenance work on kamailio.org server, to
be done later today, expected to start like 18:00 Berlin time.

Website, downloads of tarballs, wiki and mailing lists are the main
components to be affected. We hope that everything goes smooth and
eventual downtimes (the server will need to be restarted) will be barely
noticeable.

Cheers,
Daniel

On 15/12/14 11:53, Daniel-Constantin Mierla wrote:
> Hello,
>
> on Wednesday (Dec 17) late afternoon in Europe (probably starting around
> 18:00, Berlin time), we plan some maintenance work on kamailio.org
> server. Hopefully the downtime will be short and barely noticeable. But
> as we know, sometime we have to expect the unexpected, therefore in case
> the server is unavailable a bit longer, keep in mind that it is a
> scheduled work.
>
> Cheers,
> Daniel
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/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] t_suspend()/t_continue() problem

[Dmytro Bogovych]

Greetings.
I'm trying to adopt kamailio to handle incoming calls / generate push
notifications for softphone running on Windows Phone 8.
Starting point was this publication
http://www.kamailio.org/events/2014-KamailioWorld/day2/26-Daniel-Constantin.Mierla-Kamailio.cfg-Async.pdf

I adopted the script from publication a bit - now notification URI is
extracted from REGISTER messages + INVITE transactions are not
resuming when unregistering happens.

However it does not work for me yet.
I see the suspicious output in kamailio log when softphone registers
after incoming push notification.
Please ignore ERROR: level name - it is just dirty logging call, not
real problem.

Dec 17 14:20:11 voipobjects /usr/local/sbin/kamailio[29652]: ERROR:

Re: [SR-Users] What is raw 0.0.0.0:255 pn netstat??

[Cezary Siwek]

Hi there,

RAW sockets don’t bind to a port.  The 255 number you are seeing it’s the IP 
protocol number for RAW sockets.
As far as I know Kamailio always tries to use RAW sockets (if has been compiled 
with the USE_RAW_SOCKS flag).
Perhaps it should only use when udp4_raw core parameter is set to 1 but I’m not 
100% sure it’s actually related

Regards,
Cezary


From: sr-users-boun...@lists.sip-router.org 
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Luis Jimenez
Sent: 16 December 2014 14:15
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] What is raw 0.0.0.0:255 pn netstat??

Sure, here it is:

root@ivr:~# netstat -anp | grep raw
raw0  0 0.0.0.0:255 0.0.0.0:*   
7   12495/kamailio
root@ivr:~#

On Fri, Dec 12, 2014 at 5:39 AM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:
Hello,

can you give -p parameter to netstat to see the process which created the 
socket?

Cheers,
Daniel

On 09/12/14 17:51, Luis Jimenez wrote:
Hello, i just installed Kamailio 4.2.1 on debian Wheezy, would like to know why 
when Kamailio starts i see this on netstat -an ??

raw0  0 0.0.0.0:255 0.0.0.0:*   
7
is it normal??
why?
Thanks in advance



___

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



--

Daniel-Constantin Mierla

http://twitter.com/#!/miconda - http://www.linkedin.com/in/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
Truphone Limited, registered in England and Wales (registered company number: 
04187081). Registered office: CityPoint, One Ropemaker Street, London EC2Y 9SS. 
VAT No. GB 851 5278 19

This e-mail, and any attachment(s), may contain information which is 
confidential and/or privileged, and is intended for the addressee only. If you 
are not the intended recipient, you may not use, disclose, copy or distribute 
this information in any manner whatsoever. If you have received this e-mail in 
error, please contact the sender immediately and delete it.
___
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] Pseudo-Variables Digest

[Daniel-Constantin Mierla]

Hello,

do you want to set the values in the headers or to get the values from
the headers in variables?

Cheers,
Daniel

On 17/12/14 08:26, Kalala Alexander wrote:
> Hi,
> How to set these Pseudo-Variables ??
>  
> Auth nonce - the nonce from Authorization or Proxy-Authorization header
> Auth response - the authentication response from Authorization or
> Proxy-Authorization header
>  
>  
>  
> /--
> С уважением/
> /Инженер по телекоммуникациям /
> /Калала Александр /
> /vel: 375291146285/
> /life: 375256819996//
> /
> /skype: klistrod
> /
> / /
> /VoIP Network Engineer
> dCAP, CCNAVoice
> Kalala Alexander/
> http://callcenters.by/ //
> http://skytel.by/
> http://voiplab.by/
> http://asterisk-pbx.by/
>  
>  
>
>
> ___
> 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

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/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] Pseudo-Variables Digest

[Kalala Alexander]

Hello, I would like to get ;) 17.12.2014, 21:59, "Daniel-Constantin Mierla" :Hello,  do you want to set the values in the headers or to get the values from the headers in variables?  Cheers, Daniel On 17/12/14 08:26, Kalala Alexander wrote:Hi,How to set these Pseudo-Variables ?? Auth nonce - the nonce from Authorization or Proxy-Authorization headerAuth response - the authentication response from Authorization or Proxy-Authorization header   --  С уважениемИнженер по телекоммуникациям Калала Александр vel: 375291146285life: 375256819996 skype: klistrod  VoIP Network Engineer dCAP, CCNAVoice Kalala Alexanderhttp://callcenters.by/ http://skytel.by/http://voiplab.by/http://asterisk-pbx.by/   ___
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
-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda,___SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users  -- С уважениемИнженер по телекоммуникациям Калала Александр vel: 375291146285life: 375256819996skype: klistrod VoIP Network EngineerdCAP, CCNAVoiceKalala Alexanderhttp://callcenters.by/ http://skytel.by/http://voiplab.by/http://asterisk-pbx.by/  ___
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] bug in allow_source_address?

[Henry Fernandes]

I¹m using allow_source_address in my Kamailio config and have been for
months/years.  I¹ve had no issues with it until today.

The issue is that allow_source_address("1²) returns ³1" (for
$si=123.17.29.201 and $sp=5060) even though we don¹t have this IP address in
the Œaddress¹ table for group 1.  We have defined this IP address for group
2 but not group 1.

select * from address order by mask;

++-+---+--+--+--+

| id | grp | ip_addr   | mask | port | tag  |

++-+---+--+--+--+

| 20 |   1 | 123.17.0.0|   23 | 5061 | Testing  |

| 22 |   1 | 123.17.0.0|   23 | 5062 | Testing  |

| 23 |   1 | 123.17.0.0|   23 | 5063 | Testing  |

| 24 |   1 | 123.17.0.0|   23 | 5064 | Testing  |

|  1 |   1 | 123.17.0.0|   23 | 5060 |  |

|  4 |   1 | 20.5.176.0|   24 | 5060 |  |

| 21 |   1 | 123.17.1.235  |   32 | 5060 | Override |

| 46 |   2 | 123.17.29.201 |   32 | 5060 | customer |

++-+---+--+--+--+


Can anyone explain this?  I¹m wondering if there¹s a bug in how
allow_source_address does its net mask calculations.
-H


___
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] Maintenance work on kamailio.org - Wed, Dec 17

[Daniel-Constantin Mierla]

Hello,

the main work has been done, hopefully the main services are back in
good shape. If anyone notices some issue, email me.

Cheers,
Daniel

On 17/12/14 09:52, Daniel-Constantin Mierla wrote:
> Hello,
>
> a reminder of the schedule maintenance work on kamailio.org server, to
> be done later today, expected to start like 18:00 Berlin time.
>
> Website, downloads of tarballs, wiki and mailing lists are the main
> components to be affected. We hope that everything goes smooth and
> eventual downtimes (the server will need to be restarted) will be barely
> noticeable.
>
> Cheers,
> Daniel
>
> On 15/12/14 11:53, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> on Wednesday (Dec 17) late afternoon in Europe (probably starting around
>> 18:00, Berlin time), we plan some maintenance work on kamailio.org
>> server. Hopefully the downtime will be short and barely noticeable. But
>> as we know, sometime we have to expect the unexpected, therefore in case
>> the server is unavailable a bit longer, keep in mind that it is a
>> scheduled work.
>>
>> Cheers,
>> Daniel
>>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/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] SIP Fragments

[Marc Soda]

I'm having a problem reassembling UDP packets on my Asterisk servers after
passing through Kamailio (it appears to me an OS level issue, nothing to do
with Kamailio).  Is there a way, with Kamailio, to limit the size of a SIP
message?  I know I can just start removing headers, but that doesn't seem
like a realistic solution.  I see that Kamailio can compress the message
body, but can Asterisk handle that?  How do other people handle this?

Thanks in advance,
Marc
___
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] SIP Fragments

[Alex Balashov]

On 12/17/2014 05:14 PM, Marc Soda wrote:


I'm having a problem reassembling UDP packets on my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio).  Is there a way, with Kamailio, to limit
the size of a SIP message?  I know I can just start removing headers,
but that doesn't seem like a realistic solution.  I see that Kamailio
can compress the message body, but can Asterisk handle that?  How do
other people handle this?


1. Any SIP-compliant endpoint should be able to handle compact headers. 
Per RFC 3261 7.3.3 ("Compact Form"):


   Implementations MUST accept both the long and short forms of
   each header name.

2. Some headers are critical should not be removed. Others really are 
mostly useless bloat commonly added by verbose UACs, and, practically 
speaking, the other peer will be neither colder nor warmer if they are 
removed, unless there is a specific use for them.


Good candidates are:

a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.

3. If one or more of your endpoints offer every codec in the known 
universe in the SDP, you can restrict the codecs offered to reduce the 
SDP size.


4. You could use TCP. In fact, RFC 3261 actually mandates this. Per RFC 
3261 Section 18.1.1 ("Sending Requests"):


   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP.

Of course, in reality, nobody cares or follows this, and many SIP 
endpoints don't even support TCP (also mandated by RFC 3261).


5. In some situations, header bloat comes from requests passing through 
numerous proxies, each of which add a stackable Via header and, if 
applicable, a Route/Record-Route set.


Reducing the number of intermediate proxies can help with this.

6. You could run the traffic through a lightweight, signalling-only 
B2BUA, such as SEMS, which deals with fragmented UDP in incoming 
requests just fine, but does not reoriginate on leg B all the bloated 
headers that came in on leg A.


7. Other than these things, there are no real solutions.

-- Alex

--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States

Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

___
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] SIP Fragments

[Daniel-Constantin Mierla]

The safest way is to switch to tcp if the OS cannot do defrag of UDP
packets.

Kamailio cannot do much otherwise, however, if you want to play with
removing unecessary headers, look at keep_hf() function from textopsx
module.

Cheers,
Daniel

On 17/12/14 23:14, Marc Soda wrote:
> I'm having a problem reassembling UDP packets on my Asterisk servers
> after passing through Kamailio (it appears to me an OS level issue,
> nothing to do with Kamailio).  Is there a way, with Kamailio, to limit
> the size of a SIP message?  I know I can just start removing headers,
> but that doesn't seem like a realistic solution.  I see that Kamailio
> can compress the message body, but can Asterisk handle that?  How do
> other people handle this?
>
> Thanks in advance,
> Marc
>
>
> ___
> 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


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/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] SIP Fragments

[Daniel-Constantin Mierla]

On 17/12/14 23:20, Alex Balashov wrote:
> On 12/17/2014 05:14 PM, Marc Soda wrote:
>
>> I'm having a problem reassembling UDP packets on my Asterisk servers
>> after passing through Kamailio (it appears to me an OS level issue,
>> nothing to do with Kamailio).  Is there a way, with Kamailio, to limit
>> the size of a SIP message?  I know I can just start removing headers,
>> but that doesn't seem like a realistic solution.  I see that Kamailio
>> can compress the message body, but can Asterisk handle that?  How do
>> other people handle this?
>
> 1. Any SIP-compliant endpoint should be able to handle compact
> headers. Per RFC 3261 7.3.3 ("Compact Form"):
>
>Implementations MUST accept both the long and short forms of
>each header name.

I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens of bytes.

>
> 2. Some headers are critical should not be removed. Others really are
> mostly useless bloat commonly added by verbose UACs, and, practically
> speaking, the other peer will be neither colder nor warmer if they are
> removed, unless there is a specific use for them.
>
> Good candidates are:
>
> a) The "Date" header.
> b) Accept: headers listing every MIME type in the known universe.

Mentioned on my previous email too -- keep_hf() from textopsx module can
be handy here.

>
> 3. If one or more of your endpoints offer every codec in the known
> universe in the SDP, you can restrict the codecs offered to reduce the
> SDP size.

Another option to reduce the size -- sdpops module has related functions
for sdp management.

>
> 4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
> RFC 3261 Section 18.1.1 ("Sending Requests"):
>
>If a request is within 200 bytes of the path MTU, or if it is larger
>than 1300 bytes and the path MTU is unknown, the request MUST be sent
>using an RFC 2914 [43] congestion controlled transport protocol, such
>as TCP.
>
> Of course, in reality, nobody cares or follows this, and many SIP
> endpoints don't even support TCP (also mandated by RFC 3261).
>
> 5. In some situations, header bloat comes from requests passing
> through numerous proxies, each of which add a stackable Via header
> and, if applicable, a Route/Record-Route set.
>
> Reducing the number of intermediate proxies can help with this.
>
> 6. You could run the traffic through a lightweight, signalling-only
> B2BUA, such as SEMS, which deals with fragmented UDP in incoming
> requests just fine, but does not reoriginate on leg B all the bloated
> headers that came in on leg A.

SEMS (like any other application layer program) had very few to do with
fragmentation. It is the kernel/operating system that sorts all this. It
the application is the same 'recvfrom(...)'.

At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.

Cheers,
Daniel

>
> 7. Other than these things, there are no real solutions.
>
> -- Alex
>


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/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] SIP Fragments

[Marc Soda]

So gzcompress is no good with Asterisk then?  Is that meant to be used only
with another Kamailio proxy?

We're trying to do a WebRTC POC with Kamailio as the proxy.  The SIP
headers and SDP are huge!  I've never seen such big messages.

Thanks,
Marc

On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla  wrote:
>
> On 17/12/14 23:20, Alex Balashov wrote:
> > On 12/17/2014 05:14 PM, Marc Soda wrote:
> >
> >> I'm having a problem reassembling UDP packets on my Asterisk servers
> >> after passing through Kamailio (it appears to me an OS level issue,
> >> nothing to do with Kamailio).  Is there a way, with Kamailio, to limit
> >> the size of a SIP message?  I know I can just start removing headers,
> >> but that doesn't seem like a realistic solution.  I see that Kamailio
> >> can compress the message body, but can Asterisk handle that?  How do
> >> other people handle this?
> >
> > 1. Any SIP-compliant endpoint should be able to handle compact
> > headers. Per RFC 3261 7.3.3 ("Compact Form"):
> >
> >Implementations MUST accept both the long and short forms of
> >each header name.
>
> I don't think compact names for headers or joining bodies under single
> header name helps that much, it would be in the range of few tens of bytes.
>
> >
> > 2. Some headers are critical should not be removed. Others really are
> > mostly useless bloat commonly added by verbose UACs, and, practically
> > speaking, the other peer will be neither colder nor warmer if they are
> > removed, unless there is a specific use for them.
> >
> > Good candidates are:
> >
> > a) The "Date" header.
> > b) Accept: headers listing every MIME type in the known universe.
>
> Mentioned on my previous email too -- keep_hf() from textopsx module can
> be handy here.
>
> >
> > 3. If one or more of your endpoints offer every codec in the known
> > universe in the SDP, you can restrict the codecs offered to reduce the
> > SDP size.
>
> Another option to reduce the size -- sdpops module has related functions
> for sdp management.
>
> >
> > 4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
> > RFC 3261 Section 18.1.1 ("Sending Requests"):
> >
> >If a request is within 200 bytes of the path MTU, or if it is larger
> >than 1300 bytes and the path MTU is unknown, the request MUST be sent
> >using an RFC 2914 [43] congestion controlled transport protocol, such
> >as TCP.
> >
> > Of course, in reality, nobody cares or follows this, and many SIP
> > endpoints don't even support TCP (also mandated by RFC 3261).
> >
> > 5. In some situations, header bloat comes from requests passing
> > through numerous proxies, each of which add a stackable Via header
> > and, if applicable, a Route/Record-Route set.
> >
> > Reducing the number of intermediate proxies can help with this.
> >
> > 6. You could run the traffic through a lightweight, signalling-only
> > B2BUA, such as SEMS, which deals with fragmented UDP in incoming
> > requests just fine, but does not reoriginate on leg B all the bloated
> > headers that came in on leg A.
>
> SEMS (like any other application layer program) had very few to do with
> fragmentation. It is the kernel/operating system that sorts all this. It
> the application is the same 'recvfrom(...)'.
>
> At the end, Asterisk is also a B2BUA and I guess if there is a server
> with an OS that can handle udp fragmentation, the Asterisk will be run
> there instead of adding another b2bua.
>
> Cheers,
> Daniel
>
> >
> > 7. Other than these things, there are no real solutions.
> >
> > -- Alex
> >
>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/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
>
___
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] SIP Fragments

[Alex Balashov]

Indeed, gzcompress is a Kamailio-only concept. 

On 17 December 2014 20:58:22 GMT-05:00, Marc Soda  wrote:
>So gzcompress is no good with Asterisk then?  Is that meant to be used
>only
>with another Kamailio proxy?
>
>We're trying to do a WebRTC POC with Kamailio as the proxy.  The SIP
>headers and SDP are huge!  I've never seen such big messages.
>
>Thanks,
>Marc
>
>On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla
>> wrote:
>>
>> On 17/12/14 23:20, Alex Balashov wrote:
>> > On 12/17/2014 05:14 PM, Marc Soda wrote:
>> >
>> >> I'm having a problem reassembling UDP packets on my Asterisk
>servers
>> >> after passing through Kamailio (it appears to me an OS level
>issue,
>> >> nothing to do with Kamailio).  Is there a way, with Kamailio, to
>limit
>> >> the size of a SIP message?  I know I can just start removing
>headers,
>> >> but that doesn't seem like a realistic solution.  I see that
>Kamailio
>> >> can compress the message body, but can Asterisk handle that?  How
>do
>> >> other people handle this?
>> >
>> > 1. Any SIP-compliant endpoint should be able to handle compact
>> > headers. Per RFC 3261 7.3.3 ("Compact Form"):
>> >
>> >Implementations MUST accept both the long and short forms of
>> >each header name.
>>
>> I don't think compact names for headers or joining bodies under
>single
>> header name helps that much, it would be in the range of few tens of
>bytes.
>>
>> >
>> > 2. Some headers are critical should not be removed. Others really
>are
>> > mostly useless bloat commonly added by verbose UACs, and,
>practically
>> > speaking, the other peer will be neither colder nor warmer if they
>are
>> > removed, unless there is a specific use for them.
>> >
>> > Good candidates are:
>> >
>> > a) The "Date" header.
>> > b) Accept: headers listing every MIME type in the known universe.
>>
>> Mentioned on my previous email too -- keep_hf() from textopsx module
>can
>> be handy here.
>>
>> >
>> > 3. If one or more of your endpoints offer every codec in the known
>> > universe in the SDP, you can restrict the codecs offered to reduce
>the
>> > SDP size.
>>
>> Another option to reduce the size -- sdpops module has related
>functions
>> for sdp management.
>>
>> >
>> > 4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
>> > RFC 3261 Section 18.1.1 ("Sending Requests"):
>> >
>> >If a request is within 200 bytes of the path MTU, or if it is
>larger
>> >than 1300 bytes and the path MTU is unknown, the request MUST be
>sent
>> >using an RFC 2914 [43] congestion controlled transport protocol,
>such
>> >as TCP.
>> >
>> > Of course, in reality, nobody cares or follows this, and many SIP
>> > endpoints don't even support TCP (also mandated by RFC 3261).
>> >
>> > 5. In some situations, header bloat comes from requests passing
>> > through numerous proxies, each of which add a stackable Via header
>> > and, if applicable, a Route/Record-Route set.
>> >
>> > Reducing the number of intermediate proxies can help with this.
>> >
>> > 6. You could run the traffic through a lightweight, signalling-only
>> > B2BUA, such as SEMS, which deals with fragmented UDP in incoming
>> > requests just fine, but does not reoriginate on leg B all the
>bloated
>> > headers that came in on leg A.
>>
>> SEMS (like any other application layer program) had very few to do
>with
>> fragmentation. It is the kernel/operating system that sorts all this.
>It
>> the application is the same 'recvfrom(...)'.
>>
>> At the end, Asterisk is also a B2BUA and I guess if there is a server
>> with an OS that can handle udp fragmentation, the Asterisk will be
>run
>> there instead of adding another b2bua.
>>
>> Cheers,
>> Daniel
>>
>> >
>> > 7. Other than these things, there are no real solutions.
>> >
>> > -- Alex
>> >
>>
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/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
>>
>
>
>
>
>___
>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

--
Sent from my mobile, and thus lacking in the refinement one might expect from a 
fully fledged keyboard. 

Alex Balashov - Principal 
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.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] SIP Fragments

[Alex Balashov]

And yeah, WebRTC is morbidly obese. I think your best bet is to use TCP. 
--
Sent from my mobile, and thus lacking in the refinement one might expect from a 
fully fledged keyboard. 

Alex Balashov - Principal 
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.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] SIP Fragments

[Richard Fuchs]

On 12/17/14 21:14, Alex Balashov wrote:
> And yeah, WebRTC is morbidly obese. I think your best bet is to use TCP. 

... or try to fix your networking.

cheers

___
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] Any extension or solution on how to implement RPC over SIP

[Thierry Luo]

Dear all,

 

I'm trying to design a SIP based framework that can execute RPC end-to-end.
Session is set up based on SIP, and then one user agent can remote call a
method into the peer user agent.

 

Anyone have any solution on this? Thanks.

 

Best Regards.

 

Thierry Luo

___
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