23 Jun
2006
23 Jun
'06
7:53 p.m.
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
24 Jun
24 Jun
9:31 a.m.
AFAIK it's not possible with From. SER processes messages and always
keep the original message. When you do subst etc, you basically tell SER
how to change the message before sending a reply or forwarding. The ruri
can be changed (but still the original uri is kept, i.e. revert_uri())
The lookup function will use the From in the original message,
regardless of what you do.
You have a broken UA.
g-)
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:43 p.m.
You have a broken UA.
Where do you get that? Nothing is broken, its the Number Porting flag the
TDM sends. If anything, Asterisk and SER are broken because they do not
recognize it :-)
And its subst_uri() that gets rid of it. I found it last night. Thanks
though.
-John
> AFAIK it's not possible with From. SER processes messages and always
> keep the original message. When you do subst etc, you basically tell SER
> how to change the message before sending a reply or forwarding. The ruri
> can be changed (but still the original uri is kept, i.e. revert_uri())
> The lookup function will use the From in the original message,
> regardless of what you do.
You have a broken UA.
> g-)
>
> 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(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>
>
>
3:57 p.m.
Hi John,
I have to ask: is it, by chance, a UA you are developing? :)
John Clements wrote:
... I mean, you have to have a motivation to be so drastic when judging
some many bright minds' outcome. :)
You have a
broken UA.
Where do you get that? Nothing is broken, its the Number Porting flag the
TDM sends. If anything, Asterisk and SER are broken because they do not
recognize it :-)
And its subst_uri() that gets rid of it. I found it
last night. Thanks
though.
-John
AFAIK it's not possible with From. SER
processes messages and always
keep the original message. When you do subst etc, you basically tell SER
how to change the message before sending a reply or forwarding. The ruri
can be changed (but still the original uri is kept, i.e. revert_uri())
The lookup function will use the From in the original message,
regardless of what you do.
You have a broken UA.
g-)
John Clements wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:09 p.m.
New subject: Re[2]: [Serusers] How do I get rid of npdi=yes?
Hello John,
As RFC3261 (19.1.1) says, you have a broken UA.
Saturday, June 24, 2006 4:43:26 PM, you wrote:
> You have a broken UA.
JC> Where do you get that? Nothing is broken, its the Number Porting flag the
JC> TDM sends. If anything, Asterisk and SER are broken because they do not
JC> recognize it :-)
JC> And its subst_uri() that gets rid of it. I found it last night. Thanks
JC> though.
JC> -John
>> AFAIK it's not possible with From. SER processes messages and always
>> keep the original message. When you do subst etc, you basically tell SER
>> how to change the message before sending a reply or forwarding. The ruri
>> can be changed (but still the original uri is kept, i.e. revert_uri())
>> The lookup function will use the From in the original message,
>> regardless of what you do.
> You have a broken UA.
>> g-)
>>
>> 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(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>>
>>
>>
JC> _______________________________________________
JC> Serusers mailing list
JC> Serusers(a)lists.iptel.org
JC> http://lists.iptel.org/mailman/listinfo/serusers
--
Mike Tkachuk
25 Jun
25 Jun
9:03 a.m.
Hi John,
I'm assuming you are using a Sonus gateway? This is a known problem with
Sonus. They put a few of the options (namely NPDI and RN) to the left of
the "@". It's kinda crazy.. Asterisk versions >= 1.2.7 WILL NOT be able
to
properly parse this URI. I'm working on a bug in the asterisk bug tracker
http://bugs.digium.com/view.php?id=7208
They are waiting on me to do a debug from my Sonus gateway, just been busy
lately.
As for SER, you should consder using the textopts modules. Try the functions:
subst_uri
or
subst_user
Let us know what that does for you..
-Brett
On Fri, June 23, 2006 12:53 pm, 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:52 a.m.
Brett N writes:
I'm assuming you are using a Sonus gateway? This
is a known problem with
Sonus. They put a few of the options (namely NPDI and RN) to the left of
the "@".
are you sure that npdi and rn are not tel uri params that must be on
left side of @? for example, 19.1.6 of rfc3261:
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
-- juha
26 Jun
26 Jun
8:15 a.m.
Sun, Jun 25, 2006 at 11:52:22, jh wrote about "Re: [Serusers] How do I get rid of
npdi=yes?":
Yes, Sonus implementation follows draft-yu-tel-url-02.txt
(very old and obsoleted draft, but still in use by some vendors)
based on RFC3261. An illustrative table from the draft:
_+----------------------------------+----------------------+
| ANSI ISUP | "tel" URL |
_+==================================+======================+
| Called Party Number | rn |
+----------------------------------+----------------------+
| "ported number" in | POTS number after |
| Generic Address Parameter | "tel:" |
+----------------------------------+----------------------+
| Ported Number Translation | |
| Indicator bit set in the | npdi=yes |
| Forward Call Indicator | |
+----------------------------------+----------------------+
| Carrier Identification Parameter | cic |
+----------------------------------+----------------------+
Example URLs from it:
Example 1: A "tel" URL such as
tel:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes
can be converted to a "sip" URL shown below.
sip:+1-202-533-1234;rn=+1-202-5443-0000;
npdi=yes(a)sip.abc.com;user=phone
Example 2: A "tel" URL such as
tel:+1-800-123-4567;cic=+1-6789
can be converted to a "sip" URL shown below.
sip:+1-800-123-4567;cic=+1-6789@sip.xyz.com;user=phone
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
* Meet us at CommunicAsia in Singapore, 20-23 June 2006, Booth 3J1-08
* http://www.communicasia.com
I'm
assuming you are using a Sonus gateway? This is a known problem with
Sonus. They put a few of the options (namely NPDI and RN) to the left of
the "@".
are you sure that npdi and rn are not tel uri params that must
be on
left side of @? for example, 19.1.6 of rfc3261:
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
8:29 a.m.
Valentin Nechayev writes:
Sun, Jun 25, 2006 at 11:52:22, jh wrote about
"Re: [Serusers] How do I get rid of npdi=yes?":
Yes, Sonus implementation follows draft-yu-tel-url-02.txt
(very old and obsoleted draft, but still in use by some vendors)
based on RFC3261. An illustrative table from the draft:
to me your sonus URI looks compatible also with tel uri syntax as
specified in RFC 3966.
-- juha
I'm
assuming you are using a Sonus gateway? This is a known problem with
Sonus. They put a few of the options (namely NPDI and RN) to the left of
the "@".
are you sure that npdi and rn are not tel uri params that must
be on
left side of @? for example, 19.1.6 of rfc3261:
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
10:13 a.m.
Mon, Jun 26, 2006 at 09:29:33, jh wrote about "Re: [Serusers] How do I get rid of
npdi=yes?":
to me your sonus URI
my? ;)
are you sure that npdi and rn are not tel uri params
that must be on
left side of @? for example, 19.1.6 of rfc3261:
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
Yes, Sonus implementation
follows draft-yu-tel-url-02.txt
(very old and obsoleted draft, but still in use by some vendors)
based on RFC3261. An illustrative table from the draft: looks compatible also with tel uri syntax as
specified in RFC 3966.
RFC3966 is only common "tel" specification.
RFC3398 specifies ISUP->SIP
mapping in manner very closed to the yu-tel-url draft.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
* Meet us at CommunicAsia in Singapore, 20-23 June 2006, Booth 3J1-08
* http://www.communicasia.com
6733
days inactive
6736
days old
9 comments
7 participants
participants (7)
-
Brett N -
Greger V. Teigre -
John Clements -
Juha Heinanen -
Mike Tkachuk -
Valentin Nechayev -
Weiter Leiter