SOLVED Problem with the Port # in a SIP Call-Id string

I’ve noticed recently, that SIP device, working with Asterisk refuses to accept the port part in Call-ID string, sent by Asterisk.

The exact message in device’s debug is:
1364485027:690000 SIP protocol: ERROR - PARSER - SIP Parser Error : Unexpected ‘:’, line 7, column 57
This is in response to:
1364485027:660000 SIP protocol: INFO - TRANSPOR - Call-ID: 5f28bea762f6e1382339acc80b09c4eb@

Is it the receiving device to blame, or the port number can be stripped from the Call-ID string somehow?

Thanks in advance

[quote]Call-ID = ( “Call-ID” / “i” ) HCOLON callid
callid = word [ “@” word ]
word = 1*(alphanum / “-” / “.” / “!” / “%” / “*” /
"_" / “+” / “`” / “’” / “~” /
"(" / “)” / “<” / “>” /
[color=#FF0000]":" [/color]/ “” / DQUOTE /
"/" / “[” / “]” / “?” /
"{" / “}” )[/quote]

The receiving device is to blame. However, you could check to see if you are explicitly setting the default port number value, and if so, simply letting it default.

Note there are no semantics in call-ids, except as an opaque, unique, reference. The use of the host name is a strategy to ensure uniqueness, but any other strategy for doing that woudl be acceptable.

Big thnaks for the quick reply.

I also think, that the device is to blame, but it used to work against Asterisk (maybe an older version) without this error.

What is more probable:

  • some configuration change caused Asterisk to add the port number to the Call-ID string
  • newer Asterisk version has changed SIP protocol

Thanks again.

I don’t doubt there has been a change, but at worst it should have no impact, and at best it avoids call-id clashes if there are two instances of Asterisk, or Asterisk and a smart phone on the same machine, but on different port numbers.

It might be an unintentional side effect of a bug fix elsewhere. It is not, in itself, a bug.

Finding the exact reason is a lot of work, for a non-bug, but basically, you would find the bit of code that is now adding the : and do an “svn blame”, to find which revision introduced it, then look at the revision comment to try to find out why it was done.

As noted above, the SIP protocol says nothing about the meaning of the “word” after the “@”, but has always allowed it to contain a “:”.

Any chance for not adding the port to the SIP Call-ID string, using sip.conf or other external configuration file?

It is possible that it is only generated if you set an explicit port number. If you have already eliminated that possibility, I can see no reason why there should be a configuration option.

From the code, it looks like it may use an explicit fromdomain, in preference to this.

Maybe you refer to:
const char *host = S_OR(pvt->fromdomain, ast_sockaddr_stringify_remote(&pvt->ourip));

I’ve just tested this.
Unfortunaltely fromdomain= has no effect and there still stays :5060 at the end of the Call-ID string :frowning:

Hmm, putting fromhost in [global] seems to solve the problem.
Will test later.

putting fromdomain in a [global] section of sip.conf solved the problem.
Big thanks!