Lee, There is some SBC, it may be possible because the origination is the behind the NAT then until & unless you get initial RTP packet from ingress they it will not activate redirects. Could you please check when you are getting the initial RTP packet from ingress.
This thing also be possible per design which you are using.. Could you please provide us the RTP traces along with signalling, so that we can check.. also could you please let us know which SBC you are using. Thanks, Nitin Kapoor 2009/12/29 <[email protected]> > Send Sip-implementors mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. No rtp coming in even after offer/answer (???) > 2. Re: No rtp coming in even after offer/answer (Sachin Rastogi) > 3. Re: No rtp coming in even after offer/answer (Alex Balashov) > 4. Re: No rtp coming in even after offer/answer (Mayank Jain) > 5. Re: No rtp coming in even after offer/answer (SungWoo Lee) > 6. Reg: session refresh (Sharanabasavaraj Mathapati) > 7. Re: Reg: session refresh (Neel Neelakantan) > 8. Two Media Stream in one Dialog (Nitin Kapoor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 28 Dec 2009 07:47:17 +0000 (GMT) > From: ??? <[email protected]> > Subject: [Sip-implementors] No rtp coming in even after offer/answer > To: SIPImplementors <[email protected]> > Message-ID: <28888369.149681261986437451.javamail.weblo...@epml14> > Content-Type: text/plain; charset=euc-kr > > Dear > > Have you ever experienced cases that you can not receive any rtp packets > even after finishing offer/answer negotiation is done, and can receive > packets only after sending out your first to the remote party? Provided > there is no fault in SIP signaling perspective, in what circumstances could > we possibly meet cases like this? Wouldn't be NAT configuration or SBC > policy in SIP carrier side? If so, will there be any specific reasons for > this? > > happy holiday. > > Lee, Sungwoo > > > > > ------------------------------ > > Message: 2 > Date: Mon, 28 Dec 2009 18:30:58 +0530 > From: Sachin Rastogi <[email protected]> > Subject: Re: [Sip-implementors] No rtp coming in even after > offer/answer > To: [email protected] > Cc: SIPImplementors <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hi Lee, > There could be multiple reason of not receiving RTP packets. > > 1. Far end UA is not sending RTP. > 2. If you are sure that far end is sending RTP packets then take > wireshark/ethereal capture of RTP media at far end and then verify > Destination IP and Port in RTP packets. > 3. Make sure your near end UA is listening RTP on same port mentioned in > step 2. > > Please verify above steps and post the results. > > Thanks, > Sachin Rastogi > > On Mon, Dec 28, 2009 at 1:17 PM, ??? <[email protected]> wrote: > > > Dear > > > > Have you ever experienced cases that you can not receive any rtp packets > > even after finishing offer/answer negotiation is done, and can receive > > packets only after sending out your first to the remote party? Provided > > there is no fault in SIP signaling perspective, in what circumstances > could > > we possibly meet cases like this? Wouldn't be NAT configuration or SBC > > policy in SIP carrier side? If so, will there be any specific reasons for > > this? > > > > happy holiday. > > > > Lee, Sungwoo > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > Message: 3 > Date: Mon, 28 Dec 2009 09:57:30 -0500 > From: Alex Balashov <[email protected]> > Subject: Re: [Sip-implementors] No rtp coming in even after > offer/answer > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > This sounds like far-end NAT traversal detection at work, together with > draft-comedia style NAT'd media detection. This type of detection waits > to observe the real source port of an incoming RTP packet before > responding, and distrusts the SDP ports advertised in the offer from the > endpoint in question. > > On 12/28/2009 02:47 AM, ??? wrote: > > > Dear > > > > Have you ever experienced cases that you can not receive any rtp packets > even after finishing offer/answer negotiation is done, and can receive > packets only after sending out your first to the remote party? Provided > there is no fault in SIP signaling perspective, in what circumstances could > we possibly meet cases like this? Wouldn't be NAT configuration or SBC > policy in SIP carrier side? If so, will there be any specific reasons for > this? > > > > happy holiday. > > > > Lee, Sungwoo > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > -- > Alex Balashov - Principal > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > > > ------------------------------ > > Message: 4 > Date: Tue, 29 Dec 2009 09:38:11 +0530 > From: Mayank Jain <[email protected]> > Subject: Re: [Sip-implementors] No rtp coming in even after > offer/answer > To: [email protected] > Cc: SIPImplementors <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > ??? wrote: > > Dear > > > > Have you ever experienced cases that you can not receive any rtp packets > even after finishing offer/answer negotiation is done, and can receive > packets only after sending out your first to the remote party? Provided > there is no fault in SIP signaling perspective, in what circumstances could > we possibly meet cases like this? Wouldn't be NAT configuration or SBC > policy in SIP carrier side? If so, will there be any specific reasons for > this? > > > > happy holiday. > > > > Lee, Sungwoo > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > You can use Niksun's NetVoice for monitoring your sip Network and find > out the bottleneck > > Key Benefits > > * End-to-end proactive network and application performance > * High-speed non-intrusive complete or filtered VoIP recording, analysis > and audio/video playback > * Collects, records and analyzes virtually unlimited calls > * Analyzes data with time resolution down to the microsecond > * Completely correlated call to message to packet level analysis > * Complete call level QoS details: Delay, Loss, Jitter and MOS score > * Powerful analysis and filtering for real-time remote diagnostics > > For more details http://www.niksun.com/product.php?id=6 . > > Regards, > Mayank Jain > > > ------------------------------ > > Message: 5 > Date: Tue, 29 Dec 2009 12:56:50 +0000 (GMT) > From: SungWoo Lee <[email protected]> > Subject: Re: [Sip-implementors] No rtp coming in even after > offer/answer > To: Franz Edler <[email protected]>, > [email protected], > [email protected], SIPImplementors > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > https://lists.cs.columbia.edu/pipermail/sip-implementors/attachments/20091229/06ab21ea/attachment-0001.html > > ------------------------------ > > Message: 6 > Date: Tue, 29 Dec 2009 19:30:16 +0530 > From: Sharanabasavaraj Mathapati <[email protected]> > Subject: [Sip-implementors] Reg: session refresh > To: "[email protected]" > <[email protected]> > Message-ID: > < > b927e06069952449b79ef15db95226df0690ea2...@sinchnmbx001.techmahindra.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi All, > > Should we need to refresh a call leg which is on-hold? > > Regards, > Sharan > > > ============================================================================================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential and subject to the Tech Mahindra policy statement, you may > review the policy at <a href="http://www.techmahindra.com/Disclaimer.html > ">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href=" > http://tim.techmahindra.com/Disclaimer.html";> > http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech > Mahindra.============================================================================================================================ > > > ------------------------------ > > Message: 7 > Date: Tue, 29 Dec 2009 08:21:55 -0800 > From: Neel Neelakantan <[email protected]> > Subject: Re: [Sip-implementors] Reg: session refresh > To: Sharanabasavaraj Mathapati <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > See below > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of > Sharanabasavaraj Mathapati > Sent: Tuesday, December 29, 2009 8:00 AM > To: [email protected] > Subject: [Sip-implementors] Reg: session refresh > > Hi All, > > Should we need to refresh a call leg which is on-hold? > > [Neel] > > If you are using UPDATE, you can avoid offer/answer. If you are using > Re-INVITE, the Session Timer referesh doesn't need to know the call status > and it works independently. > > >From RFC 4028: > > Similarly, a re-INVITE or UPDATE request sent within a dialog for > purposes other than session refreshes will also have the effect of > refreshing the session, and its processing will follow the procedures > defined in this specification. > > Regards, > Sharan > > > ============================================================================================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential and subject to the Tech Mahindra policy statement, you may > review the policy at <a href="http://www.techmahindra.com/Disclaimer.html > ">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href=" > http://tim.techmahindra.com/Disclaimer.html";> > http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech > Mahindra.============================================================================================================================ > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 8 > Date: Tue, 29 Dec 2009 12:47:52 -0500 > From: Nitin Kapoor <[email protected]> > Subject: [Sip-implementors] Two Media Stream in one Dialog > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello All, > > I am facing the issue with one of my customer where he is getting two media > streams in one call and they are using SBC(Nextone) > > I checked the signaling & RTP traces and everything looks okay to me. > > As per the traces one RTP packet is going out and the other is coming in, > *But > whenever i am decoding the packets and trying to hear the conversation so > both are the different conversation. * > > Could you please let me know is it possible where i can have the two media > streams in one call when this is the not the conference call. And if this > is > possible then what is the scenario where its possible. > > Thanks, > Nitin Kapoor > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 81, Issue 15 > ************************************************ > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
