hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
--- /usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr ---
the ACK i sent look like this:
--- Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0 ---
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
--- "6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com" ---
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Hi Kerker,
Perhaps there needs to be SRV records in the DNS server that manages iptel1.ipatl.se.
Below are example SRV records. If this is your first time working with SRV records, I strongly suggest reading some of the online doc that deals with them.
_sip._tcp.iptel1.ipatl.se. IN SRV 0 0 5060 sip.iptel1.ipatl.se. _sip._udp.iptel1.ipatl.se. IN SRV 0 0 5060 sip.iptel1.ipatl.se.
Regards, Norm
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
I'm not sure about the maddr parameter. doesn't it mean that the request should be forwarded to this IP regardsless of the domain? If yes, the DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it on the to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@gmail.com:
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it on the to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
-- Simon.
2006/7/7, Klaus Darilion klaus.mailinglists@pernau.at:
I'm not sure about the maddr parameter. doesn't it mean that the request should be forwarded to this IP regardsless of the domain? If yes, the DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: <sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr> From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
after a quick check, the answer is : no
this is a quick hack i've made as a workaround. feedback welcome :)
781,783c781,803 < if (set_dst_uri(_m, uri) < 0) { < LOG(L_ERR, "after_loose: Error while setting dst_uri\n"); < return RR_ERROR; ---
if( puri.maddr.s != NULL ){ str builturistr; char builturi[150]; memcpy( builturi, "sip:", 4 ); memcpy( builturi+4, puri.maddr.s+6, puri.maddr.len-6 ); builturi[4+puri.maddr.len-6] ='\0'; LOG( L_ERR, "MaddrURI is %p\n", builturi ); builturistr.s = builturi; builturistr.len = 4+puri.maddr.len-6; if (set_dst_uri(_m, &builturistr) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; } }else{ if (set_dst_uri(_m, uri) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; }
2006/7/28, Simon Morvan garphy@gmail.com:
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@gmail.com:
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it on the to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
-- Simon.
2006/7/7, Klaus Darilion klaus.mailinglists@pernau.at:
I'm not sure about the maddr parameter. doesn't it mean that the request should be forwarded to this IP regardsless of the domain? If yes, the DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: <sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr> From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
modified file : modules/rr/loose.c
2006/7/28, Simon Morvan garphy@gmail.com:
after a quick check, the answer is : no
this is a quick hack i've made as a workaround. feedback welcome :)
781,783c781,803 < if (set_dst_uri(_m, uri) < 0) { < LOG(L_ERR, "after_loose: Error while setting dst_uri\n");
< return RR_ERROR;
if( puri.maddr.s != NULL ){ str builturistr; char builturi[150]; memcpy( builturi, "sip:", 4 ); memcpy( builturi+4, puri.maddr.s+6, puri.maddr.len-6 ); builturi[4+puri.maddr.len-6] ='\0'; LOG( L_ERR, "MaddrURI is %p\n", builturi ); builturistr.s = builturi; builturistr.len = 4+puri.maddr.len-6; if (set_dst_uri(_m, &builturistr) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; } }else{ if (set_dst_uri(_m, uri) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; }
2006/7/28, Simon Morvan garphy@gmail.com:
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@gmail.com:
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it on the to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
-- Simon.
2006/7/7, Klaus Darilion klaus.mailinglists@pernau.at:
I'm not sure about the maddr parameter. doesn't it mean that the request should be forwarded to this IP regardsless of the domain? If yes, the DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
the record-route header received by the proxy on the other side (SNOM4S), inserts the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK to the incomming OK, it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se" /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p Route: <sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr> From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p To: sip:2307@ipatl.se;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd Content-Length: 0
as far as i understand, according the rfc 3263, the route-header may contain domain name that has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
sip:1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name recieved in the route header, and since that's a domain name, it's unresolvable, and so the ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Simon!
Please make a unified diff (cvs diff -u) and post it at the bugtracker on sourceforge: http://sourceforge.net/tracker/?group_id=139143&atid=743022
This way it can't get lost under thousands of emails.
regards klaus
Simon Morvan wrote:
modified file : modules/rr/loose.c
2006/7/28, Simon Morvan garphy@gmail.com:
after a quick check, the answer is : no
this is a quick hack i've made as a workaround. feedback welcome :)
781,783c781,803 < if (set_dst_uri(_m, uri) < 0) { < LOG(L_ERR, "after_loose: Error while setting dst_uri\n");
< return RR_ERROR;
if( puri.maddr.s != NULL ){ str builturistr; char builturi[150]; memcpy( builturi, "sip:", 4 ); memcpy( builturi+4, puri.maddr.s+6,
puri.maddr.len-6 );
builturi[4+puri.maddr.len-6] ='\0'; LOG( L_ERR, "MaddrURI is %p\n", builturi ); builturistr.s = builturi; builturistr.len = 4+puri.maddr.len-6; if (set_dst_uri(_m, &builturistr) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; } }else{ if (set_dst_uri(_m, uri) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; }
2006/7/28, Simon Morvan garphy@gmail.com:
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@gmail.com:
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it
on the
to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
-- Simon.
2006/7/7, Klaus Darilion klaus.mailinglists@pernau.at:
I'm not sure about the maddr parameter. doesn't it mean that the
request
should be forwarded to this IP regardsless of the domain? If
yes, the
DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote:
hi i recently bounced into this problem, and i'm not sure here. i'm running the openser-devel, with the cacheless db_mode=3.
(works fine btw)
the record-route header received by the proxy on the other
side (SNOM4S), inserts
the domain name (iptel1.ipatl.se) and not the hostname
(sip.iptel1.ipatl.se) in the
record-route header, and uses the maddr=<ip_of_server> with
the actual server IP address.
now, when my client (behind the OpenSER) replies with an ACK
to the incomming OK,
it uses the Route-header recieved in the RR-header, and sends
the ACK to OpenSER. i
then get the following errors in OpenSER.
/usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not
resolve hostname: "iptel1.ipatl.se"
/usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name
in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
the ACK i sent look like this:
Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 Via: SIP/2.0/UDP
172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport
Route: <sip:172.28.248.10;lr=on;ftag=li9buf1i4p> Route:
<sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr>
From: "Snom 2652" <sip:2652@ipatl.se>;tag=li9buf1i4p To: <sip:2307@ipatl.se>;tag=hvseiz7kgb Call-ID: 3c269d83900b-xj3ild14y880@snom360 CSeq: 1 ACK Max-Forwards: 70 Contact: <sip:2652@172.28.248.52:2051;line=cp4a7ljd> Content-Length: 0
as far as i understand, according the rfc 3263, the
route-header may contain domain name that
has to be resolved using SRV.
"6 Constructing SIP URIs
In many cases, an element needs to construct a SIP URI for
inclusion
in a Contact header in a REGISTER, or in a Record-Route
header in an
INVITE. According to RFC 3261 [1], these URIs have to have
the
property that they resolve to the specific element that
inserted
them. However, if they are constructed with just an IP
address, for
example:
sip:1.2.3.4
then should the element fail, there is no way to route the
request or
response through a backup.
SRV provides a way to fix this. Instead of using an IP
address, a
domain name that resolves to an SRV record can be used:
sip:server23.provider.com"
now, OpenSER only asks DNS for an A record of the name
recieved in the route header,
and since that's a domain name, it's unresolvable, and so the
ACK is never sent.
any hints or clues?
best regards, /Staffan Kerker
-- Staffan Kerker Saab Communications, Växjö p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
did that
2006/7/31, Klaus Darilion klaus.mailinglists@pernau.at:
Hi Simon!
Please make a unified diff (cvs diff -u) and post it at the bugtracker on sourceforge: http://sourceforge.net/tracker/?group_id=139143&atid=743022
This way it can't get lost under thousands of emails.
regards klaus
Simon Morvan wrote:
modified file : modules/rr/loose.c
2006/7/28, Simon Morvan garphy@gmail.com:
after a quick check, the answer is : no
this is a quick hack i've made as a workaround. feedback welcome :)
781,783c781,803 < if (set_dst_uri(_m, uri) < 0) { < LOG(L_ERR, "after_loose: Error while setting dst_uri\n");
< return RR_ERROR;
if( puri.maddr.s != NULL ){ str builturistr; char builturi[150]; memcpy( builturi, "sip:", 4 ); memcpy( builturi+4, puri.maddr.s+6,
puri.maddr.len-6 );
builturi[4+puri.maddr.len-6] ='\0'; LOG( L_ERR, "MaddrURI is %p\n", builturi ); builturistr.s = builturi; builturistr.len = 4+puri.maddr.len-6; if (set_dst_uri(_m, &builturistr) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; } }else{ if (set_dst_uri(_m, uri) < 0) { LOG(L_ERR, "after_loose: Error while
setting dst_uri\n");
return RR_ERROR; }
2006/7/28, Simon Morvan garphy@gmail.com:
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@gmail.com:
As Daniel said on the ml thread :
it makes sense, we will analyze the implications and include it
on the
to-do list.
Cheers, Daniel
Has it been included in the developpement branch yet ?
-- Simon.
2006/7/7, Klaus Darilion klaus.mailinglists@pernau.at:
I'm not sure about the maddr parameter. doesn't it mean that the
request
should be forwarded to this IP regardsless of the domain? If
yes, the
DNS lookup can be skipped.
regards klaus
Kerker Staffan wrote: > hi > i recently bounced into this problem, and i'm not sure here. > i'm running the openser-devel, with the cacheless db_mode=3.
(works fine btw)
> > the record-route header received by the proxy on the other
side (SNOM4S), inserts
> the domain name (iptel1.ipatl.se) and not the hostname
(sip.iptel1.ipatl.se) in the
> record-route header, and uses the maddr=<ip_of_server> with
the actual server IP address.
> > now, when my client (behind the OpenSER) replies with an ACK
to the incomming OK,
> it uses the Route-header recieved in the RR-header, and sends
the ACK to OpenSER. i
> then get the following errors in OpenSER. > > --- > /usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not
resolve hostname: "iptel1.ipatl.se"
> /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name
in URI sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr
> --- > > the ACK i sent look like this: > > --- > Request-Line: ACK sip:2307@iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0 > Via: SIP/2.0/UDP
172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport
> Route: sip:172.28.248.10;lr=on;ftag=li9buf1i4p > Route:
sip:4ffec4ce755c218a72228c6643cb3b6b@iptel1.ipatl.se:5060;maddr= 172.28.248.66;transport=udp;lr
> From: "Snom 2652" sip:2652@ipatl.se;tag=li9buf1i4p > To: sip:2307@ipatl.se;tag=hvseiz7kgb > Call-ID: 3c269d83900b-xj3ild14y880@snom360 > CSeq: 1 ACK > Max-Forwards: 70 > Contact: sip:2652@172.28.248.52:2051;line=cp4a7ljd > Content-Length: 0 > --- > > as far as i understand, according the rfc 3263, the
route-header may contain domain name that
> has to be resolved using SRV. > > --- > "6 Constructing SIP URIs > > In many cases, an element needs to construct a SIP URI for
inclusion
> in a Contact header in a REGISTER, or in a Record-Route
header in an
> INVITE. According to RFC 3261 [1], these URIs have to have
the
> property that they resolve to the specific element that
inserted
> them. However, if they are constructed with just an IP
address, for
> example: > > sip:1.2.3.4 > > then should the element fail, there is no way to route the
request or
> response through a backup. > > SRV provides a way to fix this. Instead of using an IP
address, a
> domain name that resolves to an SRV record can be used: > > sip:server23.provider.com" > --- > > now, OpenSER only asks DNS for an A record of the name
recieved in the route header,
> and since that's a domain name, it's unresolvable, and so the
ACK is never sent.
> > any hints or clues? > > best regards, > /Staffan Kerker > > > -- > Staffan Kerker > Saab Communications, Växjö > p. +46 470 42185 > c. +46 705 391365 > m. staffan.kerker@saabgroup.com > > > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users