[Freeswitch-users] One way audio to CME

Peter eidevm5 at gmail.com
Fri Aug 9 05:03:04 MSD 2013


Ah, it all makes sense now.  I was misunderstanding the way the way the
sip/rtp IP settings worked.

Thank you very much for sorting this out.  Much appreciated.


On Thu, Aug 8, 2013 at 7:07 PM, Anthony McGarry <agtmcgarry at gmail.com>wrote:

> sip-ip & rtp-ip should be set per profile. So if you have 5 profiles each
> profile.xml will have these params set to whatever IP address the profile
> should use.
> In your case
>
> external profile
> <param name="sip-ip" value="10.1.1.206"/>
> <param name="rtp-ip" value="10.1.1.206"/>
>
> internal profile
> <param name="sip-ip" value="10.10.10.206"/>
> <param name="rtp-ip" value="10.10.10.206"/>
>
> you only need to worry about ext-sip-ip and ext-rtp-ip if there is NAT in
> the path.
> Better to leave them in each profile to
> <param name="ext-sip-ip" value="auto-nat"/>
> <param name="ext-rtp-ip" value="auto-nat"/>
>
>
> On 8 Aug 2013, at 03:29, Peter <eidevm5 at gmail.com> wrote:
>
> Hi Brian.
>
> I did have the IP set in the external profile, but after removing them it
> didn't seem to make any difference, ie:  the SIP ports were listening on
> the correct IP address.
>
> Have to say I'm getting a little confused as to when and where to use
> sip-ip and ext-sip-ip
>
> Should sip-ip ALWAYS be set to your internal IP address and ext-sip-ip to
> your external IP address?
>
> If so, which profiles do they need to be set in?   If they are set in both
> the internal and external SIP profiles, does that matter?
>
> Thanks
>
> Peter
>
>
>
> On Thu, Aug 8, 2013 at 11:41 AM, Brian Foster <bdfoster at davri.com> wrote:
>
>> Your ip for the external profile will show whatever the ip is set to in
>> the external profile configs. It doesn't matter what is set in the internal
>> profile.
>>
>> Thank you,
>>
>> Brian Foster
>> Project Manager/Owner's Rep.
>> Davri Investments, Inc.
>> O: 317-787-2686 x2102
>> M: 317-600-9753
>> E: bdfoster at davri.com
>> Indianapolis, Indiana
>>
>> Sent from a mobile device.
>> On Aug 7, 2013 9:36 PM, "Peter" <eidevm5 at gmail.com> wrote:
>>
>>> Hi Anthony
>>>
>>> Really appreciate the taking your time to look at this.  It's starting
>>> to drive me nuts.
>>>
>>> My dialplan for calls to CME is:
>>>
>>>   <extension name="incoming-cme">
>>>         <condition field="destination_number" expression="^(3\d\d\d)$">
>>>             <action application="bridge" data="sofia/internal/${
>>> destination_number}@10.10.10.203"/>
>>>         </condition>
>>>   </extension>
>>>
>>>
>>> My internal sip profile has:
>>>
>>>     <param name="rtp-ip" value="10.10.10.206"/>
>>>     <param name="sip-ip" value="10.10.10.206"/>
>>>     <param name="ext-rtp-ip" value="10.1.1.206"/>
>>>     <param name="ext-sip-ip" value="10.1.1.206"/>
>>>
>>> The output from:
>>>
>>> sofia status
>>>
>>> is:
>>>
>>> internal    profile                 sip:mod_sofia at 10.1.1.206:5060
>>> RUNNING (0)
>>> external    profile                 sip:mod_sofia at 10.1.1.206:5060
>>> RUNNING (0)
>>>
>>> Should internal show 10.10.10.206??
>>>
>>> The output from:
>>>
>>> sofia status profile internal
>>>
>>> shows:
>>>
>>> Name                 internal
>>> Domain Name          N/A
>>> Auto-NAT             false
>>> DBName               sofia_reg_internal
>>> Pres Hosts           10.10.10.206,10.1.1.206
>>> Dialplan             XML
>>> Context              public
>>> Challenge Realm      auto_from
>>> RTP-IP               10.10.10.206
>>> Ext-RTP-IP           10.1.1.206
>>> SIP-IP               10.10.10.206
>>> Ext-SIP-IP           10.1.1.206
>>> URL                  sip:mod_sofia at 10.1.1.206:5060
>>> BIND-URL             sip:mod_sofia at 10.1.1.206:5060;maddr=10.10.10.206
>>> HOLD-MUSIC           N/A
>>> OUTBOUND-PROXY       N/A
>>> CODECS IN            iLBC at 30i,PCMU,PCMA,GSM
>>> CODECS OUT           iLBC at 30i,PCMU,PCMA,GSM
>>> TEL-EVENT            101
>>> DTMF-MODE            rfc2833
>>> CNG                  13
>>> SESSION-TO           0
>>> MAX-DIALOG           0
>>> NOMEDIA              false
>>> LATE-NEG             false
>>> PROXY-MEDIA          false
>>> ZRTP-PASSTHRU        false
>>> AGGRESSIVENAT        false
>>> STUN-ENABLED         true
>>> STUN-AUTO-DISABLE    false
>>>
>>>
>>> The SIP trace from the Freeswitch SBC is at:
>>>
>>> http://pastebin.freeswitch.org/21279
>>>
>>> I've been playing around with all sorts of different combinations of
>>> SIP/RTP IP settings, but still no closer.
>>>
>>> Hope you have some insight.
>>>
>>> Thanks
>>>
>>> Peter
>>>
>>> On Wed, Aug 7, 2013 at 6:31 PM, Anthony McGarry <agtmcgarry at gmail.com>wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> Your debug shows the invite with via/from/contact/rpid all coming from
>>>> 10.1.1.206, your external side.
>>>> Check your bridge statement, is it using the correct sip profile?
>>>> Check your sip profile SBC internal params rtp-ip & sip-ip, make sure
>>>> they are set correctly to 10.10.10.206
>>>> Paste up your logs from the sbc including sip trace.
>>>>
>>>> Anthony
>>>>
>>>>
>>>> On 7 Aug 2013, at 08:12, Peter <eidevm5 at gmail.com> wrote:
>>>>
>>>> Hi Anthony.
>>>>
>>>> Yes, the SIP profiles are the same for calls going to Kamailio and to
>>>> CME/CUBE.
>>>>
>>>> Note that CME only has one interface, so binding the source interface
>>>> doesn't really make much sense.
>>>>
>>>> Note that I've simplified my set up a little and the phone that was
>>>> registered to CUCM is now registered to CME.  However, the result is still
>>>> the same, ie:  one way audio to the Cisco phone.
>>>>
>>>> You can see the SIP debug from CME at:
>>>>
>>>> http://pastebin.freeswitch.org/21274
>>>>
>>>> The call is coming from 1001 at 10.1.1.204 to 3000 at 10.10.10.203
>>>>
>>>> where
>>>>
>>>> 10.1.1.204  - Freeswitch where SIP clients register to
>>>> 10.1.1.206  - External side of Freeswitch SBC
>>>> 10.10.10.206 - Internal side of Freeswitch SBC
>>>> 10.10.10.203 - CME
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> On Tue, Aug 6, 2013 at 5:13 PM, Anthony McGarry <agtmcgarry at gmail.com>wrote:
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> Because the calls are fine when using Kamailio I'm assuming your sip
>>>>> profiles are fine and you FS SBC config is fine. Are you using the same
>>>>> profiles?
>>>>> Yes you are correct. Have you added the commands? Add them as a first
>>>>> step.
>>>>> Send on a 'debug ccsip messages'
>>>>>
>>>>> Anthony
>>>>>
>>>>>
>>>>>
>>>>> On 6 Aug 2013, at 05:35, Peter <eidevm5 at gmail.com> wrote:
>>>>>
>>>>> Thanks for replying Anthony.
>>>>>
>>>>> Keep in mind that I have very little experience with Cisco products,
>>>>> so I may be missing something fundamental.
>>>>>
>>>>> As far as I can see
>>>>>
>>>>> voice-class sip bind media source-interface ....
>>>>>
>>>>> is just used to bind the SIP or media stream to the appropriate
>>>>> interface on the CUBE.
>>>>>
>>>>> My issue is that the CUBE is trying to initiate the return RTP stream
>>>>> to the external interface (instead of the internal interface) on the
>>>>> Freeswitch SBC.
>>>>>
>>>>> Is my understanding of the sip bind media command correct?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> On Mon, Aug 5, 2013 at 5:23 PM, Anthony McGarry <agtmcgarry at gmail.com>wrote:
>>>>>
>>>>>> On cube make sure you specify the source address on your dial-peers
>>>>>> voice-class sip bind media|control
>>>>>> to the correct side. I have seen one way audio when not set.
>>>>>>
>>>>>> On 5 Aug 2013, at 06:29, Peter <eidevm5 at gmail.com> wrote:
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > I currently have successful two way calls (signalling and media) in
>>>>>> the following setup
>>>>>> >
>>>>>> >
>>>>>> > External Linphone -->  Freeswitch  --> Freeswitch SBC  -> Router
>>>>>>  -> Kamailio --> Internal Linphone
>>>>>> >
>>>>>> > However, when I try to call a Cisco handset that is registered to
>>>>>> CUCM9 via CME in the following config:
>>>>>> >
>>>>>> > External Linphone -->  Freeswitch  --> Freeswitch SBC  -> Router
>>>>>>  -> CME ->  CUCM9 -->  Cisco handset
>>>>>> >
>>>>>> > The call signalling appears to be working fine and I can
>>>>>> successfully  initiate a call from each end, but the only RTP stream that
>>>>>> is working is from the external Linphone client to the Cisco handset.
>>>>>> >
>>>>>> > Note that CME is being used as a CUBE device, so all SIP and RTP
>>>>>> goes via it.
>>>>>> >
>>>>>> > Looking at the RTP debugs on CME I can see the problem is that the
>>>>>> "Media Dest Addr" is getting set to the external side of the FS SBC rather
>>>>>> than the internal IP address.
>>>>>> >
>>>>>> >
>>>>>> > I tried setting adding:
>>>>>> >
>>>>>> >             <action application="set"
>>>>>> data="disable_rtp_auto_adjust="true" />
>>>>>> >
>>>>>> > to the dialplan on the SBC, but it made no difference.
>>>>>> >
>>>>>> >
>>>>>> > Any suggestions as to what to check next?
>>>>>> >
>>>>>> > Thanks
>>>>>> >
>>>>>> > Peter
>>>>>> >
>>>>>> >
>>>>>> _________________________________________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>>
>>>>> 
>>>>> 
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.freeswitch.org
>>>>> http://www.cluecon.com
>>>>>
>>>>> FreeSWITCH-users mailing list
>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:http://
>>>>> lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>>
>>>>> 
>>>>> 
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.freeswitch.org
>>>>> http://www.cluecon.com
>>>>>
>>>>> FreeSWITCH-users mailing list
>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:
>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> 
>>>> 
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> 
>>>> 
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130809/dfcde22f/attachment-0001.html 


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list