1 Aug
2016
1 Aug
'16
3:10 p.m.
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer so for
exaples customer1 send traffic to us with 1111 prefix, customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for examples if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
1 Aug
1 Aug
3:24 p.m.
Hello,
On 01/08/16 14:10, Laura wrote:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer so for
exaples customer1 send traffic to us with 1111 prefix, customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for examples if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
The From header URI in reply is not related to request URI (r-uri).
Kamailio has uac_replace_from() in the uac module that can be used to
update and restore From uri. Are you using it in the config for INVITE
request?
If you can provide an ngrep or pcap for such call, then it will be
useful to see what you are referring to and propose eventual fixes.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3:25 p.m.
Hi,
do you use "uac_replace_from" or "uac_replace_to" in your logic?
If not, it seems to me, that your supplier is messing around with the
SIP-Replies.
Thanks,
Carsten
2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net>et>:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer so for
exaples customer1 send traffic to us with 1111 prefix, customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for examples if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
10 Aug
10 Aug
1:27 p.m.
Sorry for delay on my reply..
I need to expalin better the situazione..
Customer1 Ip : 1.1.1.1
Kamailio1 ip : 2.2.2.2
Kamailio2 ip: 3.3.3.3
CiscoGW ip: 4.4.4.4
Kamailio1 is on USA for example
Kamailio2 is on Germany for example
Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO GW
SIP/TDM for PTSN termination
Customer1 is sending a call using his specific color 9999 to number
4912345678 and from sender 151512345678
U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
INVITE sip:*9999*4912345678@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
Max-Forwards: 70.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9999*4912345678@2.2.2.2>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.8.32.3.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 1.1.1.1.
t=0 0.
m=audio 15710 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
After that the Kamailio1 platform is checking the LCR and route it with
the color of its supplier (9053) to Kamailio2. Kamailio2 is a supplier
of Kamailio1
U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:*9053*4912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via:
SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9053*4912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 use its LCR and send the call to Cisco Gateway that use its
color and send the call on termination to TDM Switch.
Naturally Kamailio2 receive the replies from Cisco and send it back to
Kamailio1.
Here is the Session progress Kamailio1 receive from Kamailio2 that it
got from Cisco.
U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 183 Session Progress.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is the
color that use CISCO to terminate the call on TDM Switch
After some other messages Kamailio1 receive the 200 OK and send it back
to Customer1
Kamailio2 --> Kamailio1
U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 200 OK.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Kamailio1 --> Customer1
U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 56710 RTP/AVP 3 101.
c=IN IP4 51.254.158.37.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
So the real question is how to fix that on Kamailio ?..
We need to use always the original messages and data into sdp header
when we talk with other parts..
On our configuration we permit to transit that modified messages.. like
you can see Customer1 is getting back datas modified from CiscoGW.
Hope that will be more clear to you all..
Anyone can suggest us a way ?
Regards
Laura
Il 01/08/16 14:25, Carsten Bock ha scritto:
Hi,
do you use "uac_replace_from" or "uac_replace_to" in your logic?
If not, it seems to me, that your supplier is messing around with the
SIP-Replies.
Thanks,
Carsten
2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net
<mailto:red_dra@plugit.net>>:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM
modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer so for
exaples customer1 send traffic to us with 1111 prefix, customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for examples
if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com <mailto:carsten@ng-voice.com>
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:33 p.m.
Ciao Laura,
would be interesting to see the INVITE from kamailo2-->Cisco and see the
headers there, as well as the 180/200 from Cisco->kamailio2.
As Carsten said, probably Cisco is messing up From/To headers. The 9990
color is not present in any of the INVITEs you provided, so would be
nice to understand where is come from.
Cheers,
Daniel
On 08/10/2016 12:27 PM, Laura wrote:
Sorry for delay on my reply..
I need to expalin better the situazione..
Customer1 Ip : 1.1.1.1
Kamailio1 ip : 2.2.2.2
Kamailio2 ip: 3.3.3.3
CiscoGW ip: 4.4.4.4
Kamailio1 is on USA for example
Kamailio2 is on Germany for example
Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO GW
SIP/TDM for PTSN termination
Customer1 is sending a call using his specific color 9999 to number
4912345678 and from sender 151512345678
U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
INVITE sip:*9999*4912345678@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
Max-Forwards: 70.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9999*4912345678@2.2.2.2>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.8.32.3.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 1.1.1.1.
t=0 0.
m=audio 15710 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
After that the Kamailio1 platform is checking the LCR and route it
with the color of its supplier (9053) to Kamailio2. Kamailio2 is a
supplier of Kamailio1
U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:*9053*4912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via:
SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9053*4912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 use its LCR and send the call to Cisco Gateway that use its
color and send the call on termination to TDM Switch.
Naturally Kamailio2 receive the replies from Cisco and send it back to
Kamailio1.
Here is the Session progress Kamailio1 receive from Kamailio2 that it
got from Cisco.
U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 183 Session Progress.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is the
color that use CISCO to terminate the call on TDM Switch
After some other messages Kamailio1 receive the 200 OK and send it
back to Customer1
Kamailio2 --> Kamailio1
U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 200 OK.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Kamailio1 --> Customer1
U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 56710 RTP/AVP 3 101.
c=IN IP4 51.254.158.37.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
So the real question is how to fix that on Kamailio ?..
We need to use always the original messages and data into sdp header
when we talk with other parts..
On our configuration we permit to transit that modified messages..
like you can see Customer1 is getting back datas modified from CiscoGW.
Hope that will be more clear to you all..
Anyone can suggest us a way ?
Regards
Laura
Il 01/08/16 14:25, Carsten Bock ha scritto:
Hi,
do you use "uac_replace_from" or "uac_replace_to" in your logic?
If not, it seems to me, that your supplier is messing around with the
SIP-Replies.
Thanks,
Carsten
2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net
<mailto:red_dra@plugit.net>>:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM
modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer
so for
exaples customer1 send traffic to us with 1111 prefix, customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for
examples if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR
module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com <mailto:carsten@ng-voice.com>
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:35 p.m.
Ciao Daniel,
here the data you request..
Of course Kamailio2 use the color 9990 to send the call to CISCO Gw
because its a required.. so CISCO send back the call with 9990 to
Kamailio2 and it to Kamailio1 and after that to Customer..
What I espect was that CISCO replied 9990 to Kamailio2, Kama2 replied
9053 to Kamailio1 and Kamailio1 replied 9999 to Customer1.
Here the sip trace you request
Kamailio1 --> Kamailio2
U 2016/08/10 10:54:29.269917 2.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:90534912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:90534912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x.x.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 --> CISCO.. LCR need to use 9990 to send call to CISCO..
U 2016/08/10 10:54:29.301085 3.3.3.3:5060 -> 4.4.4.4:5060
INVITE sip:99904912345678@4.4.4.4 SIP/2.0.
Record-Route: <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0.
Via: SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 68.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x..
t=0 0.
m=audio 58242 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
CISCO ---> Kamailio2 180/200 messages
U 2016/08/10 10:54:29.361634 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
U 2016/08/10 10:54:39.486505 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
185.24.22
0.141:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Il 10/08/16 13:33, Daniel Grotti ha scritto:
Ciao Laura,
would be interesting to see the INVITE from kamailo2-->Cisco and see
the headers there, as well as the 180/200 from Cisco->kamailio2.
As Carsten said, probably Cisco is messing up From/To headers. The
9990 color is not present in any of the INVITEs you provided, so would
be nice to understand where is come from.
Cheers,
Daniel
On 08/10/2016 12:27 PM, Laura wrote:
Sorry for delay on my reply..
I need to expalin better the situazione..
Customer1 Ip : 1.1.1.1
Kamailio1 ip : 2.2.2.2
Kamailio2 ip: 3.3.3.3
CiscoGW ip: 4.4.4.4
Kamailio1 is on USA for example
Kamailio2 is on Germany for example
Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO GW
SIP/TDM for PTSN termination
Customer1 is sending a call using his specific color 9999 to number
4912345678 and from sender 151512345678
U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
INVITE sip:*9999*4912345678@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
Max-Forwards: 70.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9999*4912345678@2.2.2.2>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.8.32.3.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 1.1.1.1.
t=0 0.
m=audio 15710 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
After that the Kamailio1 platform is checking the LCR and route it
with the color of its supplier (9053) to Kamailio2. Kamailio2 is a
supplier of Kamailio1
U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:*9053*4912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via:
SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9053*4912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 use its LCR and send the call to Cisco Gateway that use its
color and send the call on termination to TDM Switch.
Naturally Kamailio2 receive the replies from Cisco and send it back
to Kamailio1.
Here is the Session progress Kamailio1 receive from Kamailio2 that it
got from Cisco.
U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 183 Session Progress.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is the
color that use CISCO to terminate the call on TDM Switch
After some other messages Kamailio1 receive the 200 OK and send it
back to Customer1
Kamailio2 --> Kamailio1
U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 200 OK.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Kamailio1 --> Customer1
U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 56710 RTP/AVP 3 101.
c=IN IP4 51.254.158.37.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
So the real question is how to fix that on Kamailio ?..
We need to use always the original messages and data into sdp header
when we talk with other parts..
On our configuration we permit to transit that modified messages..
like you can see Customer1 is getting back datas modified from CiscoGW.
Hope that will be more clear to you all..
Anyone can suggest us a way ?
Regards
Laura
Il 01/08/16 14:25, Carsten Bock ha scritto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hi,
do you use "uac_replace_from" or "uac_replace_to" in your logic?
If not, it seems to me, that your supplier is messing around with
the SIP-Replies.
Thanks,
Carsten
2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net
<mailto:red_dra@plugit.net>>:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM
modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer
so for
exaples customer1 send traffic to us with 1111 prefix, customer2
send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for
examples if i
want to send the call to supplier1 i need to use tech prefix 1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us something
like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR
module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com <mailto:carsten@ng-voice.com>
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:34 p.m.
Hey,
are you using uac_replace_from() in your uplink leg (INVITEs) or are you
changing $fu directly ?
I think using uac_replace_from() and then using:
modparam("uac","restore_mode","auto")
should do the trick.
Daniel
rt Vienna, ATU64002206
On 08/10/2016 02:35 PM, Laura wrote:
Ciao Daniel,
here the data you request..
Of course Kamailio2 use the color 9990 to send the call to CISCO Gw
because its a required.. so CISCO send back the call with 9990 to
Kamailio2 and it to Kamailio1 and after that to Customer..
What I espect was that CISCO replied 9990 to Kamailio2, Kama2 replied
9053 to Kamailio1 and Kamailio1 replied 9999 to Customer1.
Here the sip trace you request
Kamailio1 --> Kamailio2
U 2016/08/10 10:54:29.269917 2.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:90534912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:90534912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x.x.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 --> CISCO.. LCR need to use 9990 to send call to CISCO..
U 2016/08/10 10:54:29.301085 3.3.3.3:5060 -> 4.4.4.4:5060
INVITE sip:99904912345678@4.4.4.4 SIP/2.0.
Record-Route: <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0.
Via: SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 68.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x..
t=0 0.
m=audio 58242 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
CISCO ---> Kamailio2 180/200 messages
U 2016/08/10 10:54:29.361634 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
U 2016/08/10 10:54:39.486505 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
185.24.22
0.141:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Il 10/08/16 13:33, Daniel Grotti ha scritto:
Ciao Laura,
would be interesting to see the INVITE from kamailo2-->Cisco and see
the headers there, as well as the 180/200 from Cisco->kamailio2.
As Carsten said, probably Cisco is messing up From/To headers. The
9990 color is not present in any of the INVITEs you provided, so
would be nice to understand where is come from.
Cheers,
Daniel
On 08/10/2016 12:27 PM, Laura wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Sorry for delay on my reply..
I need to expalin better the situazione..
Customer1 Ip : 1.1.1.1
Kamailio1 ip : 2.2.2.2
Kamailio2 ip: 3.3.3.3
CiscoGW ip: 4.4.4.4
Kamailio1 is on USA for example
Kamailio2 is on Germany for example
Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO GW
SIP/TDM for PTSN termination
Customer1 is sending a call using his specific color 9999 to number
4912345678 and from sender 151512345678
U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
INVITE sip:*9999*4912345678@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
Max-Forwards: 70.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9999*4912345678@2.2.2.2>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.8.32.3.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 1.1.1.1.
t=0 0.
m=audio 15710 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
After that the Kamailio1 platform is checking the LCR and route it
with the color of its supplier (9053) to Kamailio2. Kamailio2 is a
supplier of Kamailio1
U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:*9053*4912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via:
SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9053*4912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 use its LCR and send the call to Cisco Gateway that use
its color and send the call on termination to TDM Switch.
Naturally Kamailio2 receive the replies from Cisco and send it back
to Kamailio1.
Here is the Session progress Kamailio1 receive from Kamailio2 that
it got from Cisco.
U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 183 Session Progress.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is the
color that use CISCO to terminate the call on TDM Switch
After some other messages Kamailio1 receive the 200 OK and send it
back to Customer1
Kamailio2 --> Kamailio1
U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 200 OK.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Kamailio1 --> Customer1
U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 56710 RTP/AVP 3 101.
c=IN IP4 51.254.158.37.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
So the real question is how to fix that on Kamailio ?..
We need to use always the original messages and data into sdp header
when we talk with other parts..
On our configuration we permit to transit that modified messages..
like you can see Customer1 is getting back datas modified from CiscoGW.
Hope that will be more clear to you all..
Anyone can suggest us a way ?
Regards
Laura
Il 01/08/16 14:25, Carsten Bock ha scritto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hi,
do you use "uac_replace_from" or "uac_replace_to" in your logic?
If not, it seems to me, that your supplier is messing around with
the SIP-Replies.
Thanks,
Carsten
2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net
<mailto:red_dra@plugit.net>>:
Dear list,
i'm asking here a question about Kamailio config.
We are testing a wide area configuration of Kamailio over separates
countries and we are still facing with an issue.
We configured Kamailio 4.3.5 with dialog support over the TM
modules and
we use LCR module for menage ours LCRs rule set profiles.
For some technicals reasons we use tech prefix for our customer
so for
exaples customer1 send traffic to us with 1111 prefix,
customer2 send
traffic to us with 2222 and something similar..
Our supplier, of course, are using tech prefix too so for
examples if i
want to send the call to supplier1 i need to use tech prefix
1789 or
something similar..
The point is..
When customer1 is sending an invite to us.. it send us
something like
(Bangladesh mobile 8801xxx)
INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
Our Kamailio will reply with the Trying and then it goes to LCR
module
and match our supplier1 so it make a new invite like this
INVITE sip:17898801xxxxxx@supplier.ip
The problem come when supplier1 reply to us and we replies back to
customer1..
Customer1 view the From: field with the 17898801xxxxxx
numbers.. and
some of our customers don't like it.
We don't use anymore the topoh module becuase we found some
troubles
using it.. so..
Is there a way that we can use for fix this situation ?
Best regards.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com <mailto:carsten@ng-voice.com>
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
30 Aug
30 Aug
10:30 a.m.
Dear Daniel and list,
i tried to use and test the restore_mode --> auto and this is what will
fix my issue.
Now ,the problem i have is that on my kamailio.cfg i need to use a replace..
Inside the branch_route[MANAGE_BRANCH] i use an uac_replace_to("$ru");
Why this ?.. because i use tech prefix for all my customers... for
examples 1234+E164number (without + ofcourse).. So with that replace i
write the color inside my CDR over the TO field .. this is useful for
the billing engine.
With that command i receive on my log.. and of course the replace is not
working..
Aug 30 06:25:08 vm-itz-01 /usr/sbin/kamailio[6441]: ERROR: uac
[replace.c:761]: restore_uris_reply(): failed to find/parse FROM hdr
Aug 30 06:25:13 vm-itz-01 /usr/sbin/kamailio[6418]: ERROR: uac
[replace.c:273]: replace_uri(): decline FROM replacing in sequential
request in auto mode (has TO tag)
How can i resolve that ? any idea guys ?
Laura
Il 10/08/16 17:34, Daniel Grotti ha scritto:
Hey,
are you using uac_replace_from() in your uplink leg (INVITEs) or are
you changing $fu directly ?
I think using uac_replace_from() and then using:
modparam("uac","restore_mode","auto")
should do the trick.
Daniel
rt Vienna, ATU64002206
On 08/10/2016 02:35 PM, Laura wrote:
Ciao Daniel,
here the data you request..
Of course Kamailio2 use the color 9990 to send the call to CISCO Gw
because its a required.. so CISCO send back the call with 9990 to
Kamailio2 and it to Kamailio1 and after that to Customer..
What I espect was that CISCO replied 9990 to Kamailio2, Kama2 replied
9053 to Kamailio1 and Kamailio1 replied 9999 to Customer1.
Here the sip trace you request
Kamailio1 --> Kamailio2
U 2016/08/10 10:54:29.269917 2.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:90534912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:90534912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x.x.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 --> CISCO.. LCR need to use 9990 to send call to CISCO..
U 2016/08/10 10:54:29.301085 3.3.3.3:5060 -> 4.4.4.4:5060
INVITE sip:99904912345678@4.4.4.4 SIP/2.0.
Record-Route: <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0.
Via: SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 68.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 x.x.x.x..
t=0 0.
m=audio 58242 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
CISCO ---> Kamailio2 180/200 messages
U 2016/08/10 10:54:29.361634 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
U 2016/08/10 10:54:39.486505 4.4.4.4:5060 -> 3.3.3.3:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
185.24.22
0.141:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 18838 RTP/AVP 3 101.
c=IN IP4 83.147.65.249.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Il 10/08/16 13:33, Daniel Grotti ha scritto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Ciao Laura,
would be interesting to see the INVITE from kamailo2-->Cisco and see
the headers there, as well as the 180/200 from Cisco->kamailio2.
As Carsten said, probably Cisco is messing up From/To headers. The
9990 color is not present in any of the INVITEs you provided, so
would be nice to understand where is come from.
Cheers,
Daniel
On 08/10/2016 12:27 PM, Laura wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Sorry for delay on my reply..
I need to expalin better the situazione..
Customer1 Ip : 1.1.1.1
Kamailio1 ip : 2.2.2.2
Kamailio2 ip: 3.3.3.3
CiscoGW ip: 4.4.4.4
Kamailio1 is on USA for example
Kamailio2 is on Germany for example
Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO
GW SIP/TDM for PTSN termination
Customer1 is sending a call using his specific color 9999 to number
4912345678 and from sender 151512345678
U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
INVITE sip:*9999*4912345678@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
Max-Forwards: 70.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9999*4912345678@2.2.2.2>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.8.32.3.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 309.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 1.1.1.1.
t=0 0.
m=audio 15710 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
After that the Kamailio1 platform is checking the LCR and route it
with the color of its supplier (9053) to Kamailio2. Kamailio2 is a
supplier of Kamailio1
U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
INVITE sip:*9053*4912345678@3.3.3.3 SIP/2.0.
Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Via:
SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
Max-Forwards: 69.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9053*4912345678@3.3.3.3>.
Contact: <sip:151512345678@1.1.1.1:5060>.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Date: Wed, 10 Aug 2016 08:54:27 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=root 869935480 869935480 IN IP4 1.1.1.1.
s=Asterisk PBX 1.8.32.3.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 36398 RTP/AVP 3 18 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
Kamailio2 use its LCR and send the call to Cisco Gateway that use
its color and send the call on termination to TDM Switch.
Naturally Kamailio2 receive the replies from Cisco and send it back
to Kamailio1.
Here is the Session progress Kamailio1 receive from Kamailio2 that
it got from Cisco.
U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 183 Session Progress.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is
the color that use CISCO to terminate the call on TDM Switch
After some other messages Kamailio1 receive the 200 OK and send it
back to Customer1
Kamailio2 --> Kamailio1
U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
SIP/2.0 200 OK.
Via:
SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 251.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 83.147.127.247.
t=0 0.
m=audio 58240 RTP/AVP 3 101.
c=IN IP4 83.147.127.247.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
Kamailio1 --> Customer1
U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
From: "151512345678" <sip:151512345678@1.1.1.1>;tag=as7f0dee78.
To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F.
Date: Wed, 10 Aug 2016 08:54:29 GMT.
Call-ID: 406a307158b1016b3a9936cd476b3c89@1.1.1.1:5060.
CSeq: 102 INVITE.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
Supported: replaces.
Allow-Events: telephone-event.
Contact: <sip:99904912345678@4.4.4.4:5060>.
Record-Route:
<sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
Content-Type: application/sdp.
Content-Length: 249.
User-Agent: Fagians VOIP 2.4.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
s=SIP Call.
c=IN IP4 51.254.158.37.
t=0 0.
m=audio 56710 RTP/AVP 3 101.
c=IN IP4 51.254.158.37.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
So the real question is how to fix that on Kamailio ?..
We need to use always the original messages and data into sdp
header when we talk with other parts..
On our configuration we permit to transit that modified messages..
like you can see Customer1 is getting back datas modified from CiscoGW.
Hope that will be more clear to you all..
Anyone can suggest us a way ?
Regards
Laura
Il 01/08/16 14:25, Carsten Bock ha scritto:
> Hi,
>
> do you use "uac_replace_from" or "uac_replace_to" in your logic?
>
> If not, it seems to me, that your supplier is messing around with
> the SIP-Replies.
>
> Thanks,
> Carsten
>
> 2016-08-01 14:10 GMT+02:00 Laura <red_dra(a)plugit.net
> <mailto:red_dra@plugit.net>>:
>
> Dear list,
>
> i'm asking here a question about Kamailio config.
>
> We are testing a wide area configuration of Kamailio over
> separates
> countries and we are still facing with an issue.
>
> We configured Kamailio 4.3.5 with dialog support over the TM
> modules and
> we use LCR module for menage ours LCRs rule set profiles.
>
> For some technicals reasons we use tech prefix for our
> customer so for
> exaples customer1 send traffic to us with 1111 prefix,
> customer2 send
> traffic to us with 2222 and something similar..
>
> Our supplier, of course, are using tech prefix too so for
> examples if i
> want to send the call to supplier1 i need to use tech prefix
> 1789 or
> something similar..
>
> The point is..
>
>
> When customer1 is sending an invite to us.. it send us
> something like
> (Bangladesh mobile 8801xxx)
>
> INVITE sip:11118801xxxxxxx@aaa.bbb.ccc.ddd
>
> Our Kamailio will reply with the Trying and then it goes to
> LCR module
> and match our supplier1 so it make a new invite like this
>
> INVITE sip:17898801xxxxxx@supplier.ip
>
> The problem come when supplier1 reply to us and we replies back to
> customer1..
>
> Customer1 view the From: field with the 17898801xxxxxx
> numbers.. and
> some of our customers don't like it.
>
> We don't use anymore the topoh module becuase we found some
> troubles
> using it.. so..
>
> Is there a way that we can use for fix this situation ?
>
>
> Best regards.
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list
> sr-users(a)lists.sip-router.org
> <mailto:sr-users@lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> --
> Carsten Bock
> CEO (Geschäftsführer)
>
> ng-voice GmbH
> Millerntorplatz 1
> 20359 Hamburg / Germany
>
> http://www.ng-voice.com
> mailto:carsten@ng-voice.com <mailto:carsten@ng-voice.com>
>
> Office +49 40 5247593-40
> Fax +49 40 5247593-99
>
> Sitz der Gesellschaft: Hamburg
> Registergericht: Amtsgericht Hamburg, HRB 120189
> Geschäftsführer: Carsten Bock
> Ust-ID: DE279344284
>
> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
> http://www.ng-voice.com/imprint/
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3008
days inactive
3037
days old
7 comments
4 participants
participants (4)
-
Carsten Bock -
Daniel Grotti -
Daniel-Constantin Mierla -
Laura