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.




On 08/07/2012 09:49 AM, Mark Dutton wrote:

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.

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

I did read your OP and I read a lot of the replies. You
have the assumption
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:[email protected]: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:[email protected]:5060>;tag=aa18c0e307
To: <sip:mailto:[email protected]: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:[email protected]:5060",response="ce4c002cb5d8ff9f5e742b25421a8eee",qop=auth,cnonce=
"e5631b2a",nc=00000001
Contact: "John Smith" <sip:mailto:[email protected]:5060>
Event: message-summary
Expires: 86400
Supported: path
User-Agent: Aastra/ZULTYS_ZIP 53i/3.2.2.2044
Content-Length: 0


SUBSCRIBE sip:mailto:[email protected] 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:[email protected]>;tag=2fca36c82b
To: <sip:mailto:[email protected]>
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:[email protected]: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.



_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to