[Home]

Summary:ASTERISK-12625: Dial(SIP/exten@host:port) ignores port
Reporter:Alistair Cunningham (acunningham)Labels:
Date Opened:2008-08-21 09:02:06Date Closed:2008-08-29 10:17:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13355.patch
( 1) 13355v2.patch
( 2) dial1.txt
Description:If you do a Dial to a non-standard port, for example:

Dial(SIP/conference@1.2.3.4:5070)

the port (5070) is ignored by Asterisk.

****** ADDITIONAL INFORMATION ******

I will upload a trace fragment that shows this in real life. The full trace is available on request.
Comments:By: Alistair Cunningham (acunningham) 2008-08-21 09:03:24

dial1.txt uploaded. IP addresses have been changed to protect the innocent.
By: Mark Michelson (mmichelson) 2008-08-26 15:06:58

Interesting. I tried this on my box with both 1.4.21.1 and the latest 1.4 subversion revision and both worked fine when I attempted this. I tried with various NAT settings (since that can affect where SIP traffic is sent) and the INVITE was still sent to the proper port.

The problem I'm having right now is I don't really have anything constructive to offer with regards to how to track this down. Just out of curiosity, what is your nat setting in sip.conf? That's the only thing I can immediately think of that could be causing this to happen.
By: Alistair Cunningham (acunningham) 2008-08-26 17:08:15

There is a peer for this IP address:

[1.2.3.4]
host = 1.2.3.4
fromdomain = 1.2.3.4
type = friend
insecure = port,invite
context = from-internal
canreinvite = no
nat = yes

OpenSER is listening on port 5060, and Asterisk on 5070, on this machine. We have the peer so that we can set "nat = yes" for NATed SIP phones registered to OpenSER. What I'm guessing is happening is that the peer is matching, and using the "port = 5060" that's being set in [general] despite the Dial() explicitly setting the port. Perhaps setting "port = 5060" in the peer would prevent it from matching at all? I'll ask the person who can make test calls to try this and see if it helps.


By: Alistair Cunningham (acunningham) 2008-08-27 03:46:55

Adding "port = 5060" to the peer did not help.
By: Mark Michelson (mmichelson) 2008-08-27 09:57:06

With the help of Josh Colp, I have figured out why it is that this was not working for you, but it was working for me. The short answer is that your peer's name is the same as its IP address.

When Dial is called, the string of the peer you are calling is passed to the SIP channel driver (called chan_sip from here on). In this case, the string is conference@1.2.3.4:5070. chan_sip then looks for an '@' sign in the string. If it is there, then it attempts to route the call based on what is after the '@' sign. In your case, it tries to route based on 1.2.3.4:5070. In determining how to route the call, chan_sip first strips off the port and tries to see if the part before the port is the name of a peer in sip.conf. In your case, it is. Since there is a peer in sip.conf called 1.2.3.4, it uses the host and port information from the peer entry instead of what was passed in the Dial string. In other words, if you wanted to have calls to 1.2.3.4 go to port 5070, then placing "port=5070" in sip.conf for that peer should allow what you're trying to do to work.

However, I do think there is something lacking here because you should be able to dial a peer but override the port specified in sip.conf. I will work on a patch which will allow for this to happen.
By: Alistair Cunningham (acunningham) 2008-08-27 10:05:49

Thank you. Unfortunately we can't put "port = 5070" in the peer because this peer is actually intended to be for calls to OpenSER.

Perhaps the best thing would that if "port = 5060" was set in the peer in extensions.conf, the peer would only match for calls to that port. If no port was specified in the peer at all, the peer would match for calls to any port at that IP address. This would, I think, make it work for us, work for everyone else, and be a reasonably intuitive way of doing it.
By: Leif Madsen (lmadsen) 2008-08-27 10:48:19

putnopvut has publically agreed to move this issue along, so it is being assigned to him :)  Changed status to acknowledged as the developer has acknowledged an issue exists here.
By: Mark Michelson (mmichelson) 2008-08-27 11:10:00

acunningham: I see what you're saying, but I do see a potential downside. If we attempt to match a peer based on both the name and port, and come up with no match, then Asterisk will route the call the the IP address and port specified in the Dial string. The problem is that if this occurs, then none of the settings in sip.conf for that peer will be applied for the call. While this may not be a problem for your setup, it could cause problems for others.

My idea for a change was a bit simpler. If a port is specified in the string to Dial, never ignore it and always route calls to that destination port, no matter what may be listed in sip.conf. This way, you would still get your peer settings for the call but it would routed to the port that was specified in Dial.
By: Alistair Cunningham (acunningham) 2008-08-27 11:11:37

That's fair enough, and suits us.
By: Mark Michelson (mmichelson) 2008-08-27 13:57:54

I have upload 13355 for testing. Let me know if it works for your setup. Thanks!
By: Alistair Cunningham (acunningham) 2008-08-27 14:10:18

Thank you. I have applied this patch, and will the person who can make test calls to try it out.
By: Alistair Cunningham (acunningham) 2008-08-27 16:38:36

Unfortunately that seemed to break calls to OpenSER on port 5060. From a trace:

Executing [50011003@enswitch-phone:3] Dial("Local/50011003@enswitch-phone-0b69,2", "SIP/50011003@1.2.3.4:5060|3600|ot") in new stack

Then a few lines later:

Reliably Transmitting (NAT) to 1.2.3.4:50195:
INVITE sip:50011003@1.2.3.4:50195 SIP/2.0
By: Mark Michelson (mmichelson) 2008-08-27 17:18:21

I forgot to change the port to network byte order. New patch coming.
By: Mark Michelson (mmichelson) 2008-08-27 17:19:36

13355v2.patch uploaded. Try that out.
By: Alistair Cunningham (acunningham) 2008-08-29 07:17:24

This now seems to be working correctly. Thank you! Can you please confirm whether it's possible to include this patch in 1.4.22?
By: Mark Michelson (mmichelson) 2008-08-29 10:08:54

1.4.22 is in release candidate status right now, so the only fixes that will make it into the official release are "critical" bug fixes (i.e. crashes or other blocking issues), so this will not be in the 1.4.22 release.

Since the latest patch is working properly, I am going to close this issue. Thanks for the testing!
By: Alistair Cunningham (acunningham) 2008-08-29 10:11:22

That's fine; I assume 1.4.23 will include it then?

Thank you for all your help on this!
By: Mark Michelson (mmichelson) 2008-08-29 10:12:18

Yes, 1.4.23 will definitely have the fix.
By: Alistair Cunningham (acunningham) 2008-08-29 10:13:11

Thank you!
By: Digium Subversion (svnbot) 2008-08-29 10:17:50

Repository: asterisk
Revision: 140417

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r140417 | mmichelson | 2008-08-29 10:17:49 -0500 (Fri, 29 Aug 2008) | 10 lines

Fix SIP's parsing so that if a port is specified
in a string to Dial(), it is not ignored.

(closes issue ASTERISK-12625)
Reported by: acunningham
Patches:
     13355v2.patch uploaded by putnopvut (license 60)
Tested by: acunningham


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=140417