[Home]

Summary:ASTERISK-23994: res_pjsip_sdp_rtp: owner address in SDP may not be fully qualified domainname
Reporter:Private Name (falves11)Labels:
Date Opened:2014-07-04 12:12:47Date Closed:2014-08-21 16:45:45
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_sdp_rtp
Versions:12.3.2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Linux any versionAttachments:
Description:I already asked this question to the list and nobody answered, therefore it is a bug. The SDP-Owner section is wrong. This is what my client said:

{quote}
"That OK message from 1.1.1.1 can not be parsed by our switch due to
address representation in their SDP:
Owner/Creator, Session Id (o): Pitcom 2723451647 2723451649 IN IP4 Pitcomlxc
Such address representation not supported, there should be IP address
instead of domain name.
Example:
{noformat}
Owner/Creator, Session Id (o): Pitcom 2723451647 2723451649 IN IP4 1.1.1.1
{noformat}

In fact, I traced it in the SDP packet, I see
{noformat}
o=Pitcom 3991413436 3 IN IP4 pitcomlxc
{noformat}

where pitcomlxc is the host name.
{quote}

How do I make PJSIP use an IP address there instead of the host name?
My /etc/hosts.com has an entry for pitcomlxc, but it makes no difference.
Comments:By: Matt Jordan (mjordan) 2014-07-04 14:11:22.519-0500

A few things before we get to the meat of this issue:

# Just because no one replies to you on a mailing list does not make your issue a bug. That's not quite how it works. Filing an issue here when you don't get a 24-hour response on the mailing list may force a response, but it's hardly likely to endear you to anyone in the project.
# Please don't file issues as blockers. Whether or not an issue is a blocker for a release is a decision made by the branch maintainers (plus, we'll just change it to Critical or something else). As it is, the fact that your provider doesn't like the SDP being generated from your machine does not make this a blocker.

Your provider is wrong. At the very minimum, a fully qualified domainname is allowable in the origin line of an SDP. From [RFC 4566, Section 5.2|http://tools.ietf.org/html/rfc4566.html#section-5.2]:

{quote}
5.2.  Origin ("o=")

     o=<username> <sess-id> <sess-version> <nettype> <addrtype>
       <unicast-address>

  The "o=" field gives the originator of the session (her username and
  the address of the user's host) plus a session identifier and version
  number:

<snip>

  <addrtype> is a text string giving the type of the address that
     follows.  Initially "IP4" and "IP6" are defined, but other values
     MAY be registered in the future (see Section 8).

  <unicast-address> is the address of the machine from which the
     session was created.  For an address type of IP4, this is either
     the fully qualified domain name of the machine or the dotted-
     decimal representation of the IP version 4 address of the machine.
     For an address type of IP6, this is either the fully qualified
     domain name of the machine or the compressed textual
     representation of the IP version 6 address of the machine.  For
     both IP4 and IP6, the fully qualified domain name is the form that
     SHOULD be given unless this is unavailable, in which case the
     globally unique address MAY be substituted.  A local IP address
     MUST NOT be used in any context where the SDP description might
     leave the scope in which the address is meaningful (for example, a
     local address MUST NOT be included in an application-level
     referral that might leave the scope).
{quote}

Now then, what is Asterisk doing?

Asterisk uses the hostname to set the origin address in the SDP:
{code}
local->origin.addr_type = session->endpoint->media.rtp.ipv6 ? STR_IP6 : STR_IP4;
local->origin.addr = *hostname;
{code}

Where hostname is retrieved from PJSIP:
{code}
hostname = pj_gethostname();
{code}

Generally, this will map to [gethostname|http://linux.die.net/man/2/gethostname] - so whatever it is returning is based on your system configuration.

In conclusion:
# Your provider is wrong. A fully qualified hostname is acceptable.
# If your machine is returning the wrong name, that would be a configuration error on your machine.
By: Matt Jordan (mjordan) 2014-07-04 14:24:17.862-0500

While your provider is still wrong, my conclusion was also a bit wrong :-)

Looking at what we sent in the origin line - and what {{gethostname}} will return - we may do two things incorrectly here:
# We may accidentally send a local address, which wouldn't be terribly useful
# We may not send the *fully qualified* name of the machine.

So there is a bug here: we should be sending the fully qualified name of the machine, or else the IP address. We should only send a local address if we have no other addresses.
By: Private Name (falves11) 2014-07-04 14:29:56.725-0500

a) This is not how the old chan_sip works
b) It will break interoperability with many SIP endpoints
c) This should be configurable by the user in pjsip.conf. In fact, this information should come only from the Transport which is associated with the outgoing endpoint.
d) Nobody has fully configured machine names that really map to an IP address. It just does not happens in the real world.
e) It is change so profound that is constitutes a bug.

Also, please understand how we do business. In a single machine, I have 50 independent Asterisk on top of each other, each one on an independent IP address. This scheme makes my design completely impossible. This field must not even look at the machine, only to the endpoint. I can show you a real machine with 50 Asterisks working perfectly well. As we say in Florida, "if ain't broke, don't fix it"

By: Matt Jordan (mjordan) 2014-07-04 14:48:27.715-0500

{quote}
a) This is not how the old chan_sip works
{quote}

Using {{chan_sip}} as a reason to do something is not a valid argument. {{chan_sip}} does many things; some are wrong. In this case, the RFC is clearly fine with sending a fully qualified domain name; whether or not {{chan_sip}} does such a thing is immaterial to the issue.

{quote}
b) It will break interoperability with many SIP endpoints
{quote}

It breaks interoperability with a broken provider. That is all we can conclude at this point.

{quote}
c) This should be configurable by the user in pjsip.conf. In fact, this information should come only from the Transport which is associated with the outgoing endpoint.
{quote}

Asterisk is open source. If you'd like to add such an option, feel free to provide a patch to this issue that does that.

The bug here, however, is not the lack of an IPv4 or IPv6 address.

{quote}
d) Nobody has fully configured machine names that really map to an IP address. It just does not happens in the real world.
{quote}

I think a fair number of people use DNS.

{quote}
e) It is change so profound that is constitutes a bug.
{quote}

It is not a change in the PJSIP stack's implementation in Asterisk. It is different from {{chan_sip}}.

Again, luckily for you, Asterisk is open source. If you'd like it to provide an IPv4 or IPv6 address only, a patch that made that option would be just fine. It should not be the default behaviour, as the RFC is more than happy with a FQDN. In fact, given aspects of DNS fail over, a FQDN would be preferable in many circumstances.

If you can't provide such a patch, you can of course wait for someone to provide one for you. As far as I'm concerned, fixing the issue I've described here is more than enough to fix this bug.

I won't argue this point further.
By: Private Name (falves11) 2014-07-04 14:59:02.895-0500

You are destroying the functionality provided by Asterisk since time immemorial, via -C /path/to/asterisk.conf, since now we can only have one single asterisk per box.
PJsip is wrong on this, and Asterisk was right using only the sip.conf bind address provided. Today, 99% of machines are multi-homed.
Please reconsider the issue. I am business man, not a developer, and my business has only one employee, why should I pay for a bug that affects the whole industry?

By: Olle Johansson (oej) 2014-07-22 07:15:58.262-0500

" I am business man, not a developer, and my business has only one employee, why should I pay for a bug that affects the whole industry?"

You have a lot of flaws in your logic here. You got a PBX software for free and built a business around it, running multiple asterisk servers. So why should you pay for fixing a missing feature? Well, that's how we make progress in the Open Source world. If a feature is missing that affects your business, you pay for fixing it. Other people pay for fixing other bugs and you get those fixes for free. We work together to lower the cost, but there will be cost at some point. Without other people paying you would not have Asterisk and propably would not be able to run your business.

I think it is time for you to reconsider and provide resources to fix this if it is important for you. Otherwise you will just have to wait until another company thinks this is annoying enough to pay for the fix.  That's how the Open Source industry works.

Welcome to contribute!