Hi!
I just tried if openser can handle a service URN in the request URI (e.g. urn:service:sos which is used for emergency calls (refer to IETF ECRIT WG)).
Do it stateless with forward() works fine. Doing it statefull with tm module and t_relay() fails:
DBG:tm:t_newtran: transaction on entrance=(nil)
DBG:core:parse_headers: flags=ffffffffffffffff
DBG:core:parse_headers: flags=78
DBG:tm:t_lookup_request: start searching: hash=20823, isACK=0
DBG:tm:matching_3261: RFC3261 transaction matching failed
DBG:tm:t_lookup_request: no transaction found
ERROR:core:parse_uri: bad uri, state 0 parsed: urn: (4) / urn:service:sos (15) ERROR:core:parse_sip_msg_uri: bad uri urn:service:sos
DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing r-uri'
ERROR:tm:new_t: uri invalid
ERROR:tm:t_newtran: new_t failed
I wonder, is it really necessary for the tm module to understand the syntax of the RURI? Of course it is necessary if routing is done based on the RURI. But if DURI is set, or t_relay("udp:1.2.3.4:5060") is used, then I think it should work with any uri scheme in RURI.
regards klaus
Hi Klaus,
And in your case, destination uri or t_relay() param were set?
Regards, Bogdan
Klaus Darilion wrote:
Hi!
I just tried if openser can handle a service URN in the request URI (e.g. urn:service:sos which is used for emergency calls (refer to IETF ECRIT WG)).
Do it stateless with forward() works fine. Doing it statefull with tm module and t_relay() fails:
DBG:tm:t_newtran: transaction on entrance=(nil)
DBG:core:parse_headers: flags=ffffffffffffffff
DBG:core:parse_headers: flags=78
DBG:tm:t_lookup_request: start searching: hash=20823, isACK=0
DBG:tm:matching_3261: RFC3261 transaction matching failed
DBG:tm:t_lookup_request: no transaction found
ERROR:core:parse_uri: bad uri, state 0 parsed: urn: (4) / urn:service:sos (15) ERROR:core:parse_sip_msg_uri: bad uri urn:service:sos
DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing r-uri'
ERROR:tm:new_t: uri invalid
ERROR:tm:t_newtran: new_t failed
I wonder, is it really necessary for the tm module to understand the syntax of the RURI? Of course it is necessary if routing is done based on the RURI. But if DURI is set, or t_relay("udp:1.2.3.4:5060") is used, then I think it should work with any uri scheme in RURI.
regards klaus
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi Klaus,
And in your case, destination uri or t_relay() param were set?
In my case I tried forwarding with t_relay("udp:1.2.3.4:5060") which failed.
regards klaus
Regards, Bogdan
Klaus Darilion wrote:
Hi!
I just tried if openser can handle a service URN in the request URI (e.g. urn:service:sos which is used for emergency calls (refer to IETF ECRIT WG)).
Do it stateless with forward() works fine. Doing it statefull with tm module and t_relay() fails:
DBG:tm:t_newtran: transaction on entrance=(nil) DBG:core:parse_headers: flags=ffffffffffffffff DBG:core:parse_headers: flags=78 DBG:tm:t_lookup_request: start searching: hash=20823, isACK=0 DBG:tm:matching_3261: RFC3261 transaction matching failed DBG:tm:t_lookup_request: no transaction found ERROR:core:parse_uri: bad uri, state 0 parsed: urn: (4) / urn:service:sos (15) ERROR:core:parse_sip_msg_uri: bad uri urn:service:sos DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing r-uri' ERROR:tm:new_t: uri invalid ERROR:tm:t_newtran: new_t failed
I wonder, is it really necessary for the tm module to understand the syntax of the RURI? Of course it is necessary if routing is done based on the RURI. But if DURI is set, or t_relay("udp:1.2.3.4:5060") is used, then I think it should work with any uri scheme in RURI.
regards klaus
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Klaus Darilion