[asterisk-bugs] [Asterisk 0014418]: [patch] If a SIP URI is resolved with SRV records, the port must no be in the Request-URI

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14418 
====================================================================== 
Reported By:                klaus3000
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14418
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-02-06 04:04 CST
Last Modified:              2009-09-16 15:38 CDT
====================================================================== 
Summary:                    [patch] If a SIP URI is resolved with SRV records,
the port must no be in the Request-URI
Description: 
Hi!

If Asterisk resolves a SIP domain by SRV, it should use the resolved
IP:port for sending the transport only, not changing the RURI.

E.g. if Asterisk sends a request to sip:user at mydomain.com and resolves
using SRV, then the requests URI must not contain the port.






    -- Now forwarding SIP/u+437206200730153-b7058588 to
'SIP/2 at app.innofon.at' (thanks to SIP/u+437206200730151-08ef44e8)
    -- ast_get_srv: SRV lookup for '_sip._udp.app.innofon.at' mapped to
host app.innofon.at, port 5160
Audio is at 81.16.153.184 port 12012
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding codec 0x2 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 81.16.153.184:5160:
INVITE sip:2 at app.innofon.at:5160 SIP/2.0
Via: SIP/2.0/UDP 81.16.153.184:5160;branch=z9hG4bK462e8ee7;rport
From: "3 (SNOM 200)" <sip:3 at 81.16.153.184:5160>;tag=as054e6763
To: <sip:2 at app.innofon.at:5160>
Contact: <sip:3 at 81.16.153.184:5160>
Call-ID: 455000696c1b0a0829b83b384670155e at 81.16.153.184
CSeq: 102 INVITE
User-Agent: InnoSIP-app
Max-Forwards: 70
Date: Fri, 06 Feb 2009 09:55:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 334

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014419 [patch] Asterisk must not perform SRV l...
====================================================================== 

---------------------------------------------------------------------- 
 (0110841) mnicholson (administrator) - 2009-09-16 15:38
 https://issues.asterisk.org/view.php?id=14418#c110841 
---------------------------------------------------------------------- 
I tested my patch and it fixes most of the problems reported here.  Here is
a summary of my findings for each of the scenarios where URIs are
generated.

- port specified in dialplan: Dial(SIP/user at host:port)
With the patch this works properly.  I tested with port = 5060 and with
other port numbers.

- port provided by SIP client during registration
I don't think this works properly with fix2 but I am preparing fix3 that
should fix this.

- port provided in sip.conf peer definition
This works properly with the patch.

- port specified in dialplan and specified in sip.conf or during
registration: Dial(SIP/123 at peer:1234)
This mostly works properly although there are problems with how peers are
processed in the config file.  SRV lookups are done when sip.conf is loaded
regardless if a port is specified in the peer definition or not.  This can
cause problems if you later specify a port to the Dial command as the SRV
record may have specified a different host than the one in the dialplan. 
This case is somewhat complicated.



I also thought of one additional case:
- asterisk generated Register requests
I don't think these are handled properly, but I am going to consider this
a separate issue. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-16 15:38 mnicholson     Note Added: 0110841                          
======================================================================