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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org