[asterisk-bugs] [JIRA] (ASTERISK-16884) [patch] add Path header support to chan_sip

Iñaki Baz Castillo (JIRA) noreply at issues.asterisk.org
Mon Dec 10 08:16:45 CST 2012


    [ https://issues.asterisk.org/jira/browse/ASTERISK-16884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200568#comment-200568 ] 

Iñaki Baz Castillo commented on ASTERISK-16884:
-----------------------------------------------

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: https://issues.asterisk.org/jira/browse/ASTERISK-20644
                
> [patch] add Path header support to chan_sip
> -------------------------------------------
>
>                 Key: ASTERISK-16884
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16884
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: Channels/chan_sip/NewFeature
>            Reporter: klaus3000
>         Attachments: path-1.8.0-patch.txt
>
>
> 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)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list