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-0600	Date Closed:	2009-05-12 19:47:09
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
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. register=me@sip.myitsp.com:1234/trunk1 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. [peername] register=600 host=sip.myitsp.com username=myaccount secret=mypassword 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.