Summary:	ASTERISK-00506: Asterisk generates incorrect 200 response to REGISTER
Reporter:	mhp (mhp)	Labels:
Date Opened:	2003-11-10 09:18:32.000-0600	Date Closed:	2011-06-07 14:10:26
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
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. ****** ADDITIONAL INFORMATION ****** 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@192.168.5.12'.  That Address-of record should have 'sip:5112@192.168.5.15:5061' (from the contact header) associated with it. In the 200 response, I would expect to see the contact contain the address 'sip:5112@192.168.5.15:5061', not the original Address-of record. For further examples of registration, you could examine: http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-02.txt 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.