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 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
2009/8/6 Alex Balashov abalashov@evaristesys.com:
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?
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
Hello,
On 06.08.2009 10:31 Uhr, Iñaki Baz Castillo wrote:
2009/8/6 Alex Balashov abalashov@evaristesys.com:
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?
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
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
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
On 06.08.2009 10:43 Uhr, Martin Hoffmann wrote:
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
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_transfor...
Cheers, Daniel
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2009/8/6 Martin Hoffmann martin.hoffmann@telio.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.
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
Olle E. Johansson schrieb:
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.
Yes, should be generic as RFC 3261 which allows all kind of URIs
klaus
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castilloibc@aliax.net wrote:
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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".
Why not?
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
Jan.
2009/8/6 Jan Janak jan@ryngle.com:
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castilloibc@aliax.net wrote:
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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".
Why not?
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
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 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
2009/8/6 Martin Hoffmann martin.hoffmann@telio.ch:
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.
Ok, but for sure that's not the purpose of a SIP proxy ;)
On Thu, Aug 6, 2009 at 3:47 PM, Iñaki Baz Castilloibc@aliax.net wrote:
2009/8/6 Martin Hoffmann martin.hoffmann@telio.ch:
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.
Ok, but for sure that's not the purpose of a SIP proxy ;)
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.
6 aug 2009 kl. 15.24 skrev Iñaki Baz Castillo:
2009/8/6 Jan Janak jan@ryngle.com:
On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castilloibc@aliax.net wrote:
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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".
Why not?
AFAIK the only URI's to implement wouuld be:
- SIP
- SIPS
- TEL
- URN
Why URN yes and HTTP not?
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.
/O
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
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???
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).
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.
ops, I didn't read about it.
Iñaki Baz Castillo schrieb:
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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
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
6 aug 2009 kl. 14.42 skrev Iñaki Baz Castillo:
2009/8/6 Klaus Darilion klaus.mailinglists@pernau.at:
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
You're forgetting
- IM - XMPP - PRES
/O
2009/8/6 Olle E. Johansson oej@edvina.net:
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?
6 aug 2009 kl. 18.51 skrev Iñaki Baz Castillo:
2009/8/6 Olle E. Johansson oej@edvina.net:
You're forgetting
- IM
IM: Hyper exotic concept made in IETF which absolutely nobody cares and nobody implements.
Well, I spent a few hours with at least one person that implements it at IETF. It's coming.
- PRES
Idem.
I can't say much about that.
- XMPP
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?
/O
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
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?
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?
6 aug 2009 kl. 20.24 skrev Iñaki Baz Castillo:
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
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?
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
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.
I strongly prefer to improve the SIP high presence including XCAP more than interoperating with other protocols. ;)
6 aug 2009 kl. 20.55 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.
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
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 ;-)
ok, I prefer to fix SIP/SIMPLE interoperability *before* implementing interoperability between SIP and XMPP ;)
Iñaki Baz Castillo schrieb:
El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió:
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?
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
2009/8/7 Klaus Darilion klaus.mailinglists@pernau.at:
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?
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 :(
2009/8/7 Iñaki Baz Castillo ibc@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 ^^^^^^^^^^^^^^
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
:)
6 aug 2009 kl. 14.24 skrev Klaus Darilion:
Olle E. Johansson schrieb:
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.
Yes, should be generic as RFC 3261 which allows all kind of URIs
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Jan Janak -
Klaus Darilion -
Martin Hoffmann -
Olle E. Johansson