Problems parsing Contact

When trying to connect a Panasonic TDE to an asterisk box I am getting a warning in the CLI saying “register_verify: Failed to parse contact info” I only get this with Asterisk version 1.6.2.18 or 1.8.3.3, I ran a packet capture during a failure and got the following.

U 192.168.0.101:5060 -> 192.168.0.6:5060
REGISTER sip:192.168.0.6:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK00005d3e;rport.
Max-Forwards: 70.
To: sip:PANATDE@192.168.0.6.
From: sip:PANATDE@192.168.0.6;tag=10170.
Call-ID: 00003e1e-1f2a63de36f7100084560080f03e61c8@192.168.0.101.
CSeq: 2 REGISTER.
Contact: *.
Expires: 0.
Authorization: Digest realm=“realm”, nonce=“6lk23jd5”, algorithm=MD5, uri=“sip:192.168.0.6:5060”, username=“PANATDE”, response=“5fdsfwefww7632r2fff2acfb5d23c142”.
Allow: INVITE,ACK,CANCEL,BYE,PRACK,OPTIONS,REGISTER,INFO,UPDATE.
User-Agent: Panasonic-MPR07-VSIPGW/V3.0007.
Content-Length: 0.
.

U 192.168.0.6:5060 -> 192.168.0.101:5060
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK00005d3e;received=192.168.0.101;rport=5060.
From: sip:PANATDE@192.168.0.6;tag=10170.
To: sip:PANATDE@192.168.0.6;tag=as72f18011.
Call-ID: 00003e1e-1f2a63de36f7100084560080f03e61c8@192.168.0.101.
CSeq: 2 REGISTER.
Server: Asterisk PBX 1.6.2.18.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces, timer.
Date: Mon, 09 May 2011 08:28:19 GMT.
Content-Length: 0.
.

The same config with asterisk 1.6.1.25 works fine. Any suggestions?

The fault lies on the other side.

If it is a problem with the other side then I am surprised it works on older versions of asterisk.

Also, judging by the CLI warning it is an issue with the Contact header, but we have numerous Panasonic systems connecting to a variety of SIP registrars with that contact header (which is a valid one according to the SIP rfc).

As presented, all your header lines end in “.”. That is not permitted by the syntax.

Older versions may not parse as rigorously.

I can’t find out what “*” means in the Contact header, although it is allowed by the syntax. My guess is it is the same as not having Contact at all. It may be that Asterisk doesn’t understand this.

  • in Contact means I’m unregistering myself, no?

I wondered that, after I wrote the reply, but I still cant find anything in RFC 3261 that explains that.

It’s section 10.2.2 in the RFC where it is defined.

Oh and I think the “.” is being added by the packet capture software. The box is up and running with asterisk 1.6.1.25 and all packets have the “.” at the end.

bump

this completely breaks support for older Grandstream ATA. :frowning:
After upgrading Asterisk from 1.6.2.14 to 1.6.2.17.3, every Grandstream ATA286 and BT100 Phones stops working.

Is there a way i can change the behaviour back?

You first need to understand what has broken, and whether it is asterisk being more correct or asterisk being wrong. Once you have found out what is broken, you can probably find the specific SVN revision that broke it and apply that in reverse.

If you can demonstrate a problem in version 1.8, you may be able to get it fixed in that, using the bug tracker, and then back port that patch.

You will be lucky to find anyone to debug it to that level for free, unles they are personally affected.

Hi,

I know exactliy what is broken. I just dont know, how i can fix it :smile:

I’ve done some debuging after upgrading to Asterisk 1.6.2.17.3.
You can find a sip-debug output here: privy.de/~kts/asterisk-debug/asterisk-debug.txt

It seems, that my Phone is sending the Header “Contact: *” which asterisk does not like.
The parts in the code, that is responsible for the check is in chan_sip.c…

A diff betweeen the both version is here: privy.de/~kts/asterisk-debug/ast … g-diff.txt
The responsible part from the diff is here: privy.de/~kts/asterisk-debug/ast … -diff2.txt

I have absolutly no clue about the SIP-Protocol but it seems, that this wildcard is something special?

Does anybody has an idea?

best regards,
Karl

grr, found that bug!

diff:

-       int single_binding_found;
+       int single_binding_found = 0;

…solves my problem :smile:

The bug is still present in 1.6.2.18 but not in 1.8.4!

best regards,
Karl

If it works in the latest 1.8 version, nothing will be done to fix it in other versions. However, for future information, for absolute copyright safety in commercial versions of Asterisk, Digium don’t look at patches unless they are attached to a report on issues.asterisk.org/ by someone who has electronically signed the licence grant on that site.

So, it’s not fixed in 1.6.2.19 ?
If not, can this be fixed, for example, by Grandstream software upgrade?