[SR-Users] Configuration Issue on Kamailio.

Daniel Grotti dgrotti at sipwise.com
Wed Aug 10 13:33:42 CEST 2016


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 at 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 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:*9999*4912345678 at 2.2.2.2>.
> Contact: <sip:151512345678 at 1.1.1.1:5060>.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 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 at 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 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:*9053*4912345678 at 3.3.3.3>.
> Contact: <sip:151512345678 at 1.1.1.1:5060>.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 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 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
> Date: Wed, 10 Aug 2016 08:54:29 GMT.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 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 at 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 at 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 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
> Date: Wed, 10 Aug 2016 08:54:29 GMT.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 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 at 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 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
> Date: Wed, 10 Aug 2016 08:54:29 GMT.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 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 at 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 at plugit.net 
>> <mailto:red_dra at 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 at 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 at 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 at lists.sip-router.org <mailto:sr-users at 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 at ng-voice.com <mailto:carsten at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160810/a2f251f9/attachment.html>


More information about the sr-users mailing list