19 Mar
2016
19 Mar
'16
9:26 p.m.
Hi,
Is there any way to remove Via and Record-Route headers from requests sent
to an endpoint and update the contact header, but have Kamailio statefully
remember where the replies need to route?
I imagine this would involve mangling the packets slightly to behave
similar to a B2BUA.
My motivations, in order of priority -
1) Reduce UDP packet size to avoid MTU limitations
2) Improve interoperability, don't expect end points to be able to properly
parse / process many via / record-route headers
3) Hide topology.
If someone could point me in the right direction in terms of configuration
or modules, that would be great.
Thanks
19 Mar
19 Mar
9:27 p.m.
Marrold,
No, you can't remove those headers. They serve an essential purpose and
the endpoints won't consider the requests or responses valid without them.
See my blog post on this topic:
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-heade…
And you certainly can't hide topology this way.
-- Alex
On 03/19/2016 09:26 PM, Marrold wrote:
Hi,
Is there any way to remove Via and Record-Route headers from requests
sent to an endpoint and update the contact header, but have Kamailio
statefully remember where the replies need to route?
I imagine this would involve mangling the packets slightly to behave
similar to a B2BUA.
My motivations, in order of priority -
1) Reduce UDP packet size to avoid MTU limitations
2) Improve interoperability, don't expect end points to be able to
properly parse / process many via / record-route headers
3) Hide topology.
If someone could point me in the right direction in terms of
configuration or modules, that would be great.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
9:41 p.m.
Thanks for your quick response.
No, you can't remove those headers. They serve an essential purpose and the
endpoints won't consider the requests or responses
valid without them.
It should be theoretically possible to remove some of the via and
record-route headers, assuming the contact is also re-written. The end
point's (phones) themselves do not need to be aware of anything downstream
of the SIP server they're registered too.
See my blog post on this topic:
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-heade…
Thanks for the link!
And you certainly can't hide topology this way.
-- Alex
On 03/19/2016 09:26 PM, Marrold wrote:
Hi,
Is there any way to remove Via and Record-Route headers from requests
sent to an endpoint and update the contact header, but have Kamailio
statefully remember where the replies need to route?
I imagine this would involve mangling the packets slightly to behave
similar to a B2BUA.
My motivations, in order of priority -
1) Reduce UDP packet size to avoid MTU limitations
2) Improve interoperability, don't expect end points to be able to
properly parse / process many via / record-route headers
3) Hide topology.
If someone could point me in the right direction in terms of
configuration or modules, that would be great.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
21 Mar
21 Mar
4:40 a.m.
Depending from case to case, the record-routing can be avoided,
especially if you know the environment and only one server is used
between two endpoints. At that moment you can store existing contact in
htable and replace it with one having the server ip. You can eventually
use uuid to generate the contact to be unique, but not a must.
The logic would be:
- call comes in, store $sht(x=>$ci::a1:contact) = contact uri
- store $sht(x=>$ci::a1:ftag) = From tag
- replace contact header with one using server ip and send out
- store new contact uri as $sht(x=>$ci::a2:contact)
- replies comes in, store $sht(x=>$ci::b1:contact) = contact uri
- replace contact header with another new one using server ip and send out
- store new contact uri as $sht(x=>$ci::b2:contact)
- when a request within dialog comes in, based on From tag and
$sht(x=>$ci::a1:ftag), you detect the direction and based on that you
set the appropriate r-uri using either $sht(x=>$ci::a1:contact) or
$sht(x=>$ci::b1:contact) and replace the contact with a2/b2 variants
Alternative to htable is to use database or other storage (e.g., nosql
like redis, mongo, ...).
As a matter of fact, upcoming 4.4 includes the topos module which should
do what you want here, but due to lack of time caused by some unexpected
events, at this moment works properly only for MESSAGE requests. By the
time of release I should have the time to fix the dialog routing as well.
Cheers,
Daniel
On 20/03/16 02:41, Matthew Harrold wrote:
Thanks for your quick response.
No, you can't remove those headers. They serve an essential
purpose and the endpoints won't consider the requests or responses
valid without them.
It should be theoretically possible to remove some of the via and
record-route headers, assuming the contact is also re-written. The end
point's (phones) themselves do not need to be aware of anything
downstream of the SIP server they're registered too.
See my blog post on this topic:
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-heade…
Thanks for the link!
And you certainly can't hide topology this way.
-- Alex
On 03/19/2016 09:26 PM, Marrold wrote:
Hi,
Is there any way to remove Via and Record-Route headers from
requests
sent to an endpoint and update the contact header, but have
Kamailio
statefully remember where the replies need to route?
I imagine this would involve mangling the packets slightly to
behave
similar to a B2BUA.
My motivations, in order of priority -
1) Reduce UDP packet size to avoid MTU limitations
2) Improve interoperability, don't expect end points to be able to
properly parse / process many via / record-route headers
3) Hide topology.
If someone could point me in the right direction in terms of
configuration or modules, that would be great.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) /
+1-678-954-0671 <tel:%2B1-678-954-0671> (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org <mailto: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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com
1:52 p.m.
I grant that the necessary statekeeping is technically possible with
enough spiritual commitment, yes, but would repeat my entreatment to ask
whether it should be done just because it can be done.
Nothing to do with "RFC purity", just a question of best-practical
solution with fewest failure modes, given that the objectives are to
solve well-known problems (topology hiding, UDP fragmentation) to which
there exist well-known, time-tested and standards-compliant solutions.
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
19 Mar
19 Mar
9:43 p.m.
Thanks for your quick response.
No, you can't remove those headers. They serve an essential purpose and the
endpoints won't consider the requests or responses
valid without them.
It should be theoretically possible to remove some of the via and
record-route headers, assuming the contact is also re-written. The end
point's (phones) themselves do not need to be aware of anything downstream
of the SIP server they're registered too.
See my blog post on this topic:
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-heade…
Thanks for the link!
On Sun, Mar 20, 2016 at 1:27 AM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
> Marrold,
>
> No, you can't remove those headers. They serve an essential purpose and
> the endpoints won't consider the requests or responses valid without them.
See my blog post on this topic:
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-heade…
>
> And you certainly can't hide topology this way.
>
> -- Alex
>
>
> On 03/19/2016 09:26 PM, Marrold wrote:
>
> Hi,
>>
>> Is there any way to remove Via and Record-Route headers from requests
>> sent to an endpoint and update the contact header, but have Kamailio
>> statefully remember where the replies need to route?
>>
>> I imagine this would involve mangling the packets slightly to behave
>> similar to a B2BUA.
>>
>> My motivations, in order of priority -
>>
>> 1) Reduce UDP packet size to avoid MTU limitations
>> 2) Improve interoperability, don't expect end points to be able to
>> properly parse / process many via / record-route headers
>> 3) Hide topology.
>>
>> If someone could point me in the right direction in terms of
>> configuration or modules, that would be great.
>>
>> Thanks
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 1447 Peachtree Street NE, Suite 700
> Atlanta, GA 30309
> United States
>
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
10:40 p.m.
On 03/19/2016 09:43 PM, Marrold wrote:
It should be theoretically possible to remove some of
the via and
record-route headers, assuming the contact is also re-written. The end
point's (phones) themselves do not need to be aware of anything
downstream of the SIP server they're registered too.
No, because intermediate endpoints:
(1) Expect the Route set to remain as configured between the two endpoints;
(2) Expect Vias corresponding to their hop to remain as upstream
elements remove theirs in transit.
You can't break SIP like that - terribly sorry! :-)
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
10:54 p.m.
I understand intermediate endpoints *expect* these headers, this is why I
asked if there's anyway for Kamailio to remember what is removed and
essentially re-add them to the response, IE-
SIP request hits edge proxy from internal network > Via and Route headers
from intermediate proxies are removed, previous 'path' is stored in memory
linked to the dialog > SIP request is forwarded to end point.
End point responds to request via edge proxy > edge proxy looks up existing
dialog and reinserts the missing headers > forwards to the next hop.
What I'm asking is theoretically possible, although it may not be RFC
compliant or something that Kamailio supports.
Thanks
On Sun, Mar 20, 2016 at 2:40 AM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On 03/19/2016 09:43 PM, Marrold wrote:
It should be theoretically possible to remove some of the via and
record-route headers, assuming the contact is
also re-written. The end
point's (phones) themselves do not need to be aware of anything
downstream of the SIP server they're registered too.
No, because intermediate endpoints:
(1) Expect the Route set to remain as configured between the two endpoints;
(2) Expect Vias corresponding to their hop to remain as upstream elements
remove theirs in transit.
You can't break SIP like that - terribly sorry! :-)
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:57 p.m.
So, you mean some sort of scheme wherein...
(1) Kamailio keeps endpoint A in the dark as to the fact that anything
was removed;
(2) Kamailio portrays itself as a UA/origin of all requests?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
11:03 p.m.
That's essentially what I'm hoping for, although I appreciate from an RFC
purist perspective it's probably a bit of a nasty hack.
On Sun, Mar 20, 2016 at 2:57 AM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
So, you mean some sort of scheme wherein...
(1) Kamailio keeps endpoint A in the dark as to the fact that anything was
removed;
(2) Kamailio portrays itself as a UA/origin of all requests?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:10 p.m.
On 03/19/2016 11:03 PM, Marrold wrote:
That's essentially what I'm hoping for,
although I appreciate from an
RFC purist perspective it's probably a bit of a nasty hack.
It's not a question of pedantic RFC purism so much as:
(a) Whether it creates at least as many complications as it solves;
solutions like this one create so many complications, corner cases and
statekeeping requirements that they represent - to borrow a term from
philosophy of science - a "degenerative heuristic". This means crawling
down a rabbit hole to solve the wrong problem the wrong way and just
getting tangled.
But perhaps a more applicable term would be:
https://en.wikipedia.org/wiki/Anti-pattern
(b) Whether it's truly the most effective solution to the problem. It
seems to me you're solving the wrong problem; solutions for UDP
fragmentation (use TCP, remove other, less essential headers) and
topology hiding (B2BUA) are well-understood and canonical.
(c) Technically possible.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
3218
days inactive
3219
days old
10 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Marrold -
Matthew Harrold