Hi,
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@192.168.60.100:5060
Is it the receiving device to blame, or the port number can be stripped from the Call-ID string somehow?
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.
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 “:”.
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.
