[Home]

Summary:ASTERISK-12663: Transport type not correctly displayed in "sip show peer" output
Reporter:John Todd (jtodd)Labels:
Date Opened:2008-08-29 14:59:12Date Closed:2008-11-07 15:40:56.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a SIP peer which is connecting with * using TCP.  I have verified both with netstat as well as with tshark that the peer is connected with TCP.  However, "sip show peer blah" always shows Transport: as UDP.  The SIP object is set with "transport=udp,tcp" in the config file.  The expected behavior would be that Transport: shows the current transport method that the SIP entity is using for the registration.  If it was the desire to have "Transport:" indicate the setting in the config file, then I would suggest another name for that field (possibly "Transport-Ord." or something like that?) and the options be printed in that new field.
Comments:By: Mark Michelson (mmichelson) 2008-09-09 04:59:02

After looking at the code for a while, I think I know what's up here. Basically what the output is showing is the "preferred" transport method as indicated in sip.conf. In other words, it will always display the first transport type configured for that peer.

The tricky part of what you propose deals with the following "...shows the current transport method that the SIP entity is using for the registration." The problem with this is that as far as I can tell, the transport method used can vary between calls. For instance, if your peer is configured with transport=udp,tcp as you have here, I would expect Asterisk to make outbound calls to this peer using UDP instead of TCP (unless there is an overriding factor like explicitly placing the TCP transport in the Dial string).

If I'm correct in the above paragraph, then I think a good compromise would be to list all the transport types configured for the peer instead of just the first.

By: Tilghman Lesher (tilghman) 2008-11-07 15:40:55.000-0600

Fixed in revision 148473.