[SR-Users] Is Media Release (signaling only) possible in Kamailio?

KamDev Essa kamdevessa at yahoo.com
Wed May 9 22:39:18 CEST 2018


 Update. I just checked inbound calls using the "rtpproxy clean" cfg. 
Inbound calls from Carrier to UA work fine with bidirectional RTP. Its the outbound calls from UA to carrier that have a NAT issue.
I am so close :).... 
KD
    On Wednesday, May 9, 2018, 4:29:39 PM EDT, KamDev Essa <kamdevessa at yahoo.com> wrote:  
 
  That did not help. sip capture shows NATed SDP being sent to carrier. Obviously carrier will not be able to make head nor tails about it. And carrier SDP sent to UA is perfect as its not NATed. So UA ===> Carrier is fine. Carrier ====> UA is no RTP.  Does not look like Kam alone can do RTP relase between NATed UA and the outside network entity. 
I will try Freeswitch piggy back and then let Freeswitch bypass media. Logic in Freeswitch may do the trick.   \
KD 
    On Wednesday, May 9, 2018, 3:30:26 PM EDT, Alex Balashov <abalashov at evaristesys.com> wrote:  
 
 You'll want to not load the rtpproxy module, and lose any rtpproxy_*() calls in the actual script. 

On May 9, 2018 3:26:43 PM EDT, KamDev Essa <kamdevessa at yahoo.com> wrote:
>If I comment out the modparam("rtpproxy", "rtpproxy_sock",
>"udp:127.0.0.1:7722") as suggested, I do get RTP flowing just in one
>direction.  From the UA to kam and out to the carrier. I get nothing
>geting back to the end point. In other words 1 way RTP. Looks like its
>Kam RTPProxy or bust.
>KD
>On Wednesday, May 9, 2018, 2:38:08 PM EDT, Alex Balashov
><abalashov at evaristesys.com> wrote:  
> 
>Correct. So remove all semblance of any RTP proxy and the resulting
>behaviour will be exactly what you expect. 
>
>On May 9, 2018 2:13:22 PM EDT, KamDev Essa <kamdevessa at yahoo.com>
>wrote:
>>I dont. I want the 2 end points to talk to each other because I am on
>>AWS with shaky bandwidth stats. It can handle signalingbut not RTP. 
>>However the cfg entry modparam("rtpproxy", "rtpproxy_sock",
>>"udp:127.0.0.1:7722") gives me to believe (not tcdumped RTP ports yet
>>to prove it ) that Kam anchors RTP @ port 7722. 
>>KD  
>>On Wednesday, May 9, 2018, 2:02:14 PM EDT, Alex Balashov
>><abalashov at evaristesys.com> wrote:  
>> 
>>That depends. Start with a more basic question: why do you need RTP
>>relay in the middle at all? 
>>
>>On May 9, 2018 1:54:55 PM EDT, KamDev Essa <kamdevessa at yahoo.com>
>>wrote:
>>>So all calls that kamailio processes using the default cfg file
>anchor
>>>RTP on the kamailio server? Is it a best architecture to farm out RTP
>>>to Freeswitch? Or is the Kamailio RTP proxy a better gig?
>>>KD
>>>On Wednesday, May 9, 2018, 1:38:04 PM EDT, Alex Balashov
>>><abalashov at evaristesys.com> wrote:  
>>> 
>>>Ironically, nothing. Kamailio doesn't touch the respective parties'
>>SDP
>>>unless you invoke an RTP relay (or something else like
>>>fix_nated_sdp()). 
>>>
>>>On May 9, 2018 1:03:19 PM EDT, KamDev Essa <kamdevessa at yahoo.com>
>>>wrote:
>>>>What cfg files changes do I need to make to get Kamailio to be a
>>>>signally only server, yet manipulate the SDP part of the INVITE
>>>message
>>>>to allow remote parties to send media to each other? In Freeswitch
>>>>terms "bypassmedia".
>>>>KD
>>>
>>>
>>>-- Alex
>>>
>>>--
>>>Sent via mobile, please forgive typos and brevity. 
>>>
>>>_______________________________________________
>>>Kamailio (SER) - Users Mailing List
>>>sr-users at lists.kamailio.org
>>>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>  
>>
>>
>>-- Alex
>>
>>--
>>Sent via mobile, please forgive typos and brevity.  
>
>
>-- Alex
>
>--
>Sent via mobile, please forgive typos and brevity.  


-- Alex

--
Sent via mobile, please forgive typos and brevity. 

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180509/43919727/attachment.html>


More information about the sr-users mailing list