MWI and Aastra

Discussion:

MWI and Aastra

Mark Dutton

2012-08-06 15:59:20 UTC

Hi All

I posted a message regarding MWI for 4.6 and Aastra
handsets.

However, I have installed 4.4 and I have the same problem.
My Polycom phones have MWI, but my Aastra phones do not.
I am getting a 401 unauthorised from the MWI server.
The phones are registered and can call OK. When they
subscribe they do send auth, but I am not sure how to tell
why the MWI is not happy with their auth parameters.
I am happy to post any relevant info, SIP traces, etc. I
would like to get this going as I do have to support Aastra
handsets.

--
Regards

Mark Dutton

Michael Picher

2012-08-06 16:05:07 UTC

Permalink

I'd grab a trace and contact Aastra...

Post by Mark Dutton
Hi All
I posted a message regarding MWI for 4.6 and Aastra
handsets.
However, I have installed 4.4 and I have the same problem.
My Polycom phones have MWI, but my Aastra phones do not.
I am getting a 401 unauthorised from the MWI server.
The phones are registered and can call OK. When they
subscribe they do send auth, but I am not sure how to tell
why the MWI is not happy with their auth parameters.
I am happy to post any relevant info, SIP traces, etc. I
would like to get this going as I do have to support Aastra
handsets.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
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.

Mark Dutton

2012-08-06 23:49:49 UTC

Permalink

Michael that is not very helpful.

Aastra are going to say "contact your software developer".

I have used Aastra handsets on Asterisk open source as well
as Zultys and Epygi commercial PBXs with perfect results.
The problem is not with Aastra.

--
Regards

Mark Dutton

George Niculae

2012-08-06 23:48:12 UTC

Permalink

Others had discussions with Aastra, this could help:
http://forum.sipfoundry.org/index.php?t=msg&goto=57147&S=d8290c231c2cf6cb0f1dd7e0f521c2b2

Maybe Henry D could update if MWI was discussed

George

Josh Patten

2012-08-07 00:01:34 UTC

Permalink

If Polycom, Snom, and others work with MWI then if Aastra is following RFC
spec then theirs should to.

The only way you would know is to get a trace of both a Polycom and an
Aastra SUBSCRIBEing to the server and see what the differences are in the
signalling. Going line by line through the SIP stuff is the only way to
figure out where the issue lies.

Post by Mark Dutton
Michael that is not very helpful.
Aastra are going to say "contact your software developer".
I have used Aastra handsets on Asterisk open source as well
as Zultys and Epygi commercial PBXs with perfect results.
The problem is not with Aastra.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Mark Dutton

2012-08-07 00:26:19 UTC

Permalink

I have done this. They are identical except for the auth
line. I don't know enough about auth to know if the
differences are significant.

In any case, the SIP lines simply show that there is a
request and a 401 response. This is all good. What I would
like to know is whether this is another useful log from the
MWI server that will be more useful that repoorts the REASON
for the 401 auth error.

Just because Snom and Polycom work doesn't make the fault
lie with Aastra. I have worked on Aastra, Snom and Polycom
phones for years. They all have their quirks and
interpretations of various RFCs.

If this is the response I am to get with a simple,
reasonable request, I guess I am wasting my time. I will
look at another Open distribution.

Thanks guys.

--
Regards

Mark Dutton

Tony Graziano

2012-08-07 00:25:59 UTC

Permalink

The authorization is handles by the proxy server.

It has been suggested that you provide this information. Do wiki has
instructions on submitting a sip trace which would probably help your cause
tremendously.

Providing a couple of lines out of been almost irrelevant log file really
does nothing to further your cause.

Placing both the sip proxy and the registrar to debug mode well rebooting
the phone then creating the trace file would go a long way.

Since you have an unwillingness to provide this, you're the 1 who has
painted yourself into this corner is that you find yourself in.

~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
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!

Post by Mark Dutton
I have done this. They are identical except for the auth
line. I don't know enough about auth to know if the
differences are significant.
In any case, the SIP lines simply show that there is a
request and a 401 response. This is all good. What I would
like to know is whether this is another useful log from the
MWI server that will be more useful that repoorts the REASON
for the 401 auth error.
Just because Snom and Polycom work doesn't make the fault
lie with Aastra. I have worked on Aastra, Snom and Polycom
phones for years. They all have their quirks and
interpretations of various RFCs.
If this is the response I am to get with a simple,
reasonable request, I guess I am wasting my time. I will
look at another Open distribution.
Thanks guys.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net

Mark Dutton

2012-08-07 00:52:01 UTC

Permalink

Excuse me?

Did you read my OP?

I asked what I information I should supply. At no time in
any of my posts did I say I was not willing to send
information.

If the proxy server does the authentication, why is it that
the proxy server passes the invite to the MWI server and the
MWI server passes back a 401 which the proxy in turn passes
to the endpoint?

In the few short weeks I worked on 4.6 I identified half a
dozen bugs via track which have been acted on. I have no
problem rolling up my sleeves and helping.

I get it. Closed club.

Bye.

--
Regards

Mark Dutton

Tony Graziano

2012-08-07 00:50:34 UTC

Permalink

I did read your OP and I read a lot of the replies. You have the assumption
4.6 is stable and release ready.

Why would the mere mention of what you should supply bother you so? I was
hoping the Italian women's beach volleyball team would do better against
the us team, but I had to let it go too.

If you decide to dig into it first realize I am not paid to help you but
can if you provide the data. I told you what you should do. You will find
others who are the same.

Btw--the proxy authorizes all transactions for its registered UA's so it is
relevant. Assuming the 4.6 install is the same as 4.4 and the phone configs
are the same (disable gruu, etc.), and it doesn't work we would all like to
make sure sipx 4.6 gets fixed.

If its easier for you to take your toys to a new playground, so be it.

Good luck.

~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
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!

Post by Mark Dutton
Excuse me?
Did you read my OP?
I asked what I information I should supply. At no time in
any of my posts did I say I was not willing to send
information.
If the proxy server does the authentication, why is it that
the proxy server passes the invite to the MWI server and the
MWI server passes back a 401 which the proxy in turn passes
to the endpoint?
In the few short weeks I worked on 4.6 I identified half a
dozen bugs via track which have been acted on. I have no
problem rolling up my sleeves and helping.
I get it. Closed club.
Bye.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Mark Dutton

2012-08-07 01:49:24 UTC

Permalink

Firstly, to George Niculae. Thank you for your post. I did
not find the answer there, but I did find it digging back
(via Google) to a very old post.

Secondly to Tony. In your first post you made the following
comment.

Post by Tony Graziano
Since you have an unwillingness to provide this, you're
the 1 who has
painted yourself into this corner is that you find
yourself in.

and

Post by Tony Graziano
I did read your OP and I read a lot of the replies. You

have the assumption

Post by Tony Graziano
4.6 is stable and release ready.

The first piece of advice I received was to send my SIP logs
to Aastra. Hardly helpful. You obviously didn't read my OP
properly as you would have seen that I was asking this
question in relation to 4.4. You still have not answered my
question on why, if the proxy does all auth the auth
originates from the MWI server. I suggest that you don't
know.

For all those who may come across this issue, the problem is
that due to what looks like a bug in the provisioning
component (yes Tony a problem with SipX. Who'd have thunk
it?). When the device group has the registrar and proxy
ports set to 0, this does not carry through to the the
device config which sets them to 5060. This causes the
subscriptions to fail. Each device needs to be set manually
with its proxy and registrar ports to 0. When this is done
and the phone reboots, it subscribes correctly.

Actually, I think the endpoint should be able to suffix the
URI and TO fields with the port number and maybe this is a
bug also, but it can be worked around, so the end result is
good.

Here are a couple of SIP traces. The first is a failing
Aastra with the port number in the URI and following is a
working Aastra.

SUBSCRIBE sip:mailto:***@datamerge.local:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.56.152;branch=z9hG4bKa9fc7cb103b8bbd0c
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "John Smith"
<sip:mailto:***@datamerge.local:5060>;tag=aa18c0e307
To: <sip:mailto:***@datamerge.local:5060>
Call-ID: 0100a73bd54c1be3
CSeq: 7190 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Authorization: Digest
username="204",realm="datamerge.local",nonce="4b94d6dd0195d1d48114df5f063f924f502022bc
",uri="sip:mailto:***@datamerge.local:5060",response="ce4c002cb5d8ff9f5e742b25421a8eee",qop=auth,cnonce=
"e5631b2a",nc=00000001
Contact: "John Smith" <sip:mailto:***@192.168.56.152:5060>
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0

SUBSCRIBE sip:mailto:***@datamerge.local SIP/2.0
Via: SIP/2.0/UDP
192.168.56.153;branch=z9hG4bK94e5fb5712769ede9
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "Minnie Mouse"
<sip:mailto:***@datamerge.local>;tag=2fca36c82b
To: <sip:mailto:***@datamerge.local>
Call-ID: 5c7a05d0d4741d5b
CSeq: 25910 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Contact: "Minnie Mouse"
<sip:mailto:***@192.168.56.153:5060;transport=udp>
Event: message-summary
Expires: 3600
Supported: path
User-Agent: Aastra 53i/3.2.2.2044
Content-Length: 0

As this is a SipX forum and not a myitedepartment forum, I
apologise to other parties for my brash behaviour. Arrogant
attacks tend to get my back up.

--
Regards

Mark Dutton

Joegen Baclor

2012-08-07 04:40:56 UTC

Permalink

Excerp from RFC 3261:

For two URIs to be equal, the user, password, host, and port
components must match.

A URI omitting the user component will not match a URI that
includes one. A URI omitting the password component will not
match a URI that includes one.

A URI omitting any component with a default value will not
match a URI explicitly containing that component with its
default value. For instance, a URI omitting the optional port
component will not match a URI explicitly declaring port 5060.
The same is true for the transport-parameter, ttl-parameter,
user-parameter, and method components.

Post by Mark Dutton
Firstly, to George Niculae. Thank you for your post. I did
not find the answer there, but I did find it digging back
(via Google) to a very old post.
Secondly to Tony. In your first post you made the following
comment.

Post by Tony Graziano
Since you have an unwillingness to provide this, you're
the 1 who has
painted yourself into this corner is that you find
yourself in.

and

Post by Tony Graziano
I did read your OP and I read a lot of the replies. You

have the assumption

Post by Tony Graziano
4.6 is stable and release ready.

The first piece of advice I received was to send my SIP logs
to Aastra. Hardly helpful. You obviously didn't read my OP
properly as you would have seen that I was asking this
question in relation to 4.4. You still have not answered my
question on why, if the proxy does all auth the auth
originates from the MWI server. I suggest that you don't
know.
For all those who may come across this issue, the problem is
that due to what looks like a bug in the provisioning
component (yes Tony a problem with SipX. Who'd have thunk
it?). When the device group has the registrar and proxy
ports set to 0, this does not carry through to the the
device config which sets them to 5060. This causes the
subscriptions to fail. Each device needs to be set manually
with its proxy and registrar ports to 0. When this is done
and the phone reboots, it subscribes correctly.
Actually, I think the endpoint should be able to suffix the
URI and TO fields with the port number and maybe this is a
bug also, but it can be worked around, so the end result is
good.
Here are a couple of SIP traces. The first is a failing
Aastra with the port number in the URI and following is a
working Aastra.
Via: SIP/2.0/UDP
192.168.56.152;branch=z9hG4bKa9fc7cb103b8bbd0c
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "John Smith"
Call-ID: 0100a73bd54c1be3
CSeq: 7190 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Authorization: Digest
username="204",realm="datamerge.local",nonce="4b94d6dd0195d1d48114df5f063f924f502022bc
"e5631b2a",nc=00000001
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0
Via: SIP/2.0/UDP
192.168.56.153;branch=z9hG4bK94e5fb5712769ede9
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "Minnie Mouse"
Call-ID: 5c7a05d0d4741d5b
CSeq: 25910 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Contact: "Minnie Mouse"
Event: message-summary
Expires: 3600
Supported: path
User-Agent: Aastra 53i/3.2.2.2044
Content-Length: 0
As this is a SipX forum and not a myitedepartment forum, I
apologise to other parties for my brash behaviour. Arrogant
attacks tend to get my back up.

Tony Graziano

2012-08-07 06:54:42 UTC

Permalink

The first shows a user agent:

User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044

The second shows a user agent:

User-Agent: Aastra 53i/3.2.2.2044

So the one that "fails" shows a firmware written for a specific platform?

Again, showing only a snippet is not really that helpful. You really ought
to provide a full sip trace:

http://wiki.sipfoundry.org/display/sipXecs/Display+SIP+message+flow+using+Sipviewer

Post by Tony Graziano
Since you have an unwillingness to provide this, you're
the 1 who has
painted yourself into this corner is that you find
yourself in.

and

Post by Tony Graziano
I did read your OP and I read a lot of the replies. You

have the assumption

Post by Tony Graziano
4.6 is stable and release ready.

The first piece of advice I received was to send my SIP logs
to Aastra. Hardly helpful. You obviously didn't read my OP
properly as you would have seen that I was asking this
question in relation to 4.4. You still have not answered my
question on why, if the proxy does all auth the auth
originates from the MWI server. I suggest that you don't
know.
For all those who may come across this issue, the problem is
that due to what looks like a bug in the provisioning
component (yes Tony a problem with SipX. Who'd have thunk
it?). When the device group has the registrar and proxy
ports set to 0, this does not carry through to the the
device config which sets them to 5060. This causes the
subscriptions to fail. Each device needs to be set manually
with its proxy and registrar ports to 0. When this is done
and the phone reboots, it subscribes correctly.
Actually, I think the endpoint should be able to suffix the
URI and TO fields with the port number and maybe this is a
bug also, but it can be worked around, so the end result is
good.
Here are a couple of SIP traces. The first is a failing
Aastra with the port number in the URI and following is a
working Aastra.
Via: SIP/2.0/UDP
192.168.56.152;branch=z9hG4bKa9fc7cb103b8bbd0c
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "John Smith"
Call-ID: 0100a73bd54c1be3
CSeq: 7190 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Authorization: Digest
username="204",realm="datamerge.local",nonce="4b94d6dd0195d1d48114df5f063f924f502022bc
:5060",response="ce4c002cb5d8ff9f5e742b25421a8eee",qop=auth,cnonce=
"e5631b2a",nc=00000001
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0
Via: SIP/2.0/UDP
192.168.56.153;branch=z9hG4bK94e5fb5712769ede9
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "Minnie Mouse"
Call-ID: 5c7a05d0d4741d5b
CSeq: 25910 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Contact: "Minnie Mouse"
Event: message-summary
Expires: 3600
Supported: path
User-Agent: Aastra 53i/3.2.2.2044
Content-Length: 0
As this is a SipX forum and not a myitedepartment forum, I
apologise to other parties for my brash behaviour. Arrogant
attacks tend to get my back up.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
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>

Mark Dutton

2012-08-07 10:08:27 UTC

Permalink

In this instance a full trace won't be of much use. It
simply ends with a 401 unauthorised reply on the failing
endpoint. You can also ignore the different user agent
strings in this instance. Zultys puts these in to enable
functionality at the PBX based on the agent string. The
actual firmware is identical. Both of these endpoints had
the same issues intially. I just wanted to show the before
and after differences.

It is working now and hopefully this will save someone else
the pain of getting it going.

Joegen's SIP RFC excerpt is interesting. Does this mean that
the proxy is inconsistent in the way it handles different
messages? As the was using the port number suffix in the URI
for REGISTER, INVITE and SUBSCRIBE, shouldn't all three have
failed? Only the SUBSCRIBE messages were failing.

Tony Graziano wrote on Tue, 07 August 2012 14:54

Post by Mark Dutton
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
User-Agent: Aastra 53i/3.2.2.2044
So the one that "fails" shows a firmware written for a
specific platform?
Again, showing only a snippet is not really that
helpful. You really ought
http://wiki.sipfoundry.org/display/sipXecs/Display+SIP+messa
ge+flow+using+Sipviewer
On Mon, Aug 6, 2012 at 9:49 PM, Mark Dutton

Post by Mark Dutton
Firstly, to George Niculae. Thank you for your
post. I did
not find the answer there, but I did find it
digging back
(via Google) to a very old post.
Secondly to Tony. In your first post you made the
following
comment.

Post by Tony Graziano
Since you have an unwillingness to provide this,

you're

Post by Mark Dutton

Post by Tony Graziano
the 1 who has
painted yourself into this corner is that you find
yourself in.

and

Post by Tony Graziano
I did read your OP and I read a lot of the replies.

You

Post by Mark Dutton
have the assumption

Post by Tony Graziano
4.6 is stable and release ready.

The first piece of advice I received was to send my
SIP logs
to Aastra. Hardly helpful. You obviously didn't
read my OP
properly as you would have seen that I was asking
this
question in relation to 4.4. You still have not
answered my
question on why, if the proxy does all auth the
auth
originates from the MWI server. I suggest that you
don't
know.
For all those who may come across this issue, the
problem is
that due to what looks like a bug in the
provisioning
component (yes Tony a problem with SipX. Who'd have
thunk
it?). When the device group has the registrar and
proxy
ports set to 0, this does not carry through to the
the
device config which sets them to 5060. This causes
the
subscriptions to fail. Each device needs to be set
manually
with its proxy and registrar ports to 0. When this
is done
and the phone reboots, it subscribes correctly.
Actually, I think the endpoint should be able to
suffix the
URI and TO fields with the port number and maybe
this is a
bug also, but it can be worked around, so the end
result is
good.
Here are a couple of SIP traces. The first is a
failing
Aastra with the port number in the URI and
following is a
working Aastra.
SIP/2.0
Via: SIP/2.0/UDP
192.168.56.152;branch=z9hG4bKa9fc7cb103b8bbd0c
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "John Smith"
Call-ID: 0100a73bd54c1be3
CSeq: 7190 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER,
OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference,
LocalModeStatus
Authorization: Digest
username="204",realm="datamerge.local",nonce="4b94d6dd0195d1d48114df5f063f924f502022bc
:5060",response="ce4c002cb5d8ff9f5e742b25421a8eee",qop=auth,cnonce=
"e5631b2a",nc=00000001
Contact: "John Smith"
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0
Via: SIP/2.0/UDP
192.168.56.153;branch=z9hG4bK94e5fb5712769ede9
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "Minnie Mouse"
Call-ID: 5c7a05d0d4741d5b
CSeq: 25910 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER,
OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference,
LocalModeStatus
Contact: "Minnie Mouse"
Event: message-summary
Expires: 3600
Supported: path
User-Agent: Aastra 53i/3.2.2.2044
Content-Length: 0
As this is a SipX forum and not a myitedepartment
forum, I
apologise to other parties for my brash behaviour.
Arrogant
attacks tend to get my back up.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
http://list.sipfoundry.org/archive/sipx-users/

--
Regards

Mark Dutton

Tony Graziano

2012-08-07 10:30:33 UTC

Permalink

Actually, Aastra provides firmware customized for certain systems. The
phone you indicated was 'broken" was written specifically for the Zultys
platform, while the other was not. Zultys does prefer hold, resume, park,
paging, etc. to work a specific way. They may be subtle differences, but
they are different.This is why they have documents to convert from Zultys
to allow people to continue using them without issues on "other"
platforms".

A full trace would have shown internal communications from the proxy,
registrar, mwi and more. This is why it is asked for, plus when that is
attached it doesn't change the text like your emailer did. This will show
things a pcap WONT show. I don't care if you care or not, I'm just saying a
real sip trace produced from the console is more enlightening when
troubleshooting. It will show things like port number and how it relates
transaction flow. You should consider using it in 4.4 and there is work to
include homer from sipcapture.org (as experimental) in 4.6, but I am not
sure it is working properly yet.

If it were me, and it's not, I would put the phone(s) on the latest
firmware and SP directly from Aastra (V3.2.2.2077), which is two patches
above what you are using. I won't begin to tell you the procedure on how to
convert the phone, but if you are not using it in a Zultys environment you
might find better help from Aastra and such no matter "what platform" you
deploy them on (with the exception of Zultys).

http://www.aastra.ca/cps/rde/aareddownload?file_id=6848-16232-_P07_XML&dsproject=www-aastratelecom-com&mtype=zip

So what happened to "allow" the MWI to begin working? I'm not sure how
helpful it is because you didn't say "how" or "what" you did to make it
work. Care to share?

Post by Mark Dutton
In this instance a full trace won't be of much use. It
simply ends with a 401 unauthorised reply on the failing
endpoint. You can also ignore the different user agent
strings in this instance. Zultys puts these in to enable
functionality at the PBX based on the agent string. The
actual firmware is identical. Both of these endpoints had
the same issues intially. I just wanted to show the before
and after differences.
It is working now and hopefully this will save someone else
the pain of getting it going.
Joegen's SIP RFC excerpt is interesting. Does this mean that
the proxy is inconsistent in the way it handles different
messages? As the was using the port number suffix in the URI
for REGISTER, INVITE and SUBSCRIBE, shouldn't all three have
failed? Only the SUBSCRIBE messages were failing.
Tony Graziano wrote on Tue, 07 August 2012 14:54

Post by Mark Dutton
Firstly, to George Niculae. Thank you for your
post. I did
not find the answer there, but I did find it
digging back
(via Google) to a very old post.
Secondly to Tony. In your first post you made the
following
comment.

Post by Tony Graziano
Since you have an unwillingness to provide this,

you're

Post by Mark Dutton

Post by Tony Graziano
the 1 who has
painted yourself into this corner is that you find
yourself in.

and

Post by Tony Graziano
I did read your OP and I read a lot of the replies.

You

Post by Mark Dutton
have the assumption

Post by Tony Graziano
4.6 is stable and release ready.

username="204",realm="datamerge.local",nonce="4b94d6dd0195d1d48114df5f063f924f502022bc

Post by Mark Dutton

Post by Mark Dutton
:5060",response="ce4c002cb5d8ff9f5e742b25421a8eee",qop=auth,cnonce=
"e5631b2a",nc=00000001
Contact: "John Smith"
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0
Via: SIP/2.0/UDP
192.168.56.153;branch=z9hG4bK94e5fb5712769ede9
Route: <sip:sipxecs.datamerge.local;lr>
Max-Forwards: 70
From: "Minnie Mouse"
Call-ID: 5c7a05d0d4741d5b
CSeq: 25910 SUBSCRIBE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER,
OPTIONS,
UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference,
LocalModeStatus
Contact: "Minnie Mouse"
Event: message-summary
Expires: 3600
Supported: path
User-Agent: Aastra 53i/3.2.2.2044
Content-Length: 0
As this is a SipX forum and not a myitedepartment
forum, I
apologise to other parties for my brash behaviour.
Arrogant
attacks tend to get my back up.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
http://list.sipfoundry.org/archive/sipx-users/

--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Mark Dutton

2012-08-07 11:13:05 UTC

Permalink

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.

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 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

Michael Picher

2012-08-07 11:15:41 UTC

Permalink

Not sure why nobody has patched it but this has been around since 3.10.x.
I don't see a tracker item on it so that would be the place to start.
http://track.sipfoundry.org

This is a long-known issue with the Aastra config template. Patches are of
course welcome.

Mike

Post by Mark Dutton
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.
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 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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Tony Graziano

2012-08-07 11:22:45 UTC

Permalink

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.

Post by Mark Dutton
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.

Post by Mark Dutton
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Michael Picher

2012-08-07 12:04:53 UTC

Permalink

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

Post by Tony Graziano

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
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.

I never suggested that. I did suggest a siptrace from sipx so the call
flow could be seen using sipviewer.

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Tony Graziano

2012-08-07 13:09:22 UTC

Permalink

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 "***@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?

Post by Michael Picher
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 <

Post by Tony Graziano

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
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.

I never suggested that. I did suggest a siptrace from sipx so the call
flow could be seen using sipviewer.

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Mark Dutton

2012-08-07 14:34:53 UTC

Permalink

I am getting a little confused here Tony, but I will
reiterate what I see. I think I am seeing what you are
seeing.

First time into a virgin devices groups / Aastra (55i say).

Click into server settings then click on "show advanced
settings"

The proxy port, registrar port and outbound proxy port are
all 0. This is what we want (for now).

I have entered a FQDN for the outbound proxy as all my
Aastras seem not to handle SRV DNS records.

Now into my devices list (based on my devices group) and
onto one of my Aastra phone lines. Click onto server and
"show advanced settings"

proxy and registrar are automatically filled in with the
default domain name. In my case datamerge.local
Outbound proxy is set to sipxecs.datamerge.local as
inherited from my devices group.
proxy port and registrar port are set to 5060 which is NOT
what I want.
Outbound proxy port is still 0

I have to manually set my proxy port and registrar port to 0
manually for each handset.

If the phone has its proxy port and registrar port set to
5060 it presents the URI (e.g. for extension 204) as
REGISTER sip:datamerge.local:5060, INVITE
sip:mailto:***@datamerge.local:5060 and SUBSCRIBE
sip:mailto:***@datamerge.local:5060.

Registrations and INVITEs handle this fine, but
SUBSCRIPTIONS fail with a 401 auth error.

When the phone has its proxy port and registrar port set to
0 it presents the URI as REGISTER sip:datamerge.local,
INVITE sip:mailto:***@datamerge.local and SUBSCRIBE
sip:mailto:***@datamerge.local.

This works for all functions.

In all the above I set the outbound proxy on the Aastras to
give the phone a FQDN (sipxecs.datamerge.local) to talk to
as it seems to have difficulty with SRV lookups.

I think the bug in the provisioning is that the default
values in the devices groups screens are populated with 0,
instead of being NULL like other fields. These are treated
as NULLS by the template logic, where 0 is a valid value for
the Aastras. The fields in the group template should be NULL
instead of 0. When 0 is put into them the phone configs
should follow with 0. Alternatively, the default of the
phone settings should simply be 0 to follow the default
group template.

Hope this makes it clearer.

Tony Graziano wrote on Tue, 07 August 2012 21:09

Post by Tony Graziano
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
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

Post by Michael Picher
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 <

On Tue, Aug 7, 2012 at 7:13 AM, Mark Dutton

Post by Mark Dutton
I did say exactly what I did to make it work in an

earlier