Hi Greame,
Thanks for support .
But my issue is ,when I calling from A to B (Out call) its showing example.com
in To_header and From_header . and same value going at my PBX ,due this might
be pbx unable to identify the value like 1...@example.com instead of
1234@10.112.87.177 . Can have any possibility to change it at IMS end.
I also change the configuration in Bgcf.json but I unable to check whether
calls are forwarding through BGCF route or not .I found configuration like
below... in one thread.
{
"number_blocks" : [
{
"name" : "Internal numbers",
"prefix" : "650555",
"regex" : "!(^.*$)!sip:\\1...@example.com!"
},
{
"name" : "External numbers",
"prefix" : "",
"regex" : "!(^.*$)!sip:\\1@10.112.87.177!"
}
]
}
{
"routes" : [
{ "name" : "TO_PBX",
"domain" : "10.112.87.177",
"route" : ["<sip:cw-aio:5058;transport=UDP;lr;orig>"]
}
]
}
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:691: Cloned tdta0x7f744c14aea0 to
tdta0x7f744c14e530
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1215: Remove top Route
header Route: <sip:odi_fWh8yrqIzM@10.112.87.250:5054;lr;orig;service=scscf>
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1735: Adding message
0x7f744c14eb40 => txdata 0x7f744c14e5d8 mapping
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1587:
scscf-0x7f744c14df40 pass initial request Request msg INVITE/cseq=1
(tdta0x7f744c14e530) to Sproutlet
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:431: S-CSCF received
initial request
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: false,
local_to_node: true, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 3
20-09-2016 16:37:12.508 UTC Debug scscfsproutlet.cpp:773: Route header
references this system
20-09-2016 16:37:12.508 UTC Debug scscfsproutlet.cpp:786: Found ODI token
fWh8yrqIzM
20-09-2016 16:37:12.508 UTC Debug aschain.h:131: AsChain inc ref 0x7f744c1364b0
-> 2
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:793: Original dialog for
odi_fWh8yrqIzM found: AsChain-orig[0x7f744c1364b0]:2/1
20-09-2016 16:37:12.508 UTC Debug scscfsproutlet.cpp:832: Got our Route header,
session case orig, OD=AsChain-orig[0x7f744c1364b0]:2/1
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:291: Served user from
P-Served-User header
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: true,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 4
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:502: Found served user, so
apply services
20-09-2016 16:37:12.508 UTC Debug scscfsproutlet.cpp:1153: Performing
originating initiating request processing
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:1178: Completed applying
originating services
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: true,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
false, treat_number_as_phone: true
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 2
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:2218: Translating URI
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:2189: Performing ENUM translation
for user 1234
20-09-2016 16:37:12.508 UTC Debug enumservice.cpp:240: Translating URI via JSON
ENUM lookup
20-09-2016 16:37:12.508 UTC Debug enumservice.cpp:305: Comparing first 4
numbers of 1234 against prefix 650555
20-09-2016 16:37:12.508 UTC Debug enumservice.cpp:305: Comparing first 0
numbers of 1234 against prefix
20-09-2016 16:37:12.508 UTC Debug enumservice.cpp:312: Match found
20-09-2016 16:37:12.508 UTC Info enumservice.cpp:280: Number 1234 found,
translated URI = sip:1234@10.112.87.177
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: false,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
false, treat_number_as_phone: true
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 5
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:2249: Translated URI
sip:1234@10.112.87.177 is a real SIP URI - replacing Request-URI
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: false,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 5
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:1194: New URI string is
sip:1234@10.112.87.177
20-09-2016 16:37:12.508 UTC Debug scscfsproutlet.cpp:1210: Routing to BGCF
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:1446: Routing to BGCF
sip:bgcf.cw-aio:5053;transport=TCP
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1350: Sproutlet
send_request 0x7f744c14eb40
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1386:
scscf-0x7f744c14df40 sending Request msg INVITE/cseq=1 (tdta0x7f744c14e530) on
fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1750: Processing actions
from sproutlet - 0 responses, 1 requests, 0 timers
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1790: Processing request
0x7f744c14e5d8, fork = 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1914: scscf-0x7f744c14df40
transmitting request on fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1928: scscf-0x7f744c14df40
store reference to non-ACK request Request msg INVITE/cseq=1
(tdta0x7f744c14e530) on fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1742: Removing message
0x7f744c14eb40 => txdata 0x7f744c14e5d8 mapping
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:119: Find target Sproutlet
for request
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:158: Found next routable
URI: sip:bgcf.cw-aio:5053;transport=TCP;lr
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:329: Possible service name
- bgcf
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:335: Hostname - cw-aio
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1154: Created Sproutlet
bgcf-0x7f744c05f0b0 for Request msg INVITE/cseq=1 (tdta0x7f744c14e530)
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:2062: Routing Response
msg 100/INVITE/cseq=1 (tdta0x7f744c1515d0) (609 bytes) to upstream sproutlet
scscf:
--start msg--
SIP/2.0 100 Trying
Via: SIP/2.0/TCP
10.112.87.250:45312;rport=45312;received=10.112.87.250;branch=z9hG4bKPjMCwNeVkjc1uawalD3By9r.lqGGy5PwHh
Via: SIP/2.0/TCP
10.112.123.57:43259;received=10.112.123.57;branch=z9hG4bK-524287-1---fa5982366f8904be
Record-Route:
<sip:scscf.cw-aio:5054;transport=TCP;lr;service=scscf;billing-role=charge-orig>
Record-Route: <sip:10.112.87.250:5058;transport=TCP;lr>
Record-Route: <sip:paRGfRUGv7@cw-aio:5060;transport=TCP;lr>
Call-ID: OV0U_26XyoJOUXCQ0B_6FA..
From: <sip:6505550...@example.com>;tag=9b0c5d3e
To: <sip:1...@example.com>
CSeq: 1 INVITE
Content-Length: 0
--end msg--
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1735: Adding message
0x7f744c151be0 => txdata 0x7f744c151678 mapping
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1623:
scscf-0x7f744c14df40 received provisional response Response msg
100/INVITE/cseq=1 (tdta0x7f744c1515d0) on fork 0, state = Proceeding
20-09-2016 16:37:12.508 UTC Info scscfsproutlet.cpp:561: S-CSCF received
response
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1413:
scscf-0x7f744c14df40 sending Response msg 100/INVITE/cseq=1 (tdta0x7f744c1515d0)
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1750: Processing actions
from sproutlet - 1 responses, 0 requests, 0 timers
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1836: Aggregating response
with status code 100
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1853: Discard 100/INVITE
response (tdta0x7f744c1515d0)
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1742: Removing message
0x7f744c151be0 => txdata 0x7f744c151678 mapping
20-09-2016 16:37:12.508 UTC Debug pjsip: tdta0x7f744c15 Destroying txdata
Response msg 100/INVITE/cseq=1 (tdta0x7f744c1515d0)
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:2062: Routing Request
msg INVITE/cseq=1 (tdta0x7f744c14e530) (1411 bytes) to downstream sproutlet
bgcf:
--start msg--
INVITE sip:1234@10.112.87.177 SIP/2.0
Record-Route:
<sip:scscf.cw-aio:5054;transport=TCP;lr;service=scscf;billing-role=charge-orig>
Via: SIP/2.0/TCP
10.112.87.250:45312;rport=45312;received=10.112.87.250;branch=z9hG4bKPjMCwNeVkjc1uawalD3By9r.lqGGy5PwHh
Record-Route: <sip:10.112.87.250:5058;transport=TCP;lr>
Record-Route: <sip:paRGfRUGv7@cw-aio:5060;transport=TCP;lr>
Via: SIP/2.0/TCP
10.112.123.57:43259;received=10.112.123.57;branch=z9hG4bK-524287-1---fa5982366f8904be
Max-Forwards: 67
Contact: <sip:6505550962@10.112.123.57:43259;transport=tcp>
To: <sip:1...@example.com>
From: <sip:6505550...@example.com>;tag=9b0c5d3e
Call-ID: OV0U_26XyoJOUXCQ0B_6FA..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, outbound, path,
X-cisco-serviceuri
User-Agent: Z 3.9.32144 r32121
Allow-Events: presence, kpml
P-Asserted-Identity: <sip:6505550...@example.com>
Session-Expires: 600
P-Served-User: <sip:6505550...@example.com>;sescase=orig;regstate=reg
Route: <sip:bgcf.cw-aio:5053;transport=TCP;lr>
Content-Type: application/sdp
Content-Length: 241
v=0
o=Z 0 0 IN IP4 10.112.123.57
s=Z
c=IN IP4 10.112.123.57
t=0 0
m=audio 8000 RTP/AVP 3 110 8 0 97 101
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
--end msg--
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:691: Cloned tdta0x7f744c14e530 to
tdta0x7f744c1515d0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1215: Remove top Route
header Route: <sip:bgcf.cw-aio:5053;transport=TCP;lr>
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1735: Adding message
0x7f744c151be0 => txdata 0x7f744c151678 mapping
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1587:
bgcf-0x7f744c05f0b0 pass initial request Request msg INVITE/cseq=1
(tdta0x7f744c1515d0) to Sproutlet
20-09-2016 16:37:12.508 UTC Debug acr.cpp:49: Created ACR (0x7f744c05f030)
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: false,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 5
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:2328: Not translating URI
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:169: home domain: false,
local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-09-2016 16:37:12.508 UTC Debug uri_classifier.cpp:199: Classified URI as 5
20-09-2016 16:37:12.508 UTC Debug bgcfservice.cpp:188: Getting route for URI
domain 10.112.87.177 via BGCF lookup
20-09-2016 16:37:12.508 UTC Info bgcfservice.cpp:198: Found route to domain
10.112.87.177
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1350: Sproutlet
send_request 0x7f744c151be0
20-09-2016 16:37:12.508 UTC Verbose sproutletproxy.cpp:1386:
bgcf-0x7f744c05f0b0 sending Request msg INVITE/cseq=1 (tdta0x7f744c1515d0) on
fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1750: Processing actions
from sproutlet - 0 responses, 1 requests, 0 timers
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1790: Processing request
0x7f744c151678, fork = 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1914: bgcf-0x7f744c05f0b0
transmitting request on fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1928: bgcf-0x7f744c05f0b0
store reference to non-ACK request Request msg INVITE/cseq=1
(tdta0x7f744c1515d0) on fork 0
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:1742: Removing message
0x7f744c151be0 => txdata 0x7f744c151678 mapping
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:119: Find target Sproutlet
for request
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:158: Found next routable
URI: sip:cw-aio:5058;transport=UDP;lr;orig
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:190: No Sproutlet found
using service name or host
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:196: Find default service
for port 5058
20-09-2016 16:37:12.508 UTC Debug sproutletproxy.cpp:874: No local sproutlet
matches request
20-09-2016 16:37:12.508 UTC Debug pjsip: tsx0x7f744c154 Transaction created for
Request msg INVITE/cseq=1 (tdta0x7f744c1515d0)
20-09-2016 16:37:12.508 UTC Debug basicproxy.cpp:1618: Added trail identifier
10262 to UAC transaction
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:490: Next hop node is encoded in
top route header
20-09-2016 16:37:12.508 UTC Debug sipresolver.cpp:86: SIPResolver::resolve for
name cw-aio, port 5058, transport 17, family 2
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:523: Attempt to parse cw-aio
as IP address
20-09-2016 16:37:12.508 UTC Debug sipresolver.cpp:128: Port is specified
20-09-2016 16:37:12.508 UTC Debug sipresolver.cpp:296: Perform A/AAAA record
lookup only, name = cw-aio
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:724: Removing record
for scscf.cw-aio (type 1, expiry time 1474389247) from the expiry list
20-09-2016 16:37:12.508 UTC Verbose dnscachedresolver.cpp:245: Check cache for
cw-aio type 1
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:251: No entry found in
cache
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:254: Create cache entry
pending query
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:302: Create and execute
DNS query transaction
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:315: Wait for query
responses
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:465: Received DNS
response for cw-aio type A
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:90: Parsing DNS message
000000: 19378580 00010001 00000000 0663772d 61696f00 00010001 c00c0001 00010000
.7.. .... .... .cw- aio. .... .... ....
000020: 00000004 0a7057fa
.... .pW.
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:95: Parsing header at offset 0x0
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:98: 1 questions, 1 answers, 0
authorities, 0 additional records
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:103: Parsing question 1 at
offset 0xc
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:229: Parsed domain name =
cw-aio, encoded length = 8
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:112: Parsing answer 1 at offset
0x18
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:229: Parsed domain name =
cw-aio, encoded length = 2
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:282: Resource Record
NAME=cw-aio TYPE=A CLASS=IN TTL=0 RDLENGTH=4
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:287: Parse A record RDATA
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:142: Answer records
cw-aio 0 IN A 10.112.87.250
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:143: Authority records
20-09-2016 16:37:12.508 UTC Debug dnsparser.cpp:144: Additional records
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:761: Adding record to
cache entry, TTL=0, expiry=1474389432
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:765: Update cache entry
expiry to 1474389432
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:707: Adding cw-aio to
cache expiry list with deletion time of 1474389732
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:319: Received all query
responses
20-09-2016 16:37:12.508 UTC Debug dnscachedresolver.cpp:347: Pulling 1 records
from cache for cw-aio A
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:362: Found 1 A/AAAA records,
randomizing
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:993: 10.112.87.250:5058
transport 17 has state: WHITE
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:993: 10.112.87.250:5058
transport 17 has state: WHITE
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:406: Added a server, now
have 1 of 5
20-09-2016 16:37:12.508 UTC Debug baseresolver.cpp:447: Adding 0 servers from
blacklist
20-09-2016 16:37:12.508 UTC Info pjutils.cpp:938: Resolved destination URI
sip:cw-aio:5058;transport=UDP;lr;orig to 1 servers
20-09-2016 16:37:12.508 UTC Debug pjutils.cpp:490: Next hop node is encoded in
top route header
20-09-2016 16:37:12.508 UTC Debug basicproxy.cpp:1641: Next hop cw-aio is not a
stateless proxy
20-09-2016 16:37:12.508 UTC Debug basicproxy.cpp:1655: Sending request for
sip:1234@10.112.87.177
20-09-2016 16:37:12.508 UTC Debug pjsip: tsx0x7f744c154 Sending Request msg
INVITE/cseq=1 (tdta0x7f744c1515d0) in state Null
20-09-2016 16:37:12.508 UTC Debug pjsip: endpoint Request msg
INVITE/cseq=1 (tdta0x7f744c1515d0): skipping target resolution because address
is already set
20-09-2016 16:37:12.508 UTC Debug pjsip: endpoint Request msg
INVITE/cseq=1 (tdta0x7f744c1515d0) exceeds UDP size threshold (1300), sending
with TCP
20-09-2016 16:37:12.508 UTC Verbose pjsip: tcpc0x7f744c15 TCP client transport
created
20-09-2016 16:37:12.508 UTC Verbose pjsip: tcpc0x7f744c15 TCP transport
10.112.87.250:57743 is connecting to 10.112.87.250:5058...
20-09-2016 16:37:12.509 UTC Verbose common_sip_processing.cpp:136: TX 1504
bytes Request msg INVITE/cseq=1 (tdta0x7f744c1515d0) to TCP 10.112.87.250:5058:
--start msg--
INVITE sip:1234@10.112.87.177 SIP/2.0
Via: SIP/2.0/TCP
10.112.87.250:57743;rport;branch=z9hG4bKPjeUUjYygIls2DRu2LAAHqVGU27AHZ.-S3
Record-Route:
<sip:scscf.cw-aio:5054;transport=TCP;lr;service=scscf;billing-role=charge-orig>
Via: SIP/2.0/TCP
10.112.87.250:45312;rport=45312;received=10.112.87.250;branch=z9hG4bKPjMCwNeVkjc1uawalD3By9r.lqGGy5PwHh
Record-Route: <sip:10.112.87.250:5058;transport=TCP;lr>
Record-Route: <sip:paRGfRUGv7@cw-aio:5060;transport=TCP;lr>
Via: SIP/2.0/TCP
10.112.123.57:43259;received=10.112.123.57;branch=z9hG4bK-524287-1---fa5982366f8904be
Max-Forwards: 66
Contact: <sip:6505550962@10.112.123.57:43259;transport=tcp>
To: <sip:1...@example.com>
From: <sip:6505550...@example.com>;tag=9b0c5d3e
Call-ID: OV0U_26XyoJOUXCQ0B_6FA..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, outbound, path,
X-cisco-serviceuri
User-Agent: Z 3.9.32144 r32121
Allow-Events: presence, kpml
P-Asserted-Identity: <sip:6505550...@example.com>
Session-Expires: 600
P-Served-User: <sip:6505550...@example.com>;sescase=orig;regstate=reg
Route: <sip:cw-aio:5058;transport=UDP;lr;orig>
Content-Type: application/sdp
Content-Length: 241
v=0
o=Z 0 0 IN IP4 10.112.123.57
s=Z
c=IN IP4 10.112.123.57
t=0 0
m=audio 8000 RTP/AVP 3 110 8 0 97 101
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
--end msg--
20-09-2016 16:37:12.509 UTC Debug pjsip: tsx0x7f744c154 State changed from Null
to Calling, event=TX_MSG
20-09-2016 16:37:12.509 UTC Debug basicproxy.cpp:213: tsx0x7f744c1546a8 -
tu_on_tsx_state UAC, TSX_STATE TX_MSG state=Calling
20-09-2016 16:37:12.509 UTC Debug basicproxy.cpp:1813: tsx0x7f744c1546a8 -
uac_tsx = 0x7f744c154540, uas_tsx = 0x7f744c001b20
20-09-2016 16:37:12.509 UTC Debug basicproxy.cpp:1821: TX_MSG event on current
UAC transaction
20-09-2016 16:37:12.509 UTC Debug basicproxy.cpp:2134: Starting timer C
20-09-2016 16:37:12.509 UTC Debug thread_dispatcher.cpp:193: Worker thread
completed processing message 0x7f744409acd8
20-09-2016 16:37:12.509 UTC Debug thread_dispatcher.cpp:199: Request latency =
8327us
20-09-2016 16:37:12.519 UTC Verbose pjsip: tcpc0x7f744c15 TCP transport
10.112.87.250:57743 is connected to 10.112.87.250:5058
20-09-2016 16:37:12.524 UTC Debug pjsip: sip_endpoint.c Processing incoming
message: Response msg 100/INVITE/cseq=1 (rdata0x7f744c157410)
20-09-2016 16:37:12.524 UTC Verbose common_sip_processing.cpp:120: RX 864 bytes
Response msg 100/INVITE/cseq=1 (rdata0x7f744c157410) from TCP
10.112.87.250:5058:
--start msg--
-----Original Message-----
From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] On
Behalf Of clearwater-requ...@lists.projectclearwater.org
Sent: 20 September 2016 17:18
To: clearwater@lists.projectclearwater.org
Subject: Clearwater Digest, Vol 41, Issue 37
Send Clearwater mailing list submissions to
clearwater@lists.projectclearwater.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
or, via email, send a message with subject or body 'help' to
clearwater-requ...@lists.projectclearwater.org
You can reach the person managing the list at
clearwater-ow...@lists.projectclearwater.org
When replying, please edit your Subject line so it is more specific than "Re:
Contents of Clearwater digest..."
Today's Topics:
1. Re: SIP Trunking With PBX_aio
(Graeme Robertson (projectclearwater.org))
2. Re: Performance limit measurement
(Graeme Robertson (projectclearwater.org))
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Sep 2016 11:06:39 +0000
From: "Graeme Robertson (projectclearwater.org)"
<gra...@projectclearwater.org>
To: "clearwater@lists.projectclearwater.org"
<clearwater@lists.projectclearwater.org>
Subject: Re: [Project Clearwater] SIP Trunking With PBX_aio
Message-ID:
<cy4pr02mb2616ba771b427321072c871ce3...@cy4pr02mb2616.namprd02.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi Surender,
At the end of originating processing at the S-CSCF, we do an ENUM lookup and
find a match and translate the Request URI to
sip:1234@10.112.87.177;transport=TCP. We then identify that this is not a local
user, so we send it to the BGCF to route off-net. The BGCF thinks there are no
routes configured for 10.112.87.177, and so it just attempts normal SIP
proxying - i.e. it sends the INVITE to 10.112.87.177:5060, which is your PBX.
It looks as though (from an earlier email) that you were hoping to route it via
Bono (as an IBCF) but for some reason this configuration hasn't been picked up.
However, I'm not sure there's actually any value to including the IBCF in this
flow - the same INVITE would still end up being routed to 10.112.87.177:5060.
Project Clearwater is designed as a spec-compliant IMS core. In the IMS world,
the user in the To header is never really used, and we never touch it. This is
not very consistent with the original standards for SIP detailed in
RFC3261<https://www.ietf.org/rfc/rfc3261.txt>, so we don't always interoperate
perfectly with non-IMS devices. I'm afraid I don't know anything about your
PBX, but if it is non-IMS and is expecting the To header to contain a certain
value, then this would explain why it is rejecting the call. If you really need
to re-write the To header on your request, and you are not averse to writing a
bit of code, Sprout provides a really easy-to-use API for developing your own
app server. https://github.com/Metaswitch/greeter is a sample application
server that uses this API and simply adds the header "Subject: Hello world!" to
a SIP message - you could write something similar that changes to the To header
on your SIP messages. Alternatively, Metaswitch has a commercial pro
duct called
Perimeta<http://www.metaswitch.com/perimeta-session-border-controller-sbc>
which can be deployed as an IBCF, and which has a SIP Message Manipulation
Framework which you would be able to use to alter your To header.
Thanks,
Graeme
-----Original Message-----
From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] On
Behalf Of Surender Singh
Sent: 20 September 2016 07:42
To:
clearwater@lists.projectclearwater.org<mailto:clearwater@lists.projectclearwater.org>
Subject: Re: [Project Clearwater] SIP Trunking With PBX_aio
Hi Graeme/Team,
Updating...............
1) Now Incoming calls are working from PBX to IMS .
2) For Outgoing calls ,able to send request Invite to PBX IP 10.112.87.177 but
getting 404 no route to destination/Not found.
3) Can you suggest me what parameter (To Header or Request URI) are checked by
the Peer node (PBX) to terminate the calls.
4) I also not able to understand configuration/calls flow in BGCF.JSON. How
IMS route the calls using BGCF.JSON.
Please find some below logs of Sprout....
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.projectclearwater.org/pipermail/clearwater_lists.projectclearwater.org/attachments/20160920/e5c1d912/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 20 Sep 2016 11:47:06 +0000
From: "Graeme Robertson (projectclearwater.org)"
<gra...@projectclearwater.org>
To: "clearwater@lists.projectclearwater.org"
<clearwater@lists.projectclearwater.org>
Subject: Re: [Project Clearwater] Performance limit measurement
Message-ID:
<mwhpr02mb2621f5d2d0fb35d6ffa34f10e3...@mwhpr02mb2621.namprd02.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
It?s worth noting that Project Clearwater is designed to scale horizontally
rather than vertically, so we would expect multiple less powerful Sprout nodes
to out-perform a single powerful Sprout node. However, that doesn?t mean that
your Sprout node isn?t capable of handling the load you?re hitting it with.
We do expose latency measurements over SNMP ? see
http://clearwater.readthedocs.io/en/stable/Clearwater_SNMP_Statistics.html for
more details. In particular, under Sprout statistics we have various latency
statistics including latency for SIP requests and latency for requests to
Homestead. There are a couple of other statistics that might be useful for
determining when exactly our requests are failing ? if the number of initial
registration failures and/or the number of authentication failures are non-zero
this would indicate that the bottleneck is actually at Homestead.
It does sound as though Sprout is reporting itself as overloaded even though it
could handle more requests. As I mentioned previously, Sprout will tweak it?s
overload controls to rectify this, but it won?t be immediate, which might
explain the failures. I know you?ve already tried tweaking the token controls,
but it might be worth looking at them again. Over the course of the minute of
your test, I think we expect to receive 60,000 REGISTERs (2 per subscriber),
and they should be even distributed, so we?re expecting 1,000 requests per
second. Have you tried setting init_token_rate to 1,000? You?ll want to make
sure this change is picked up on both Sprout and Homestead ? you can do this by
editing /etc/clearwater/shared_config on a single node and running
/usr/share/clearwater/clearwater-config-manager/scripts/upload_shared_config.
After a few minutes the change will have propagated around the deployment.
Thanks,
Graeme
From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] On
Behalf Of ??????? ?ats?????
Sent: 19 September 2016 08:42
To: clearwater@lists.projectclearwater.org
Subject: Re: [Project Clearwater] Performance limit measurement
Hi Graeme,
i created a simpler scenario comparing to what the Sip Stress testing uses. In
each scenario two subscribers try just to register to IMS and do not make any
call to each other. I run this scenario for 15000 pairs of subscribers (30000
subscribers). The register requests are distributed in 1 minute time. It seems
tha Sprout node is the bottleneck. The return code of most of the failed
messages is 503 (Service Unavailable) and of some of them 408 (Request
Timeout). I have added resources in Sprout (4 CPUs and 8Gb memory) so i don't
believe that resources is the issue.
Does Sprout somehow exposes the latency measurements that lead to the
throttling? We would like to take a look at them.
Here is the the xml file .
<scenario name="Call Load Test">
<User variables="my_dn,peer_dn,call_repeat" />
<nop hide="true">
<action>
<!-- Get my and peer's DN -->
<assignstr assign_to="my_dn" value="[field0]" />
<!-- field1 is my_auth, but we can't store it in a variable -->
<assignstr assign_to="peer_dn" value="[field2]" />
<!-- field3 is peer_auth, but we can't store it in a variable -->
<assign assign_to="reg_repeat" value="0"/>
<assign assign_to="call_repeat" value="0"/>
</action>
</nop>
<pause distribution="uniform" min="0" max="60000" />
<send>
<![CDATA[
REGISTER sip:[$my_dn]@[service] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];rport;branch=[branch]-[$my_dn]-[$reg_repeat]
Route: <sip:[service];transport=[transport];lr>
Max-Forwards: 70
From: <sip:[$my_dn]@[service]>;tag=[pid]SIPpTag00[call_number]
To: <sip:[$my_dn]@[service]>
Call-ID: [$my_dn]///[call_id]
CSeq: [cseq] REGISTER
User-Agent: Accession 4.0.0.0
Supported: outbound, path
Contact:
<sip:[$my_dn]@[local_ip]:[local_port];transport=[transport];ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000000000001>"
Expires: 3600
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Content-Length: 0
]]>
</send>
<recv response="401" auth="true">
<action>
<add assign_to="reg_repeat" value="1" />
</action>
</recv>
<send>
<![CDATA[
REGISTER sip:[$my_dn]@[service] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];rport;branch=[branch]-[$my_dn]-[$reg_repeat]
Route: <sip:[service];transport=[transport];lr>
Max-Forwards: 70
From: <sip:[$my_dn]@[service]>;tag=[pid]SIPpTag00[call_number]
To: <sip:[$my_dn]@[service]>
Call-ID: [$my_dn]///[call_id]
CSeq: [cseq] REGISTER
User-Agent: Accession 4.0.0.0
Supported: outbound, path
Contact:
<sip:[$my_dn]@[local_ip]:[local_port];transport=[transport];ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000000000001>"
Expires: 3600
[field1]
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Content-Length: 0
]]>
</send>
<recv response="200">
<action>
<ereg regexp="rport=([^;]*);.*received=([^;]*);" search_in="hdr"
header="Via:" assign_to="dummy" />
<add assign_to="reg_repeat" value="1" />
</action>
</recv>
<Reference variables="dummy" />
<send>
<![CDATA[
REGISTER sip:[$peer_dn]@[service] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];rport;branch=[branch]-[$peer_dn]-[$reg_repeat]
Route: <sip:[service];transport=[transport];lr>
Max-Forwards: 70
From: <sip:[$peer_dn]@[service]>;tag=[pid]SIPpTag00[call_number]
To: <sip:[$peer_dn]@[service]>
Call-ID: [$peer_dn]///[call_id]
CSeq: [cseq] REGISTER
User-Agent: Accession 4.0.0.0
Supported: outbound, path
Contact:
<sip:[$peer_dn]@[local_ip]:[local_port];transport=[transport];ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000000000001>"
Expires: 3600
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Content-Length: 0
]]>
</send>
<recv response="401" auth="true">
<action>
<add assign_to="reg_repeat" value="1" />
</action>
</recv>
<send>
<![CDATA[
REGISTER sip:[$peer_dn]@[service] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];rport;branch=[branch]-[$peer_dn]-[$reg_repeat]
Route: <sip:[service];transport=[transport];lr>
Max-Forwards: 70
From: <sip:[$peer_dn]@[service]>;tag=[pid]SIPpTag00[call_number]
To: <sip:[$peer_dn]@[service]>
Call-ID: [$peer_dn]///[call_id]
CSeq: [cseq] REGISTER
User-Agent: Accession 4.0.0.0
Supported: outbound, path
Contact:
<sip:[$peer_dn]@[local_ip]:[local_port];transport=[transport];ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000000000001>"
Expires: 3600
[field3]
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Content-Length: 0
]]>
</send>
<recv response="200">
<action>
<add assign_to="reg_repeat" value="1" />
</action>
</recv>
</scenario>
Best Regards,
Michael Katsoulis
2016-09-16 21:25 GMT+03:00 Graeme Robertson
(projectclearwater.org<http://projectclearwater.org>)
<gra...@projectclearwater.org<mailto:gra...@projectclearwater.org>>:
Hi Michael,
Can you tell me more about your scenario? It sounds like you?re not using the
clearwater-sip-stress package, or at least not in exactly the form we package
up. If you?re not using the clearwater-sip-stress package then please can you
send details of your stress scenario?
Depending on how powerful your Sprout node is, I would expect 15000 calls per
second to be towards the upper limit of its performance powers. However, if the
CPU is not particularly high then that would suggest that Sprout?s throttling
controls might require further tuning. Do you know what return code the
?unexpected messages? have? 503s indicate that there is overload somewhere.
Sprout does adjust its throttling controls to match the load its able to
process, but that process is not immediate, and we recommend building stress up
gradually rather than immediately firing 15000 calls per second into the system
? for more information on that, see
http://www.projectclearwater.org/clearwater-performance-and-our-load-monitor/.
One final thought I had was that the node you?re running stress on might be
overloaded. If the stress node is not responding to messages in a timely
fashion then that will generate time outs and unexpected messages.
Thanks,
Graeme
From: Clearwater
[mailto:clearwater-boun...@lists.projectclearwater.org<mailto:clearwater-boun...@lists.projectclearwater.org>]
On Behalf Of ??????? ?ats?????
Sent: 16 September 2016 15:16
To:
clearwater@lists.projectclearwater.org<mailto:clearwater@lists.projectclearwater.org>
Subject: Re: [Project Clearwater] Performance limit measurement
Hi Graeme,
thanks a lot for your response.
In our scenario we are using the Stress node to generate 15000 calls in 60
seconds. The number of unsuccessful calls varies from ~500 to ~5000 even in
subsequent repetitions of the same scenario.
According to wireshark the failures happen because of Sprout that does not send
the correct responses in time and so we get "time-outs" and "unexpected
messages" in the Stress node.
The Sprout node has sufficient CPU and memory resources.
What could be the reason of this instability in our deployment?
Thank you in advance,
Michael Katsoulis
2016-09-16 16:14 GMT+03:00 Graeme Robertson
(projectclearwater.org<http://projectclearwater.org>)
<gra...@projectclearwater.org<mailto:gra...@projectclearwater.org>>:
Hi Michael,
How many successes and failures are you seeing? We primarily use the
clearwater-sip-stress package to check we haven?t introduced crashes under
load, and to check we haven?t significantly regressed the performance of
Project Clearwater. Unfortunately clearwater-sip-stress is not reliable enough
to generate completely accurate performance numbers for Project Clearwater (and
we don?t accurately measure Project Clearwater performance or provide numbers).
We tend to see around 1% failures when running clearwater-sip-stress. If your
failure numbers are fluctuating at around 1% then this is probably down to the
test scripts not being completely reliable, and you won?t have actually hit the
deployment?s limit until you start seeing more failures than this.
Thanks,
Graeme
From: Clearwater
[mailto:clearwater-boun...@lists.projectclearwater.org<mailto:clearwater-boun...@lists.projectclearwater.org>]
On Behalf Of ??????? ?ats?????
Sent: 16 September 2016 10:17
To:
Clearwater@lists.projectclearwater.org<mailto:Clearwater@lists.projectclearwater.org>
Subject: [Project Clearwater] Performance limit measurement
Hi all,
we are running Stress Tests against our Clearwater Deployment using Sip Stress
node.
We have noticed that the results are not consistent as the number of
successfull calls changes during repetitions of the same test scenario.
We have tried to increase the values of max_tokens , init_token_rate,
min_token_rate and target_latency_us but we did not observe any difference.
What is the proposed way to discover the deployment's limit on how many
requests per second can be served?
Thanks in advance,
Michael Katsoulis
_______________________________________________
Clearwater mailing list
Clearwater@lists.projectclearwater.org<mailto:Clearwater@lists.projectclearwater.org>
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
_______________________________________________
Clearwater mailing list
Clearwater@lists.projectclearwater.org<mailto:Clearwater@lists.projectclearwater.org>
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.projectclearwater.org/pipermail/clearwater_lists.projectclearwater.org/attachments/20160920/5dbe2e56/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Clearwater mailing list
Clearwater@lists.projectclearwater.org
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
------------------------------
End of Clearwater Digest, Vol 41, Issue 37
******************************************
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Clearwater mailing list
Clearwater@lists.projectclearwater.org
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
