[Home]

Summary:ASTERISK-06201: REGISTER without Contact: and Expires: fails
Reporter:op (op)Labels:
Date Opened:2006-01-26 07:51:21.000-0600Date Closed:2006-01-27 01:09:13.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch
Description:If a SIP client (in this case an AVM FRITZ!Box Fon 7170) sends a REGISTER that contains neither a Contact: nor an Expires: header, Asterisk replies "100 Trying" and discards the registration. The following error message appears:

Jan 26 14:35:08 WARNING[16484]: chan_sip.c:6421 register_verify: Failed to parse contact info

Please note that the line number might be inaccurate as this Asterisk system contains the BRIstuff patches.

My quick and dirty workaround shown below (break commented out) causes Asterisk to treat PARSE_REGISTER_FAILED just like PARSE_REGISTER_QUERY. I'm not familiar enough with the SIP code for a real fix, so a decent one would be appreciated.

                       transmit_response(p, "100 Trying", req);
                       if (!(res = check_auth(p, req, p->randdata, sizeof(p->ra
nddata), peer->name, peer->secret, peer->md5secret, SIP_REGISTER, uri, 0, ignore
))) {
                               sip_cancel_destroy(p);
                               switch (parse_register_contact(p, peer, req)) {
                               case PARSE_REGISTER_FAILED:
                                       ast_log(LOG_WARNING, "Failed to parse co
ntact info\n");
                                       // break;
                               case PARSE_REGISTER_QUERY:

This is what the REGISTER request looks like:

REGISTER sip:host.name.removed SIP/2.0
Via: SIP/2.0/UDP XX.XX.XX.XX:5060;branch=z9hG4bKA9DBF7696F913FD65FB4B0B40ED8F
From: <sip:XXXX@host.name.removed>;tag=3519631095
To: <sip:XXXX@host.name.removed>
Call-ID: 369C9E975DF8C1235E37700D80462@192.168.178.1
CSeq: 2 REGISTER
Authorization: Digest username="XXXX" [...removed...]
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.03.99 (Jan 18 2006)
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
Comments:By: Olle Johansson (oej) 2006-01-26 08:07:58.000-0600

Just a quick note for reference: RFC 3261

10.2.3 Fetching Bindings
A success response to any REGISTER request contains the complete list of existing bindings, regardless of
whether the request contained a Contact header field. If no Contact header field is present in a REGISTER
request, the list of bindings is left unchanged.
By: Olle Johansson (oej) 2006-01-26 08:08:41.000-0600

Do you know why it sends such a packet?
By: Olle Johansson (oej) 2006-01-26 08:11:33.000-0600

I need to see a full SIP debug of this transaction, from the first registration to the answer of this packet. Set debug to 4, verbose to 4 and enable sip debugging. Capture that and add as an attachment to this bug report, thank you.
By: Olle Johansson (oej) 2006-01-26 08:25:21.000-0600

Reading the source, I think we support this IF we have an active registration. It is unclear what response we should send if we do not have an active registration, guessing a 200 OK without any contact headers at all.
By: op (op) 2006-01-26 08:34:37.000-0600

Excellent question, the previous model (7050) supplies a Contact: header and works fine with Asterisk.
By: Olle Johansson (oej) 2006-01-26 08:38:37.000-0600

Just to explain: This package is not a registration request, it's a query.
By: op (op) 2006-01-26 09:02:41.000-0600

All subsequent packets contain a valid Contact: header, so returning a 200 OK in this case eliminates the problem while returning 100 Trying caused the device to give up without ever retrying to obtain a registration.

According to the RFC 3261 snippet, there should be nothing wrong with sending a 200, so I think it should be implemented that way. What do you think?
By: Olle Johansson (oej) 2006-01-26 11:47:37.000-0600

Well, a query with an empty answer is much better than no answer at all...
By: Olle Johansson (oej) 2006-01-26 11:53:05.000-0600

Op, please try this patch and see if it returns a proper answer.
By: op (op) 2006-01-26 12:54:28.000-0600

Looks like a clean version of my workaround and works perfectly. I just had the user reboot his box, and the following handshake occurred:

Client: REGISTER (without Contact:)
Server: 100, 401
Client: REGISTER (without Contact:, with authentication information)
Server: 100, 200
Client: REGISTER (with Contact:)
Server: 100, 200

...and a SUBSCRIBE without any problems, so this issue should be solved.

Thanks for your help!


By: Olle Johansson (oej) 2006-01-26 14:42:52.000-0600

If possible, I would like to see a SIP debug of those transactions, just to be sure. Thanks for a quick reply!
By: op (op) 2006-01-26 15:06:06.000-0600

Here we go:

REGISTER sip:host.name SIP/2.0
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bKBA7496004A4A74C4C208C027061C4
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.03.99 (Jan 18 2006)
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

SIP/2.0 100 Trying
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bKBA7496004A4A74C4C208C027061C4;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 1 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:XXXX@X.X.X.X>
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bKBA7496004A4A74C4C208C027061C4;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>;tag=as08544891
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 1 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:XXXX@X.X.X.X>
WWW-Authenticate: Digest realm="host.name", nonce="3566d6e6"
Content-Length: 0

REGISTER sip:host.name SIP/2.0
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK89DDD47A5A7CDB33EDCE216E396E3
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 2 REGISTER
Authorization: Digest username=[...]
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.03.99 (Jan 18 2006)
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

SIP/2.0 100 Trying
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK89DDD47A5A7CDB33EDCE216E396E3;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 2 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:XXXX@X.X.X.X>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK89DDD47A5A7CDB33EDCE216E396E3;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>;tag=as08544891
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 2 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 1672
Contact: <sip:XXXX@X.X.X.X>;expires=1672
Date: Thu, 26 Jan 2006 19:29:35 GMT
Content-Length: 0

REGISTER sip:host.name SIP/2.0
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bK34D32EDE0FBEC6DC11D10F75A228D
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 3 REGISTER
Contact: <sip:XXXX@X.X.X.X;uniq=AFBE27EB13BF5462708B7948F6A8D>
Authorization: Digest username=[...]
Expires: 1800
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.03.99 (Jan 18 2006)
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

SIP/2.0 100 Trying
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bK34D32EDE0FBEC6DC11D10F75A228D;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 3 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:XXXX@X.X.X.X>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/udp X.X.X.X:5060;branch=z9hG4bK34D32EDE0FBEC6DC11D10F75A228D;received=X.X.X.X
From: <sip:XXXX@host.name>;tag=1309735931
To: <sip:XXXX@host.name>;tag=as08544891
Call-ID: FF372BBD690C9DBF049CFE5D0C6A6@192.168.178.1
CSeq: 3 REGISTER
User-Agent:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 1800
Contact: <sip:XXXX@X.X.X.X;uniq=AFBE27EB13BF5462708B7948F6A8D>;expires=1800
Date: Thu, 26 Jan 2006 19:29:35 GMT
Content-Length: 0
By: Olle Johansson (oej) 2006-01-27 01:08:37.000-0600

Fixed in rev 8785 of 1.2 and 8786 of trunk. Thank you for reporting this!