4 Mar
2009
4 Mar
'09
10:20 p.m.
here is correct reqwest and reqwest via kamailio
is there any way to rewrite To: field in kamailio
because now it nto work
correct reqwest(asterisk)
RECEIVING FROM: 69.70.173.195:5060
CANCEL sip:34249@193.110.78.12:8484 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.180:5060;branch=z9hG4bK4c97bd4a
From: "Unknown"
<sip:Unknown@voip1.bravotelecom.com<sip%3AUnknown@voip1.bravotelecom.com>
;tag=as366a0ba0
To:
<sip:34249@193.110.78.12:8484>
Call-ID: 322db75c71be4ba45a61c7666b93e6be(a)voip1.bravotelecom.com
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
incorrect reqwest(multi-homed kamailio, asterisk originate to internal eth)
RECEIVING FROM: 69.70.173.195:5060
CANCEL sip:34249@193.110.78.12:8484 SIP/2.0
Via: SIP/2.0/UDP 69.70.173.195;branch=z9hG4bK1b1b.3c42cea6.0
From: "Unknown" <sip:Unknown@69.70.173.195
<sip%3AUnknown(a)69.70.173.195>
;tag=as6075df60
Call-ID:
4d784fa972c4e9c9795032417f46cb26(a)voip1.bravotelecom.com
To: <sip:34249@192.168.2.170 <sip%3A34249(a)192.168.2.170>>
CSeq: 102 CANCEL
Max-Forwards: 70
asterisk
Content-Length: 0
--
Merkulov Alexander
4 Mar
4 Mar
10:57 p.m.
Take a look at textops module:
http://www.kamailio.net/docs/modules/1.5.x/textops.html#id2467719
Regards,
Ovidiu Sas
On Wed, Mar 4, 2009 at 4:20 PM, alexander merkulov <arheops(a)gmail.com> wrote:
here is correct reqwest and reqwest via kamailio
is there any way to rewrite To: field in kamailio
because now it nto work
correct reqwest(asterisk)
RECEIVING FROM: 69.70.173.195:5060
CANCEL sip:34249@193.110.78.12:8484 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.180:5060;branch=z9hG4bK4c97bd4a
From: "Unknown" <sip:Unknown@voip1.bravotelecom.com>;tag=as366a0ba0
To: <sip:34249@193.110.78.12:8484>
Call-ID: 322db75c71be4ba45a61c7666b93e6be(a)voip1.bravotelecom.com
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
incorrect reqwest(multi-homed kamailio, asterisk originate to internal eth)
RECEIVING FROM: 69.70.173.195:5060
CANCEL sip:34249@193.110.78.12:8484 SIP/2.0
Via: SIP/2.0/UDP 69.70.173.195;branch=z9hG4bK1b1b.3c42cea6.0
From: "Unknown" <sip:Unknown@69.70.173.195>;tag=as6075df60
Call-ID: 4d784fa972c4e9c9795032417f46cb26(a)voip1.bravotelecom.com
To: <sip:34249@192.168.2.170>
CSeq: 102 CANCEL
Max-Forwards: 70
asterisk
Content-Length: 0
--
Merkulov Alexander
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
11:18 p.m.
Iñaki Baz Castillo wrote:
El Miércoles, 4 de Marzo de 2009, alexander merkulov
escribió:
That was the question I was going to ask. It violates proxy behaviour.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
is there any way to rewrite To: field in
kamailio
because now it nto work
Could I know why you need to rewrite To header?
A proxy MUST NOT do it. 
11:20 p.m.
El Miércoles, 4 de Marzo de 2009, Alex Balashov escribió:
Iñaki Baz Castillo wrote:
Unfortunatelly a typical pathetic reply from a SIP carrier is "sorry but the
To is different than the request URI, so it cannot work...".
--
Iñaki Baz Castillo
El Miércoles, 4 de Marzo de 2009, alexander
merkulov escribió:
That was the question I was going to ask. It violates proxy behaviour. is there any way to rewrite To: field in
kamailio
because now it nto work
Could I know why you need to rewrite To header?
A proxy MUST NOT do it. 
11:20 a.m.
Ernest Mavrel wrote:
El Miércoles, 4 de Marzo de 2009, Alex Balashov
escribió:
This is not a "pathetic" reply. This is an RFC-compliant reply. A user
agent reasonably expects the To and From header values to match those in
the initial request.
Why do you need to rewrite the To URI? The RFC says you shouldn't route
on it, but on the Request URI. If you need to rewrite the To URI,
chances are you are doing something wrong or there is a better way to
accomplish the goal.
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
/ Iñaki Baz Castillo wrote:
/>/ > El
Miércoles, 4 de Marzo de 2009, alexander merkulov escribió:
/>/ >> is there any way to rewrite To: field in kamailio
/>/ >> because now it nto work
/>/ >
/>/ > Could I know why you need to rewrite To header?
/>/ > A proxy MUST NOT do it.
/>/
/>/ That was the question I was going to ask. It violates proxy behaviour.
/
Unfortunatelly a typical pathetic reply from a SIP carrier is "sorry but the
To is different than the request URI, so it cannot work...". 
11:25 a.m.
12 aug 2009 kl. 11.20 skrev Alex Balashov:
Ernest Mavrel wrote:
No, there's an update to RFC3261 which actually allows changing the
From: and To: headers. It's something needed during transfers or other
cases where you need an caller ID update. Check RFC 4916 for more
information.
El Miércoles, 4 de Marzo de 2009, Alex Balashov
escribió:
This is not a "pathetic" reply. This is an RFC-compliant reply. A
user agent reasonably expects the To and From header values to match
those in the initial request. / Iñaki Baz Castillo wrote:
/>/ > El
Miércoles, 4 de Marzo de 2009, alexander merkulov escribió:
/>/ >> is there any way to rewrite To: field in kamailio
/>/ >> because now it nto work
/>/ >
/>/ > Could I know why you need to rewrite To header?
/>/ > A proxy MUST NOT do it.
/>/
/>/ That was the question I was going to ask. It violates proxy
behaviour.
/
Unfortunatelly a typical pathetic reply from a SIP carrier is
"sorry but the To is different than the request URI, so it cannot
work...".
Why do you need to rewrite the To URI? The RFC says you shouldn't
route on it, but on the Request URI. If you need to rewrite the To
URI, chances are you are doing something wrong or there is a better
way to accomplish the goal.
In some cases, where you have on registration and 10 DIDs, the To:
header is the only place where you actually will find the original
called number on the PSTN side, to separate the different DID's. The
request URI will always be the contact URI provided in the
registration. Unless you use the hack they came up with for SIP-
connect, where you register a contact, but don't use that in the R-URI
for the calls based on the registration.
Cheers,
/O
11:34 a.m.
Olle E. Johansson wrote:
No, there's an update to RFC3261 which actually
allows changing the
From: and To: headers. It's something needed during transfers or other
cases where you need an caller ID update. Check RFC 4916 for more
information.
Yes, but as I understand it, "This solution uses the UPDATE method for
the request, or in some circumstances the re-INVITE method."
This is not the same as simply rewriting the To URI on request
processing at the proxy, which is what the poster is asking about.
Or am I missing something?
In some cases, where you have on registration and 10
DIDs, the To:
header is the only place where you actually will find the original
called number on the PSTN side, to separate the different DID's. The
request URI will always be the contact URI provided in the registration.
Unless you use the hack they came up with for SIP-connect, where you
register a contact, but don't use that in the R-URI for the calls based
on the registration.
Conveying the dialed number via overriding the user part of the contact
binding is an accepted and mainstream way of sending DNIS to the
registrant UAC among providers of SIP origination, although I agree that
ignoring the Contact URI provided in the client's REGISTER request is
very much not RFC compliant, much like far-end NAT traversal techniques. :)
It's kind of a nasty situation, actually, because some endpoints will
gladly accept an incoming Request URI that differs from the Contact URI
with which it registered, such as Asterisk. But other devices, like
various ATAs and phones, irrevocably expect the user part of the Request
URI to match up 100% with what was submitted, and will simply reject the
call (404 Not Found) if that's the case.
For the SIP registrar implementations I've done, I've usually had to
give the customer a flag to toggle that controls whether this override
behaviour is done. It is set depending on what kind of device is the
endpoint.
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
11:38 a.m.
New subject: [Kamailio-Users] Request uri vs registered contact
12 aug 2009 kl. 11.34 skrev Alex Balashov:
...and I've seen implementation who refuse to accept the registered
contact as a request URI...
There's some vague security thinking behind a device who doesn't
accept any r-URI from, but only the registered contact. Is some cases,
the contact indicates a line or something in the device, so it needs
the full contact to be able to provide the user with the proper
interface reaction for the incoming call.
/O
In some cases, where you have on registration and
10 DIDs, the To:
header is the only place where you actually will find the original
called number on the PSTN side, to separate the different DID's.
The request URI will always be the contact URI provided in the
registration. Unless you use the hack they came up with for SIP-
connect, where you register a contact, but don't use that in the R-
URI for the calls based on the registration.
Conveying the dialed number via overriding the user part of the
contact binding is an accepted and mainstream way of sending DNIS to
the registrant UAC among providers of SIP origination, although I
agree that ignoring the Contact URI provided in the client's
REGISTER request is very much not RFC compliant, much like far-end
NAT traversal techniques. :)
It's kind of a nasty situation, actually, because some endpoints
will gladly accept an incoming Request URI that differs from the
Contact URI with which it registered, such as Asterisk. But other
devices, like various ATAs and phones, irrevocably expect the user
part of the Request URI to match up 100% with what was submitted,
and will simply reject the call (404 Not Found) if that's the case.
For the SIP registrar implementations I've done, I've usually had to
give the customer a flag to toggle that controls whether this
override behaviour is done. It is set depending on what kind of
device is the endpoint.
11:41 a.m.
New subject: [Kamailio-Users] Request uri vs registered contact
Olle E. Johansson wrote:
...and I've seen implementation who refuse to
accept the registered
contact as a request URI...
There's some vague security thinking behind a device who doesn't accept
any r-URI from, but only the registered contact. Is some cases, the
contact indicates a line or something in the device, so it needs the
full contact to be able to provide the user with the proper interface
reaction for the incoming call.
Yep. It's not stupid; the logic is quite clear, and the behaviour is
as intended. It just poses a problem for trunking and/or multiple DIDs
where the device is expected to potentially route a call differently
based on the number used to reach it.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
11:45 a.m.
New subject: [Kamailio-Users] Request uri vs registered contact
12 aug 2009 kl. 11.41 skrev Alex Balashov:
Olle E. Johansson wrote:
I did not say it was stupid, but it's not related to security...
Anyway, there's some work in the IETF to handle the register for
multiple DID's, since the way it's used now clearly violates what's in
the RFCs and there is an obvious need to register for "SIP trunks".
/O
...and I've seen implementation who refuse to
accept the registered
contact as a request URI...
There's some vague security thinking behind a device who doesn't
accept any r-URI from, but only the registered contact. Is some
cases, the contact indicates a line or something in the device, so
it needs the full contact to be able to provide the user with the
proper interface reaction for the incoming call.
Yep. It's not stupid; the logic is quite clear, and the behaviour
is as intended. It just poses a problem for trunking and/or
multiple DIDs where the device is expected to potentially route a
call differently based on the number used to reach it.
12:29 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
El Miércoles, 12 de Agosto de 2009, Olle E. Johansson escribió:
Anyway, there's some work in the IETF to handle
the register for
multiple DID's, since the way it's used now clearly violates what's in
the RFCs and there is an obvious need to register for "SIP trunks".
I implemented this in an "ellegant" way:
- The SIP trunk (Asterisk?) registers with Contact "s@IP" (or any contact).
- It has associated 3 PSTN numbers in the proxy/registrar.
- When the proxy receives a call for one of these 3 numbers it changes the
RURI according to the location of the client (lookup("location")) and adds a
header whose value is the dialed PSTN number in E164 format:
P-Dialed-Number: +34987654321
So:
- "To" remains unchanged.
- RURI arriving to the client matches its registration's Contact.
- The client must inspect a custom header to know the real destination number
of the call.
However, I've read some RFC with a similar solution (I think it uses "P-
Called-Party" header, but later the complex "History" header appeared
and...).
--
Iñaki Baz Castillo <ibc(a)aliax.net>
12:34 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
12 aug 2009 kl. 12.29 skrev Iñaki Baz Castillo:
El Miércoles, 12 de Agosto de 2009, Olle E. Johansson
escribió:
You could have used Remote-party-id with party=called as well.
In fact, if you start testing various equipment you realize that you
have to deliver this information in multiple ways.
Anyway, there's some work in the IETF to
handle the register for
multiple DID's, since the way it's used now clearly violates what's
in
the RFCs and there is an obvious need to register for "SIP trunks".
I implemented this in an "ellegant" way:
- The SIP trunk (Asterisk?) registers with Contact "s@IP" (or any
contact).
- It has associated 3 PSTN numbers in the proxy/registrar.
- When the proxy receives a call for one of these 3 numbers it
changes the
RURI according to the location of the client (lookup("location"))
and adds a
header whose value is the dialed PSTN number in E164 format:
P-Dialed-Number: +34987654321
So:
- "To" remains unchanged.
- RURI arriving to the client matches its registration's Contact.
- The client must inspect a custom header to know the real
destination number
of the call.
However, I've read some RFC with a similar solution (I think it uses
"P-
Called-Party" header, but later the complex "History" header
appeared and...).
Yes, in the future a PSTN gateway propably should add sip-history with
this information.
The draft for the update doesn't mention gateways or b2bua's much, so
it still needs feedback I guess.
/O
12:45 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
Iñaki Baz Castillo wrote:
El Miércoles, 12 de Agosto de 2009, Olle E. Johansson
escribió:
That is quite elegant, and easy to get around in the Asterisk dial plan
so that routing can still happen on "extension," where "extension" is
the dialed number:
[generic-incoming]
exten => _.,1,Set(dialed=${SIP_HEADER(P-Dialed-Number)})
exten => _.,n,Goto(incoming-route,${dialed},1)
But in other endpoints it would be quite hard or impossible.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Anyway, there's some work in the IETF to
handle the register for
multiple DID's, since the way it's used now clearly violates what's in
the RFCs and there is an obvious need to register for "SIP trunks".
I implemented this in an "ellegant" way:
- The SIP trunk (Asterisk?) registers with Contact "s@IP" (or any contact).
- It has associated 3 PSTN numbers in the proxy/registrar.
- When the proxy receives a call for one of these 3 numbers it changes the
RURI according to the location of the client (lookup("location")) and adds a
header whose value is the dialed PSTN number in E164 format:
P-Dialed-Number: +34987654321
So:
- "To" remains unchanged.
- RURI arriving to the client matches its registration's Contact.
- The client must inspect a custom header to know the real destination number
of the call.
12:48 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
El Miércoles, 12 de Agosto de 2009, Alex Balashov escribió:
That is quite elegant, and easy to get around in the
Asterisk dial plan
so that routing can still happen on "extension," where "extension"
is
the dialed number:
[generic-incoming]
exten => _.,1,Set(dialed=${SIP_HEADER(P-Dialed-Number)})
exten => _.,n,Goto(incoming-route,${dialed},1)
But in other endpoints it would be quite hard or impossible.
Sure, that's why I told about some RFC's defining such a specification.
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
12:54 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
Iñaki Baz Castillo wrote:
El Miércoles, 12 de Agosto de 2009, Alex Balashov
escribió:
Bah, keeping track of all this stuff is way, way too hard. Let's all
switch to P2P2PSIP[1].
I know you said specifically not to refer you to it[2], but, alas.
[1] http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt
[2]
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-April/019182.…
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
That is quite elegant, and easy to get around in
the Asterisk dial plan
so that routing can still happen on "extension," where "extension"
is
the dialed number:
[generic-incoming]
exten => _.,1,Set(dialed=${SIP_HEADER(P-Dialed-Number)})
exten => _.,n,Goto(incoming-route,${dialed},1)
But in other endpoints it would be quite hard or impossible.
Sure, that's why I told about some RFC's defining such a specification.
12:48 p.m.
New subject: [Kamailio-Users] Request uri vs registered contact
12 aug 2009 kl. 12.45 skrev Alex Balashov:
Iñaki Baz Castillo wrote:
The power of Open Source! :-)
/O
El Miércoles, 12 de Agosto de 2009, Olle E.
Johansson escribió:
That is quite elegant, and easy to get around in the Asterisk dial
plan so that routing can still happen on "extension," where
"extension" is the dialed number:
[generic-incoming]
exten => _.,1,Set(dialed=${SIP_HEADER(P-Dialed-Number)})
exten => _.,n,Goto(incoming-route,${dialed},1)
But in other endpoints it would be quite hard or impossible. Anyway, there's some work in the IETF to
handle the register for
multiple DID's, since the way it's used now clearly violates
what's in
the RFCs and there is an obvious need to register for "SIP trunks".
I
implemented this in an "ellegant" way:
- The SIP trunk (Asterisk?) registers with Contact "s@IP" (or any
contact).
- It has associated 3 PSTN numbers in the proxy/registrar.
- When the proxy receives a call for one of these 3 numbers it
changes the RURI according to the location of the client
(lookup("location")) and adds a header whose value is the dialed
PSTN number in E164 format:
P-Dialed-Number: +34987654321
So:
- "To" remains unchanged.
- RURI arriving to the client matches its registration's Contact.
- The client must inspect a custom header to know the real
destination number of the call.
11:34 a.m.
Ernest Mavrel wrote:
I need to rewrite the To URI because of my provider.
He expected all
numbers in e.164 format. Unfortunately some users start calls in
international format, some in national. I changed R-URI, but provider
also check line "To" in header. So I need to change that line to.
That's strange. Unless your provider is routing on the To header, which
it should not be, it should be of purely cosmetic significance.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
11:42 a.m.
Ernest Mavrel wrote:
Alex Balashov pravi:
I have a customer with a Nextone, and they do not seem to care what
their users send in To. But I don't have any concrete experience with
them personally.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Ernest Mavrel wrote:
My provider have NexTone SBC, if anyone have experience with.//// I need to rewrite the To URI because of my
provider. He expected all
numbers in e.164 format. Unfortunately some users start calls in
international format, some in national. I changed R-URI, but provider
also check line "To" in header. So I need to change that line to.
That's strange. Unless your provider is routing on the To header,
which it should not be, it should be of purely cosmetic significance.
5365
days inactive
5526
days old
21 comments
6 participants
participants (6)
-
Alex Balashov -
alexander merkulov -
Ernest Mavrel -
Iñaki Baz Castillo -
Olle E. Johansson -
Ovidiu Sas