[Spce-user] CE - Voicemail

Daniel Grotti dgrotti at sipwise.com
Mon Mar 24 13:38:25 EDT 2014


Sorry, I meant the output of:

cat /etc/sems/etc/ngcp_cf.sbcprofile.conf

the interested part should looks like:


header_filter=whitelist
header_list=P-Caller-UUID,P-Caller-CLIR,P-CF-Depth,P-First-Caller-UPN,P-First-Caller-NPN,P-First-Caller-UPD,P-First-Caller-NPD,P-Acc-Caller-User,P-Acc-Caller-Domain,P-Acc-State,P-From-Peer,P-First-V46-RTP,P-First-RTP,P-Callee-Ext-Contr-ID,P-Callee-Ext-Subs-ID,P-Callee-Account-ID,P-Preferred-Identity,P-Asserted-Identity,Diversion,Privacy,Allow,Supported,Require,RAck,RSeq,Rseq,Call-Info



Thanks,

On 03/24/2014 06:32 PM, Daniel Grotti wrote:
> Hi,
> problem is that you have the second INVITE (the one that should be the
> internal loop) not being seen as internal loop but as call from PSTN:
> 
> Mar 21 19:40:50 spce proxy[3785]: NOTICE: <script>: New request -
> M=INVITE R=sip:vmu1905642XXXX at voicebox.local
> F=sip:9057636529 at 74.205.223.213 T=sip:1905642XXXX at sipce.halex.com
> IP=127.0.0.1:5080 (127.0.0.1:5080)
> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.213
> Mar 21 19:40:50 spce proxy[3785]: INFO: <script>: Load domain
> preferences for callee - R=sip:vmu1905642XXXX at voicebox.local
> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.213
> Mar 21 19:40:50 spce proxy[3785]: INFO: <script>: Clean domain
> preferences for callee - R=sip:vmu1905642XXXX at voicebox.local
> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.213
> Mar 21 19:40:50 spce proxy[3785]: NOTICE: <script>: Call from PSTN -
> R=sip:vmu1905642XXXX at voicebox.local
> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.213
> ...
> ...
> 
> 
> so somehow the following check fails:
> 
> else if(ds_is_from_list("3") && is_present_hf("P-CF-Depth"))
> {
>                 xlog("L_NOTICE", "Internal CF loop - [% logreq -%]\n");
> ...
> ...
> 
> 
> which means that in your mysql kamailio.dispatcher table , group 3 is
> not set to 127.0.0.1:5080 or you don't have P-CF-Depth header set in
> that INVITE.
> 
> What is the output of:
> cat /etc/sems/etc/ngcp.sbcprofile.conf ?
> 
> 
> 
> 
> That's strange, do you have the pcap of this call ?
> You can send it in private, to me if you want.
> 
> Daniel
> 
> 
> 
> 
> On 03/24/2014 06:02 PM, Derrick Bradbury wrote:
>> Attached the full log:
>>
>>
>> ________________________________________
>> From: spce-user-bounces at lists.sipwise.com [spce-user-bounces at lists.sipwise.com] on behalf of Daniel Grotti [dgrotti at sipwise.com]
>> Sent: Monday, March 24, 2014 12:42 PM
>> To: spce-user at lists.sipwise.com
>> Subject: Re: [Spce-user] CE -  Voicemail
>>
>> Can you share your kamailio-proxy.log regarding that CallID (at least
>> the internal loop part) ?
>>
>> Thanks,
>> Daniel
>>
>>
>>
>> On 03/24/2014 05:34 PM, Derrick Bradbury wrote:
>>> Should have also said, I'm on v3.1.. Sorry!
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* spce-user-bounces at lists.sipwise.com
>>> [spce-user-bounces at lists.sipwise.com] on behalf of Derrick Bradbury
>>> [derrickb at halex.com]
>>> *Sent:* Monday, March 24, 2014 12:30 PM
>>> *To:* spce-user at lists.sipwise.com
>>> *Subject:* [Spce-user] CE - Voicemail
>>>
>>> Hi all...
>>>
>>> I'm running CE on Virtualbox, and am having issues trying to get the
>>> voicemail to work..
>>>
>>> To test I have  call forwarding set to the voicemail box.
>>>
>>> From what I can see in the docs with the callflow the call is supposed
>>> to go:
>>>
>>> Endpoint -> LB -> Proxy -> AppServer (voicemail)
>>>
>>> But it is going:
>>>
>>> Endpoint -> LB ->Proxy -> SBC -> dies
>>>
>>> I have been pouring over logs the last little bit and see this:
>>>
>>> Mar 21 19:40:50 spce proxy[3785]: INFO: <script>: No CF time destination
>>> set for CF map id '5' found, CF is done always -
>>> R=sip:user_FKpNTQML at sipce.halex.com
>>> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.213
>>> Mar 21 19:40:50 spce proxy[3785]: NOTICE: <script>: CFU to destination
>>> 'sip:vmu1905642XXXX at voicebox.local' with timeout '300' activated -
>>> R=sip:vmu1905642XXXX at voicebox.local
>>> ID=070e54c47e42ec7f7e6fa723037ea108 at 74.205.223.XXX
>>>
>>> It then jumps down to ROUTE_EXECUTE_CF_LOOP where it sends it to the SBC
>>> and somewhere in here I see:
>>>
>>> Mar 21 20:29:49 spce sems[16908]: [#7f200fdfd700] [send,
>>> transport.cpp:98] DEBUG: send  msg#012--++--#012INVITE
>>> sip:vmu19056423835 at voicebox.local SIP/2.0#015#012Via: SIP/2.0/UDP
>>> 127.0.0.1:5080;branch=z9hG4bKb1f7Ta~I;rport#015#012From: "Halex"
>>> <sip:9057636529 at 74.205.223.213>;tag=7DE69E5E-532C932D0002B975-0F
>>>
>>> and then:
>>> Mar 21 20:29:49 spce sems[16908]: [#7f200efef700] [run,
>>> udp_trsp.cpp:213] DEBUG: vv M [|] u recvd msg via UDP
>>> vv#012--++--#012SIP/2.0 404 Not Found#015#012Via: SIP/2.0/UDP
>>> 127.0.0.1:5080;branch=z9hG4bKb1f7Ta~I;rport=5080#015#012From: "Halex"
>>> <sip:9057636529 at 74.205.223.213>;tag=7DE69E5E-532C932D0002B975-0FEM
>>>
>>> Which then gets relayed back up the line....
>>>
>>> So looking at the logic, it will work if it goes to the app server
>>> instead of the SBC.. but am I missing something on the routing?
>>>
>>> This seems to be my only show stopper right now...
>>>
>>> Thanks,
>>> Derrick
>>>
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> http://lists.sipwise.com/listinfo/spce-user
>>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>>
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
> 




More information about the Spce-user mailing list