|Summary:||ASTERISK-00506: Asterisk generates incorrect 200 response to REGISTER|
|Date Opened:||2003-11-10 09:18:32.000-0600||Date Closed:||2011-06-07 14:10:26|
|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:firstname.lastname@example.org'. That Address-of record should have 'sip:email@example.com:5061' (from the contact header) associated with it.
In the 200 response, I would expect to see the contact contain the address 'sip:firstname.lastname@example.org:5061', 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.