6 Aug
2009
6 Aug
'09
2:31 a.m.
Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio doesn't
support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
- "is_sips?": returns true if RURI has SIPS URI.
- "is_sip_ips?": returns true if RURI has SIP or SIPS URI.
- "is_tel?": returns true if RURI has TEL URI.
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
6 Aug
6 Aug
3:05 a.m.
Iñaki Baz Castillo wrote:
Hi, does/will SR implement TEL URI properly? This is:
OpenSer/Kamailio doesn't
support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
if($ru =~ "^sip:")
- "is_sips?": returns true if RURI has SIPS
URI.
if($ru =~ "^sips:")
- "is_sip_ips?": returns true if RURI has
SIP or SIPS URI.
if($ru =~ "^sip([s]*):)
- "is_tel?": returns true if RURI has TEL
URI.
if($ru =~ "^tel:")
?
Or are you looking for something more involved than that, i.e.
validation of the actual contents of the values and not just the alleged
URI scheme?
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
11:31 a.m.
2009/8/6 Alex Balashov <abalashov(a)evaristesys.com>om>:
Iñaki Baz Castillo wrote:
Yes Alex, the above is a hack ;)
The current "support" of TEL uri is also a "hack", since after
parsing
a TEL URI what we have is:
- $rU = null
- $rd = the TEL number
(note: parhaps is the opposite)
I'd realy would like to have something as:
- $rtU = RURI TEL number
- $rtparams = RURI TEL parameters
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hi, does/will SR implement TEL URI properly? This
is: OpenSer/Kamailio
doesn't support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
if($ru =~ "^sip:")
- "is_sips?": returns true if RURI has
SIPS URI.
if($ru =~ "^sips:")
- "is_sip_ips?": returns true if RURI
has SIP or SIPS URI.
if($ru =~ "^sip([s]*):)
- "is_tel?": returns true if RURI has
TEL URI.
if($ru =~ "^tel:")
?
Or are you looking for something more involved than that, i.e. validation of
the actual contents of the values and not just the alleged URI scheme? 
11:42 a.m.
Hello,
On 06.08.2009 10:31 Uhr, Iñaki Baz Castillo wrote:
2009/8/6 Alex Balashov
<abalashov(a)evaristesys.com>om>:
sip-router core has support for tel uri, but there are no PVs associated
with. The username should be the tel number and the host is empty. Try
and see if all works ok.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
Iñaki Baz Castillo wrote:
Yes Alex, the above is a hack ;)
The current "support" of TEL uri is also a "hack", since after
parsing
a TEL URI what we have is:
- $rU = null
- $rd = the TEL number
(note: parhaps is the opposite)
I'd realy would like to have something as:
- $rtU = RURI TEL number
- $rtparams = RURI TEL parameters
Hi, does/will SR implement TEL URI properly? This
is: OpenSer/Kamailio
doesn't support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
if($ru =~ "^sip:")
- "is_sips?": returns true if RURI has
SIPS URI.
if($ru =~ "^sips:")
- "is_sip_ips?": returns true if RURI
has SIP or SIPS URI.
if($ru =~ "^sip([s]*):)
- "is_tel?": returns true if RURI has
TEL URI.
if($ru =~ "^tel:")
?
Or are you looking for something more involved than that, i.e. validation of
the actual contents of the values and not just the alleged URI scheme?
11:43 a.m.
Iñaki Baz Castillo wrote:
The current "support" of TEL uri is also a "hack", since after
parsing
a TEL URI what we have is:
- $rU = null
- $rd = the TEL number
(note: parhaps is the opposite)
I'd realy would like to have something as:
- $rtU = RURI TEL number
- $rtparams = RURI TEL parameters
Call me biased, but I do prefer the select stuff:
@ruri.type -> "tel"
@ruri.user -> number
@ruri.params -> parameters
@ruri.params["phone-context"] -> phone-context parameter
The only thing I always need to look up is whether it is user or
username. One could probably add a sub-select "number" which is only
valid if the type is "tel" or if the username part of the URI consists
of characters valid in a TEL URI.
I know C people like their functions and variables to have cryptical
names for hyst[eo]rical reasons, but this is so 20th century.
Regards,
Martin
11:48 a.m.
On 06.08.2009 10:43 Uhr, Martin Hoffmann wrote:
Iñaki Baz Castillo wrote:
in K there are transformations that can be used as well for other
variables that contains URI:
$var(x) = "sip:daniel@xyz.com";
$(var(x){uri.user})
http://www.kamailio.org/dokuwiki/doku.php/transformations:1.5.x#uri_transfo…
Cheers,
Daniel
The current "support" of TEL uri is
also a "hack", since after parsing
a TEL URI what we have is:
- $rU = null
- $rd = the TEL number
(note: parhaps is the opposite)
I'd realy would like to have something as:
- $rtU = RURI TEL number
- $rtparams = RURI TEL parameters
Call me biased, but I do prefer the select stuff:
@ruri.type -> "tel"
@ruri.user -> number
@ruri.params -> parameters
@ruri.params["phone-context"] -> phone-context parameter
The only thing I always need to look up is whether it
is user or
username. One could probably add a sub-select "number" which is only
valid if the type is "tel" or if the username part of the URI consists
of characters valid in a TEL URI.
I know C people like their functions and variables to have cryptical
names for hyst[eo]rical reasons, but this is so 20th century.
Regards,
Martin
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
11:51 a.m.
2009/8/6 Martin Hoffmann <martin.hoffmann(a)telio.ch>ch>:
Call me biased, but I do prefer the select stuff:
@ruri.type -> "tel"
@ruri.user -> number
@ruri.params -> parameters
@ruri.params["phone-context"] -> phone-context parameter
The only thing I always need to look up is whether it is user or
username. One could probably add a sub-select "number" which is only
valid if the type is "tel" or if the username part of the URI consists
of characters valid in a TEL URI.
I know C people like their functions and variables to have cryptical
names for hyst[eo]rical reasons, but this is so 20th century.
I agree 200%. In fact I really would like that each module exports
functions (and pseudo-variables) into a namespace, example:
if userloc.lockup("location")
There are ~ 100 modules right now, each one adding functions and
pseudo variables to the config script. When I see "check_to" or
"is_gw" it's really annoying to know which is the parent module of
those functions. Imagine a newbie inspecting for first time the
example config file.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:02 a.m.
6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo:
Hi, does/will SR implement TEL URI properly? This is:
OpenSer/
Kamailio doesn't
support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
- "is_sips?": returns true if RURI has SIPS URI.
- "is_sip_ips?": returns true if RURI has SIP or SIPS URI.
- "is_tel?": returns true if RURI has TEL URI.
At the same time, we could implement support for other URI's, like
XMPP since we have an xmpp gateway.
/O
3:24 p.m.
Olle E. Johansson schrieb:
6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo:
Yes, should be generic as RFC 3261 which allows all kind of URIs
klaus
Hi, does/will SR implement TEL URI properly? This
is: OpenSer/Kamailio
doesn't
support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
- "is_sips?": returns true if RURI has SIPS URI.
- "is_sip_ips?": returns true if RURI has SIP or SIPS URI.
- "is_tel?": returns true if RURI has TEL URI.
At the same time, we could implement support for other URI's, like XMPP
since we have an xmpp gateway.
3:42 p.m.
2009/8/6 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI".
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
At the same
time, we could implement support for other URI's, like XMPP
since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all kind of URIs 
4:12 p.m.
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castillo<ibc(a)aliax.net> wrote:
2009/8/6 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI".
Why not?
At the
same time, we could implement support for other URI's, like XMPP
since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all kind of URIs AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
Jan.
4:24 p.m.
2009/8/6 Jan Janak <jan(a)ryngle.com>om>:
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz
Castillo<ibc(a)aliax.net> wrote:
According to some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI).
But if SR impements HTTP perfect, then I'll configure a SR as HTTP
proxy and load balancer XDD
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2009/8/6 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI".
Why not?
At the
same time, we could implement support for other URI's, like XMPP
since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all kind of URIs AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
4:34 p.m.
Iñaki Baz Castillo wrote:
According to some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI).
Because it isn't specified, it can't be done? One could probably think
of some scenarios where a MESSAGE request with a text body and a mailto
URI does make sense. Of course you need some pre-configured logic to
make the proxy understand what to do with it. If it knows where to send
the request to, it can happily do that. No need to have a SIP URI for
that purpose.
Regards,
Martin
4:47 p.m.
2009/8/6 Martin Hoffmann <martin.hoffmann(a)telio.ch>ch>:
Iñaki Baz Castillo wrote:
Ok, but for sure that's not the purpose of a SIP proxy ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
According to some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI).
Because it isn't specified, it can't be done? One could probably think
of some scenarios where a MESSAGE request with a text body and a mailto
URI does make sense. Of course you need some pre-configured logic to
make the proxy understand what to do with it. If it knows where to send
the request to, it can happily do that. No need to have a SIP URI for
that purpose.
4:57 p.m.
On Thu, Aug 6, 2009 at 3:47 PM, Iñaki Baz Castillo<ibc(a)aliax.net> wrote:
2009/8/6 Martin Hoffmann
<martin.hoffmann(a)telio.ch>ch>:
Just to make things a bit more clear, I was asking why not because I
assumed that you were referring to some existing internet draft or RFC
which says that HTTTP (and possibly other URI types) should not be
used in SIP messages.
Possibly because they are considered harmful, or something like that
(IETF does issue such RFCs from time to time). Not being able to
recall any such document, I thought I missed it.
If that's not the case then I just mentally add "in my opinion" to the
original text to make is sound less definitive.
I was not trying to argue that HTTP (or any other URI types) should be
explicitly supported by a SIP proxy.
Jan.
Iñaki Baz Castillo wrote:
Ok, but for sure that's not the purpose of a SIP proxy ;)
According to some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI).
Because it isn't specified, it can't be done? One could probably think
of some scenarios where a MESSAGE request with a text body and a mailto
URI does make sense. Of course you need some pre-configured logic to
make the proxy understand what to do with it. If it knows where to send
the request to, it can happily do that. No need to have a SIP URI for
that purpose.
9:09 p.m.
6 aug 2009 kl. 15.24 skrev Iñaki Baz Castillo:
2009/8/6 Jan Janak <jan(a)ryngle.com>om>:
Why should it be
translated???
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz
Castillo<ibc(a)aliax.net>
wrote:
According to some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI). 2009/8/6 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Why not?
> At the same time, we could implement support
for other URI's,
> like XMPP
> since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all kind of URIs
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI". AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
But if SR impements HTTP perfect, then I'll configure a SR as HTTP
proxy and load balancer XDD
No, but there's a lot of stuff now being implemented in HTTP requests
in regards to SIP conferencing and SIMPLE.
/O
9:22 p.m.
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
I don't remember the details right now, but AFAIR a UAC sends a URN request to
its oubound proxy which routes it to the proxy server handling those kind of
requests. The later proxies translates them into a normal SIP/TEL URI
generating a normal call to a PSTN number (the PSTN emergency number according
for the caller based on his location and so on).
ops, I didn't read about it.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
According to
some exotic RFC, a proxy should handle a URN URI and
translate it into a SIP URI (or route the request to a predefined
proxy which handles it). But no specification defines how a HTTP URI
should be translated into a SIP URI (or other kind of URI).
Why should it be translated??? But if SR
impements HTTP perfect, then I'll configure a SR as HTTP
proxy and load balancer XDD
No, but there's a lot of stuff now being implemented in HTTP requests
in regards to SIP conferencing and SIMPLE.
6:25 p.m.
Iñaki Baz Castillo schrieb:
2009/8/6 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI".
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
IMO this is a little bit short-sighted. You never know which knid of new
URIs we have in 3 years.
It would be great if we do not have to patch sr for every new URI schema
- having support for "absolute-URI" would allow to just handle the URI
to an external application (exec, http, DB-query, radius ..whatever) and
do the routing for the next hop.
regaeds
Klaus
At the
same time, we could implement support for other URI's, like XMPP
since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all
kind of URIs
7:36 p.m.
6 aug 2009 kl. 14.42 skrev Iñaki Baz Castillo:
2009/8/6 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a
request, or a mailto URI, even if RFC 3261 says "any URI".
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
You're forgetting
- IM
- XMPP
- PRES
/O
At the
same time, we could implement support for other URI's, like
XMPP
since we have an xmpp gateway.
Yes, should be generic as RFC 3261 which allows all kind of URIs
7:51 p.m.
2009/8/6 Olle E. Johansson <oej(a)edvina.net>et>:
You're forgetting
- IM
IM: Hyper exotic concept made in IETF which absolutely nobody cares
and nobody implements.
- PRES
Idem.
- XMPP
Why should a SIP proxy manage XMPP URI?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:19 p.m.
6 aug 2009 kl. 18.51 skrev Iñaki Baz Castillo:
I can't say much about that.
sip router already has XMPP gateways. In order to send instant
messages or set up calls to URI's in the XMPP name space, it's easier
to use that than having to mangle it with various strange methods.
MESSAGE sip:inaki@aliax.net
From: xmpp:oej@edvina.net
To: sip:inaki@aliax.net
See?
/O
2009/8/6 Olle E. Johansson <oej(a)edvina.net>et>:
Well, I spent a few hours with at least one person that implements it
at IETF. It's coming.
You're forgetting
- IM
IM: Hyper exotic concept made in IETF which absolutely nobody cares
and nobody implements. - PRES
Idem. - XMPP
Why should a SIP proxy manage XMPP URI?
9:24 p.m.
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
This means that the receipt of the request (my softphone) should also allow
XMPP URI to display the From. Since no RFC states it, why should my softphone
implement it?
--
Iñaki Baz Castillo <ibc(a)aliax.net>
Why should a
SIP proxy manage XMPP URI?
sip router already has XMPP gateways. In order to send instant
messages or set up calls to URI's in the XMPP name space, it's easier
to use that than having to mangle it with various strange methods.
MESSAGE sip:inaki@aliax.net
From: xmpp:oej@edvina.net
To: sip:inaki@aliax.net
See?
9:32 p.m.
6 aug 2009 kl. 20.24 skrev Iñaki Baz Castillo:
El Jueves, 6 de Agosto de 2009, Olle E. Johansson
escribió:
This means that the receipt of the request (my softphone) should
also allow
XMPP URI to display the From. Since no RFC states it, why should my
softphone
implement it?
Because of future work being done right now that will soon result in
internet-drafts.
SIP - XMPP interoperability...
Wait and see.
/O
Why
should a SIP proxy manage XMPP URI?
sip router already has XMPP gateways. In order to send instant
messages or set up calls to URI's in the XMPP name space, it's easier
to use that than having to mangle it with various strange methods.
MESSAGE sip:inaki@aliax.net
From: xmpp:oej@edvina.net
To: sip:inaki@aliax.net
See?
9:55 p.m.
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
I strongly prefer to improve the SIP high presence including XCAP more than
interoperating with other protocols. ;)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
This means
that the receipt of the request (my softphone) should
also allow
XMPP URI to display the From. Since no RFC states it, why should my
softphone
implement it?
Because of future work being done right now that will soon result in
internet-drafts.
SIP - XMPP interoperability...
Wait and see.
10:30 p.m.
6 aug 2009 kl. 20.55 skrev Iñaki Baz Castillo:
El Jueves, 6 de Agosto de 2009, Olle E. Johansson
escribió:
I strongly prefer to improve the SIP high presence including XCAP
more than
interoperating with other protocols. ;)
Well interoperability was one of the CPIM requirements from IETF, so
you'll be trapped there no matter what ;-)
/O
This
means that the receipt of the request (my softphone) should
also allow
XMPP URI to display the From. Since no RFC states it, why should my
softphone
implement it?
Because of future work being done right now that will soon result in
internet-drafts.
SIP - XMPP interoperability...
Wait and see.
10:40 p.m.
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
ok, I prefer to fix SIP/SIMPLE interoperability *before* implementing
interoperability between SIP and XMPP ;)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
I strongly
prefer to improve the SIP high presence including XCAP
more than
interoperating with other protocols. ;)
Well interoperability was one of the CPIM requirements from IETF, so
you'll be trapped there no matter what ;-)
7 Aug
7 Aug
2:34 p.m.
Iñaki Baz Castillo schrieb:
El Jueves, 6 de Agosto de 2009, Olle E. Johansson
escribió:
This means that the receipt of the request (my softphone) should also allow
XMPP URI to display the From. Since no RFC states it, why should my softphone
implement it?
Because RFC 3261 defines it:
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
addr-spec = SIP-URI / SIPS-URI / absoluteURI
^^^^^^^^^^^^^^
regards
klaus
Why
should a SIP proxy manage XMPP URI?
sip router already has XMPP gateways. In order
to send instant
messages or set up calls to URI's in the XMPP name space, it's easier
to use that than having to mangle it with various strange methods.
MESSAGE sip:inaki@aliax.net
From: xmpp:oej@edvina.net
To: sip:inaki@aliax.net
See?
2:35 p.m.
2009/8/7 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Because RFC 3261 defines it:
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
addr-spec = SIP-URI / SIPS-URI / absoluteURI
^^^^^^^^^^^^^^
Yes, I know. However I would like to know how many implementations
would accept it and don't reject the request :(
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
MESSAGE sip:inaki@aliax.net
From: xmpp:oej@edvina.net
To: sip:inaki@aliax.net
See?
This means that the receipt of the request (my softphone) should also
allow XMPP URI to display the From. Since no RFC states it, why should my
softphone implement it?
2:41 p.m.
2009/8/7 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Yes, I know. However I would like to know how many implementations
would accept it and don't reject the request :(
Also, please suggest me what would be the content of $fu, $fU, $fd in
the following cases:
a) From: <xmpp:oej@edvina.net>;tag=1234567
b) From:
<http://mi-web-interface.example.org/ohyeah?user=alice&service=cool>;tag=123123
c) From: <mailto:bob@domain.org>;tag=12234234
:)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
This means that the receipt of the request (my
softphone) should also
allow XMPP URI to display the From. Since no RFC states it, why should my
softphone implement it?
Because RFC 3261 defines it:
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
addr-spec = SIP-URI / SIPS-URI / absoluteURI
^^^^^^^^^^^^^^
6 Aug
6 Aug
8:23 p.m.
6 aug 2009 kl. 14.24 skrev Klaus Darilion:
Olle E. Johansson schrieb:
Yes, exactly. As you say, the only thing we can be sure of is that we
have no idea about which URI schemes that will be used in the future.
An internal registry of handlers would be a good thing.
/O
6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo:
Yes, should be generic as RFC 3261 which allows all kind of URIs Hi, does/will SR implement TEL URI properly? This
is: OpenSer/
Kamailio doesn't
support it (just a very basic support).
Also, some useful funtions would be:
- "is_sip?": returns true if RURI has SIP URI.
- "is_sips?": returns true if RURI has SIPS URI.
- "is_sip_ips?": returns true if RURI has SIP or SIPS URI.
- "is_tel?": returns true if RURI has TEL URI.
At the same time, we
could implement support for other URI's, like
XMPP since we have an xmpp gateway.
5586
days inactive
5588
days old
29 comments
7 participants
participants (7)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Jan Janak -
Klaus Darilion -
Martin Hoffmann -
Olle E. Johansson