I don't think that the problem in URI is presence of npdi. The problem is IMO that it is a SIP URDI without a domain -- I don't really see to where I would be able to send such a URI.
-jiri
At 19:53 23/06/2006, John Clements wrote:
I've looked around and have found one or two other posts asking about this, but I have never seen an answer. The From is:
=uri: sip:5551212;npdi=yes@x.x.x.x:5060;dtg=SIP;user=phone
Which causes a number of issues. USRLOC no longer works:
=lookup(): '5551212;npdi=yes' Not found in usrloc
And when you send the call to an Asterisk server, Asterisk wigs out because it truncates everything after the first ";" it encounters in the URI. Does anyone have any idea how to get rid of it? I've tried subst(), but could not get it to work. :-(
-John
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
I bag to disagree but according to the BNF of RFC3261 (page 222) the username of the URI below is '5551212;npdi=yes' and the host part ist 'x.x.x.x' (and the URI parameters are 'dtg=SIP' and 'user=phone'). But IMHO each implementation which puts such an extension into the username should be aware of the fact that all implementations which are not compliant with this extension will interpret the username like described above (and AFAIK there is no rule which tells 3261 implementations to strip anything in an username).
Regards Nils
On Saturday 24 June 2006 09:59, Jiri Kuthan wrote:
I don't think that the problem in URI is presence of npdi. The problem is IMO that it is a SIP URDI without a domain -- I don't really see to where I would be able to send such a URI.
-jiri
At 19:53 23/06/2006, John Clements wrote:
I've looked around and have found one or two other posts asking about this, but I have never seen an answer. The From is:
=uri: sip:5551212;npdi=yes@x.x.x.x:5060;dtg=SIP;user=phone
Which causes a number of issues. USRLOC no longer works:
=lookup(): '5551212;npdi=yes' Not found in usrloc
And when you send the call to an Asterisk server, Asterisk wigs out because it truncates everything after the first ";" it encounters in the URI. Does anyone have any idea how to get rid of it? I've tried subst(), but could not get it to work. :-(
-John
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Nils Ohlmeier writes:
I bag to disagree but according to the BNF of RFC3261 (page 222) the username of the URI below is '5551212;npdi=yes' and the host part ist 'x.x.x.x' (and the URI parameters are 'dtg=SIP' and 'user=phone').
syntax of userinfo is
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
in the case of question, userinfo consists of telephone-subscriber and its syntax is defined in rfc2806.
-- juha
On Monday 26 June 2006 12:09, Juha Heinanen wrote:
Nils Ohlmeier writes:
I bag to disagree but according to the BNF of RFC3261 (page 222) the username of the URI below is '5551212;npdi=yes' and the host part ist 'x.x.x.x' (and the URI parameters are 'dtg=SIP' and 'user=phone').
syntax of userinfo is
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
in the case of question, userinfo consists of telephone-subscriber and its syntax is defined in rfc2806.
Ok, but the URI does not uses the tel URI scheme. Thus there is no way of detecting that this user part is telephone-subscriber and not a normal user, or? And BTW even if the URI would have used the tel scheme usrloc also has no clue that telephone-subscriber users have to be treated differently.
Nils
Nils Ohlmeier writes:
Ok, but the URI does not uses the tel URI scheme. Thus there is no way of detecting that this user part is telephone-subscriber and not a normal user, or?
if sip uri has user=phone parameter, then proxy could try to parse user part as telephone-subscriber.
And BTW even if the URI would have used the tel scheme usrloc also has no clue that telephone-subscriber users have to be treated differently.
that is indeed a problem with current implementation.
-- juha
-
Jiri Kuthan -
Juha Heinanen -
Nils Ohlmeier