Summary:ASTERISK-00506: Asterisk generates incorrect 200 response to REGISTER
Reporter:mhp (mhp)Labels:
Date Opened:2003-11-10 09:18:32.000-0600Date Closed:2011-06-07 14:10:26
Versions:Frequency of
Environment:Attachments:( 0) asterisk3.eth
Description:When a UA registers with Asterisk, the 200 response sent to the UA contains an incorrect Contact: header.  The Contact header should contain a list of bound URIs, not the address-of record that is being bound.


RFC 3261, Section 10.3, bulletpoint 8 describes what should be in the 200 OK response.
Comments:By: Mark Spencer (markster) 2003-11-10 10:58:31.000-0600

Can you provide any sort of example of what we send and what we should send?

By: mhp (mhp) 2003-11-10 11:10:27.000-0600

The attached file (asterisk3.eth) is an Ethereal trace of a registration.  I've only supplied the three interesting packets (REGISTER, 100, 200).  In the Register, you can see that I am trying to create a binding for 'sip:5112@'.  That Address-of record should have 'sip:5112@' (from the contact header) associated with it.

In the 200 response, I would expect to see the contact contain the address 'sip:5112@', not the original Address-of record.

For further examples of registration, you could examine:

Hope this helps.

By: Brian West (bkw918) 2004-01-26 23:11:41.000-0600

Can you confirm that this is still a problem?

By: Olle Johansson (oej) 2004-01-27 13:15:24.000-0600

In chan_sip2.c (see bug 0000759 ) I'm experimenting with saving the contact: and using it for subsequent INVITES, which is the correct way of doing it. I haven't checked what Asterisk return to a 200 OK for a REGISTER Contact: header. I think that according to the RFC we should reply with all registred contacts for that user, but since we only allow one per SIP account, that is not a problem today. Can't find any text in the RFC 3261 indicating that we can't parse the contact header and compose a new, but I know this leads to problems later on, in INVITEs.

However, Asterisk rewrites Contact: headers, which breaks SNOM phones and some middleman NAT-boxes. (See bug 0000732 ). I wasn't aware that this also was a problem in the reply to a register. This report doesn't indicate that it in fact is a problem, only that Asterisk is incorrect. I'll go experiment. Would be interesting to know if any UA chokes on this behaviour.

By: Olle Johansson (oej) 2004-03-23 12:02:38.000-0600

This is the same problem as 777, discussion moved to that bug". Stay tuned.