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.comsip%3AUnknown@voip1.bravotelecom.com
;tag=as366a0ba0
To: sip:34249@193.110.78.12:8484 Call-ID: 322db75c71be4ba45a61c7666b93e6be@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@69.70.173.195
;tag=as6075df60
Call-ID: 4d784fa972c4e9c9795032417f46cb26@voip1.bravotelecom.com To: <sip:34249@192.168.2.170 sip%3A34249@192.168.2.170> CSeq: 102 CANCEL Max-Forwards: 70 asterisk Content-Length: 0
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@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@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@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
El Miércoles, 4 de Marzo de 2009, Alex Balashov escribió:
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...".
Ernest Mavrel wrote:
El Miércoles, 4 de Marzo de 2009, Alex Balashov escribió:
/ 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...".
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
12 aug 2009 kl. 11.20 skrev Alex Balashov:
Ernest Mavrel wrote:
El Miércoles, 4 de Marzo de 2009, Alex Balashov escribió:
/ 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...".
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.
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.
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
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
12 aug 2009 kl. 11.34 skrev Alex Balashov:
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.
...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
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.
12 aug 2009 kl. 11.41 skrev Alex Balashov:
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.
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
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...).
12 aug 2009 kl. 12.29 skrev Iñaki Baz Castillo:
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
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.
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
Iñaki Baz Castillo wrote:
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.
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.
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 wrote:
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.
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.h...
12 aug 2009 kl. 12.45 skrev Alex Balashov:
Iñaki Baz Castillo wrote:
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.
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.
The power of Open Source! :-)
/O
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.
Ernest Mavrel wrote:
Alex Balashov pravi:
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.
My provider have NexTone SBC, if anyone have experience with.////
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 -
alexander merkulov -
Ernest Mavrel -
Iñaki Baz Castillo -
Olle E. Johansson -
Ovidiu Sas