[agranig]

Is there a way to use the R-Uri to determine the DIDN instead of the To-user or a To-header-parameter? According to RFC3261, To holds the original destination, which might change during call routing because of call forwards or some DIDN mangling, which is reflected in the Request URI, but usually not in the To-header.

So if a SIP proxy rewrites the R-Uri because of a call-forward, the call breaks if an SPA9000 is the final destination because it uses the To-header instead of the R-Uri to get the DIDN. Any solutions for this?

Example:

A (1234) calls B (2345):

INVITE sip:2345@some.domain
From: sip:1234@some.domain;tag=123
To: sip:2345@some.domain

Proxy forwards call to C (3456) with extension 100:

INVITE: sip:3456100@some.domain
From: sip:1234@some.domain;tag=123
To: sip:2345@some.domain

This is a perfectly valid call flow, but C isn't able to properly ring 100 because it only sees To, which is 2345. It would work if To where either sip:3456100@some.domain or sip:2345@some.domain;didn=3456100, but this is more than impractical, if not an RFC violation.

[humba3]

Wouldn't "SIP Remote-Party ID" on the phones do the trick?

There's no other did related setting on the SPA9k itself afaik.

[agranig]

Originally Posted by humba3

Wouldn't "SIP Remote-Party ID" on the phones do the trick?

Remote-Party-ID is used to transport the calling party number, but the problem of the spa9k is that it uses To (either the user-id or a parameter) instead of Request-URI to get the called party number.