|Summary:||ASTERISK-16884: [patch] add Path header support to chan_sip|
|Date Opened:||2010-10-27 15:00:50||Date Closed:||2013-03-05 07:20:39.000-0600|
|Environment:||Attachments:||( 0) path-1.8.0-patch.txt|
|Description:||This patch adds Path header support (RFC 3327) to Asterisk. You just have to activate "usepath=yes" in sip.conf for the peer.|
****** ADDITIONAL INFORMATION ******
currently the Path header is parsed (re-using the Record-Router parser) and stored in the peer structure. It is also stored/read to/form astDB. Realtime support is missing yet (any hints are appreciated).
I did basic testing and it worked so far (it is almost impossible to understand to which destination the request will finally be sent (global OBP, peer OBP, nat=yes, ...). Some of these decisions are done in Asterisk during REGISTER handling, some are done during message sending. IMO it should be only done during message sending)
|Comments:||By: Leif Madsen (lmadsen) 2010-11-02 08:50:47|
This is a new feature, and should really be filed against trunk.
By: Iñaki Baz Castillo (ibc) 2012-03-28 15:18:49.140-0500
This feature is REALLY interesting and important. Please, consider it.
By: Olle Johansson (oej) 2012-09-04 17:10:09.675-0500
For some strange reason, the reviewboard issue has been marked as "submitted".
I've created a branch for this patch and added (yet untested) support for realtime and an option in the [general] section of sip.conf (tested).
Testing the code with Kamailio, it works great.
By: Iñaki Baz Castillo (ibc) 2012-09-05 06:11:29.297-0500
Hi Olle, does the patch support more than a single Path header? I can test it if there is some Asterisk online with the patch applied.
By: Olle Johansson (oej) 2012-12-07 04:40:27.101-0600
This is now in https://reviewboard.asterisk.org/r/2235/
I have a branch for trunk: oolong-path-support-trunk
Yes, it should support more than one Path header. Let's test, Iñaki.
By: Iñaki Baz Castillo (ibc) 2012-12-10 08:16:19.377-0600
Hi Olle, the problem is when the outbound proxy forwards the REGISTER (by adding Path header) to Asterisk via TCP/TLS. In that case Asterisk will always attempt to reuse the proxy initiated connection (which is not persistent) for sending incoming requests to the registered client.
This basically means that if clients send a REGISTER (via UDP/TCP/TLS/WS/WSS) to an outbound proxy, the outbound proxy forwards them to Asterisk via TCP, and later the proxy is restarted, then all the registrations are lost since Asterisk will not attempt to route the requests for clients to the URI in the Path header (which looks like "sip:PROXY_IP:5060;transport=tcp") but instead Asterisk assumes that the communication has been broken due to the TCP disconection. So all the registration bindings are lost until clients register again. Sad.
This is clearly explained in: ASTERISK-20644
By: Olle Johansson (oej) 2012-12-10 08:28:05.289-0600
Unfortunately that is a general problem with the TCP/TLS implementation in chan_sip, which was bad from start. This patch doesn't change or improve that.
I believe that part is covered by a separate issue in this bug tracker.
By: Olle Johansson (oej) 2013-01-22 10:10:39.108-0600
Discovered a bug in the 1.8 patch that works in the 1.4 version. Will need to check why OPTIONS messages are not routed according to the route header. The Route: header is added (based on Path in the REGISTER) but we still transmit to the Contact.
The wonders of the TCP/TLS patch messing with routing I guess.
By: Daniel Pocock (daniel.pocock) 2016-12-14 07:18:06.016-0600
Browsing the repository, it appears that this patch was merged just before 1.8.22 RC1
Can somebody update the bug report meta data to confirm if 1.8.22 is the first version including this feature?
By: Walter Doekes (wdoekes) 2016-12-14 07:35:32.974-0600
Git log says no:
$ git log origin/1.8 | grep 'Add RFC 3327 Path header support to chan_sip'
It appears first in 12. Which coincidentally matches with the "merged into these tags" list you see here:
(note that that list doesn't work for newer commits)
And it matches with the list here:
By: Daniel Pocock (daniel.pocock) 2016-12-14 09:56:18.222-0600
Yes, I was scrolling through the repository with gitk, looking again I notice there is a break in the line before it reaches 1.8.22 so it is not in that release.