but this also means the template was modified by the user or the defaults
were changed somehow, because they default to 5060, which does work. So
this issue is if "it is set to 0" it does not behave as expected.

While I agree "ideally" it would do a DNS lookup if set to port 5060, but
would also need to "send" port 5060 if the DNS sends this back. In as much
as I want to think this is a sipx thing, we'd really need to understand the
logic and whether that is specifically supported by Aastra to perform this
function. Why I say Aastra (dont take it as a bad thing to say) is because
RIGHT NOW the hostname does not get set in the proxy or registrar fields
for the line, just the sip domain. For subscriptions and registrations it
sends/auths successfully as "user@sipdomain:port".

So that is two things: will it send port 5060 if doing a DNS lookup and
assumes if it finds port 5060, does it use this. That I think is a UA
question. When it does that, does it also use the sipdomain or the hostname?

Ideally the lookup function would only be relevant to the port number and
not change the proxy/registrar to hostname (IMO).

What is the use case to change the port from 5060 to "0" though?



On Tue, Aug 7, 2012 at 8:04 AM, Michael Picher <[email protected]> wrote:

> The problem is specifically with Aastra phones that if port is set to 0
> then it will use SRV, is port is set it will use A-Record resolution.  The
> phone config template is putting in 5060 and this should be user definable
> and should default to 0.
>
> Mike
>
> On Tue, Aug 7, 2012 at 7:22 AM, Tony Graziano <
> [email protected]> wrote:
>
>>
>>
>> On Tue, Aug 7, 2012 at 7:13 AM, Mark Dutton <[email protected]>wrote:
>>
>>>
>>>
>>> I did say exactly what I did to make it work in an earlier
>>> post. The problem was that the SipX provisioning software
>>> was not carrying the port = 0 variable in the device group
>>> server settings for registrar and proxy. Even though the
>>> device group profile has 0, the device profile still puts in
>>> 5060 as a default. You have to go to each device
>>> individually and override the setting with 0. This then
>>> causes the handset to use the default port of 5060, but not
>>> to specify it in the URI. This then made the MWI server
>>> happy to auth it.
>>>
>>
>> In normal instances, sipxecs tries to be "SRV aware". Using port "0"
>> means to look up the information (automatic) and DNS will find the correct
>> port and transport.
>>
>> " You have to go to each device individually and override the setting
>> with 0. " Is this the case on 4.4 or 4.6 or both?
>>
>> I would help if you supplied the value for whatever versions that you had
>> to manually change in the handset:
>>
>> i.e. sip line1 proxy port: 0 to sip line1 proxy port: 5060
>>
>> to get it to work.
>>
>> Because on my systems (4.4 and 4.6), it says this in the line settings.
>>
>>
>> (i.e Phone, Line, Server Settings)
>>
>> sip line1 registrar port: 5060
>> sip line1 proxy port: 5060
>>
>> So I do not know what is different on yours. On mine my DNS records are
>> fully populated, but both generated configs say "5060" by default,
>> specifically, but I don't have an Aastra to test with. The only thing that
>> has "0" in it is the outbound proxy port. I am trying to understand why
>> yours defaults to "0" and mine does not. For what it is worth, the
>> timezones are not fully populated to be of good enough production use for
>> certain parts of the world either so it needs a maintainer.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> And I can tell you with all certainty that Zultys does not
>>> use a special firmware. I have been a Zultys beta tester for
>>> 5 years working with the dev guys. Aastra has a provisioning
>>> system where it goes to the Internet on first boot (after
>>> factory default) and looks up the mac address a database
>>> maintained by Aastra. Aastra then sends back certain
>>> identity information, such as the correct splash screen
>>> bitmap and agent string, etc.
>>>
>>> The actual firmware is direct from Aastra and is unmodified
>>> (in the Zultys case).
>>>
>>> What got my back up was that in my first post I asked what
>>> information to gather to send to the SipX forum and instead
>>> I was told to send a SIP log to Aastra. Believe me they
>>> would have absolutely no interest in even replying.
>>>
>>
>> I never suggested that. I did suggest a siptrace from sipx so the call
>> flow could be seen using sipviewer.
>>
>>>
>>> I am new to SipX, but not to IP tel. I am not sure which
>>> logs give me what sort of information (apart from
>>> sipXproxy.log). I have been using sipx-trace and sipviewer
>>> (when necessary) to do my investigations to date. Where I
>>> came unstuck with this was that I did not know why I was
>>> getting an auth error.
>>>
>>> As it turned out, it was because the phone was subscribing
>>> with the port in the URI. From Joegen's post (the RFC
>>> excerpt), I could see that the port designator is a key part
>>> of a URI match and this is what SipX didn't like. However,
>>> if SipX was being strict, it should not have allowed the
>>> REGISTER, or INVITE methods either as these too were
>>> appending the port to the URI.
>>>
>>> One has to be pragmatic with SIP. There are so many
>>> "viewpoints" on what is legal. When it comes to Aastra, a
>>> large, isolationist company, or SipX, an open community, it
>>> is going to be the latter that is more likely to accomodate
>>> change than the former. Just the way of the world.
>>> --
>>> Regards
>>>
>>> Mark Dutton
>>>
>>> _______________________________________________
>>> sipx-users mailing list
>>> [email protected]
>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~
>> Tony Graziano, Manager
>> Telephone: 434.984.8430
>> sip: [email protected]
>> Fax: 434.465.6833
>> ~~~~~~~~~~~~~~~~~~
>> Linked-In Profile:
>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
>> Ask about our Internet Fax services!
>> ~~~~~~~~~~~~~~~~~~
>>
>> Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
>> 2013!
>> <http://sipxcolab2013.eventbrite.com/?discount=tony2013>
>>
>>
>> LAN/Telephony/Security and Control Systems Helpdesk:
>> Telephone: 434.984.8426
>> sip: [email protected].**net<[email protected]>
>>
>> Helpdesk Customers: 
>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
>> Blog: http://blog.myitdepartment.net
>>
>> _______________________________________________
>> sipx-users mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>
>
>
> --
> Michael Picher, Director of Technical Services
> eZuce, Inc.
>
> 300 Brickstone Square****
>
> Suite 201****
>
> Andover, MA. 01810
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
> www.ezuce.com
>
>
> ------------------------------------------------------------------------------------------------------------
> There are 10 kinds of people in the world, those who understand binary and
> those who don't.
>
>
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



-- 
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

-- 
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected]

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to