Summary:ASTERISK-13441: [patch] The contact exten field in the sip.conf register string is not parsed
Reporter:nick_lewis (nick_lewis)Labels:
Date Opened:2009-01-23 07:58:40.000-0600Date Closed:2009-05-12 19:47:09
Versions:Frequency of
Environment:Attachments:( 0) chan_sip.c-callback.patch
Description:The contact exten field for all registrations is set to "s" irrespective of the value of the contact exten parameter in the register string.

This problem was first mentioned in note 97149 of issue 14185. I think that the patches that address the primary problem with expiry in issue 14185 also address this contact exten issue. However if a separate patch is needed for this alone then I can make one.
Comments:By: Olle Johansson (oej) 2009-01-23 08:11:43.000-0600

Please give an example of a register= string where exten isn't matched, thank you. (Please read the bug guidelines).

By: nick_lewis (nick_lewis) 2009-01-23 08:56:58.000-0600

Sorry, it is whenever there is a host port e.g.


By: Olle Johansson (oej) 2009-01-23 09:04:30.000-0600

Ok, that is a bad and needs to be fixed.

We need to go through all the changes done to the register= lately and revert some, since we don't want to overload that line. All extra configurations should be done in a peer section referred to by the register= line. It has to be a very basic trigger for registrations and not a complete peer section replacement...

By: nick_lewis (nick_lewis) 2009-01-23 09:17:47.000-0600

Do you want a specific patch for this or are you happy to take it with issue 14185?

Re "All extra configurations should be done in a peer section referred to by the register= line" - I strongly agree!

The register line should be no more than the peername and the expiry. In fact the register line could be supported in the [peername] section as well as the [general] section and in this case would have only the expiry e.g.


By: Olle Johansson (oej) 2009-01-23 10:29:17.000-0600

Nick, please read sip.conf.sample carefully :-)

By: nick_lewis (nick_lewis) 2009-01-26 03:21:11.000-0600

Ooops sorry - so the peer definitions already support registration using the callbackextension parameter. The world is a wonderful place and I didn't know it

The ~expiry parameter does not currently seem to be supported in the peer definitions though. The expiry parameter is important when operating behind nat so as to keep alive the nat binding

Anyway back to this register string issue I am happy to produce a patch that just moves parsing of the reg->callback parameter before the call to sip_parse_host()

By: Olle Johansson (oej) 2009-01-26 03:30:17.000-0600

Yes, we need to implement the expiry string in the peer definition - it makes more sense there than in the register= line since it's an advanced setting. Maybe change register=yes/no and add a third choice which is a timer.

I'll take a look at any patch. If you want to discuss, I'm on the IRC channel and also reachable over XMPP with my e-mail address.

By: nick_lewis (nick_lewis) 2009-01-26 05:04:01.000-0600

Please find attached a patch that parses the reg->callback parameter before the call to sip_parse_host(). It also removes some presumably historic code for the host port that is in fact handled by the sip_parse_host() function

Please note that this patch performs part of changes included in the patch for issue 14185 so the latter patch will not successfully apply after this patch. If you are happy to apply fixes for both issue 14321 and issue 14185 then please use the patch in 14321

By: nick_lewis (nick_lewis) 2009-01-26 05:11:36.000-0600

Correction: "then please use the patch in 14321" should read "then please use the patch in 14185"

By: Olle Johansson (oej) 2009-01-26 06:00:20.000-0600

I guess it was not only me that got a bit confused :-)

By: Olle Johansson (oej) 2009-01-26 06:12:19.000-0600

Nick, you need to upload a unified diff, not the complete source code. THanks.

By: nick_lewis (nick_lewis) 2009-01-26 06:26:32.000-0600

I have uploaded the actual patch this time I hope

By: Olle Johansson (oej) 2009-01-26 06:29:58.000-0600

You've reported this for 1.6.1, but did you check 1.6.0 - does the problem exist there as well or not?

By: nick_lewis (nick_lewis) 2009-01-26 07:55:50.000-0600

Looking at 1.6.0 the problem appears to affect it too

By: Leif Madsen (lmadsen) 2009-01-28 07:01:18.000-0600

Just a note that I saw from 14185:

14185 should be applied first, otherwise 14185 will not apply cleanly if this bug is committed prior.

By: nick_lewis (nick_lewis) 2009-01-28 07:10:30.000-0600

Sorry to cause more confusion

If 14185 is applied first then it should not be necessary to apply this patch since 14185 is a superset of 14321.

The reason I raised this issue separately was because there was some uncertainty whether 14185 would be applied

By: Leif Madsen (lmadsen) 2009-05-12 19:47:08

Based on Nick's comments, this issue can be closed because issue 14185 was closed prior to this one.