[Asterisk-Dev] help needed - SIP register response contact
Conroy, Lawrence (SMTP)
lwc at roke.co.uk
Mon Dec 1 10:37:40 MST 2003
Hi Michael, folks,
Below is a good summary of what the problem is and how one could fix
it long term. Michael highlights that this is a hack (as I admitted :),
in that it copies over the client's requested expires: parameter along
with their address, rather than having * strip out any client-supplied
parameter and then add it's own.
However, could folk please TEST this hack if they have Cisco or Snom or
Grandstream or Pingtel phones, please, and report back the results?
"hack to be tested" on channels/chan_sip.c, line 2257, replace with:
/* lwc add_header(resp, "Contact", contact); */ copy_header(resp,
Once I know that this works with these non-Mediatrix or Siemens stacks
we can go on from there.
all the best,
On 1 Dec 2003, at 3:59 pm, Michael Procter wrote:
>> From: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk]
>> Sent: 29 November 2003 13:16
>> Hi Folks,
>> suitably nudged, I would like to fix a latent bug that has been
>> hanging around in chan_sip for ages.
> [Creation of Contact header in 200 response to REGISTER]
>> I believe that this is WRONG - it certainly causes the mediatrix stack
>> (and Siemens phones) to ignore the register response, as they don't
>> think it's for them. They expect to see their OWN contact address in
>> the register response, not that of the proxy (or any other machine).
> I believe you are correct - that this is the wrong behaviour. I
> came up against this problem, and listed it as bug ID 510 on
>> As a quick hack, I replace the last line (2257) with the following:
>> /* lwc add_header(resp, "Contact", contact); */ copy_header(resp,
> Whilst this is more correct, in the sense that the Contact header now
> the correct bound address, there are still problems. Firstly, this
> appears to copy throught the 'expires' parameter from the REGISTER
> Whilst the UA may provide a suggested 'expires', the registrar should
> final value. If Asterisk wishes to use a different value, this change
> prevent that (expires value in Contact header takes precedence over
> value in
> Expires header).
> Secondly, I think it still misses one of the main points of performing
> Suppose I send a REGISTER containing 'To:
> sip:me at asterisk.example.com', and
> 'Contact: sip:myphone at mydesk.example.com'. Any call to
> me at asterisk.example.com through Asterisk should arrive at
> myphone at mydesk (no argument there, I think), but with the Request-URI
> rewritten to be 'sip:myphone at mydesk.example.com', i.e. the value I
> specified in the Contact of the REGISTER message. [RFC3261 Sec
> specifically the rewriting of the Request-URI that P2 performs].
> So, by not caching the true Contact details, I'm not sure how future
> routed via Asterisk can be received by a SIP phone. Just stashing the
> address/port information is a start, but a Request-URI can contain
> parameters as well. [RFC3261 Table 1 in section 19.1.2].
>> The real issue is line 2254, where p->our_contact is used. Nope, it
>> should be THEIR contact address (as in the req Contact header).
> Exactly. And Asterisk should cache the contact address (parameters and
> all) to use in the Request-URI of future calls.
>> Some phones don't check the Contact header address in the register
>> response, so the current
>> stuff doesn't break them. This is why it has worked for most folk -
>> their phones aren't strictly compliant. However...
> I thought this was true, when I found out that my Cisco 7960 can
> with Asterisk. But I did a few more tests. If the 7960 can't find
> Contact-URI in the response to the register, it defaults the expiry
> to be the value specified in the Expires: header. Since Asterisk sends
> an Expires: header correctly, the 7960 is happy, even though the
> header is incorrect.
>> I don't have any Cisco phones (or pingtel, grandstream, Snom ones)
>> available, so could
>> someone put in my proposed hack to check whether it breaks their
> I would suggest that at a minimum, you ensure you don't copy any
> parameter from the Contact in the REGISTER. Ideally, I think the
> URI should be cached, but that may be a larger change than you were
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
More information about the asterisk-dev