Hi Arun you won't get RTP from NW and end point at the same time. consider this scenario: User Alice calls User Bob. Now Bob is busy with other call. So here User Alice will hear a hold tone i.e busy signal and would get 486 Busy here. Here SSRC would be server . So now Alice will not get any RTP packets from User Bob
Then User Alice may remain on hold or disconnect or can request call back. So when user Alice get call back and gets connected with User Bob, then User Alice will see RTP packets from User B - these are end to end. Here SSRC would be User Bob. So looking at SSRC / Source in RTP, you can differentiate. Also hold packets will have music which can tell u that they are for hold. On Thu, Sep 22, 2022 at 9:56 AM Arun Tagare <arun.taga...@gmail.com> wrote: > Thanks Ranjit, > > Yes for the signalling part i am aware, but as shared earlier how the RTP > from N/w and other UE in same session be differentiate? > > So SSRC will be different right? > > On Thu, 22 Sep 2022 at 8:05 PM, Ranjit Avasarala <ranjitka...@gmail.com> > wrote: > >> Hi Arun >> >> Both are technically voice packets and use RTP protocol. So that way >> both are similar. Also the voice traffic is end to end whereas hold music >> is from the server. Like announcement - may be from Application Server. >> So looking at the SSRC or Source in RTP Packets, you should be able to say >> which entity is sending those packets. >> >> Another way to check is the SDP. for hold music, the media attribute >> will be sendonly. where as for regular voice traffic it will sendrecv >> >> Regards >> Ranjit >> >> On Thu, Sep 22, 2022 at 4:19 AM Amanpreet Singh < >> amanpreeet.si...@gmail.com> wrote: >> >>> Arun, for what purpose would you like to inspect and differentiate the >>> hold >>> and audio RTP packets? >>> and based on the signaling messages, can't that be achieved. >>> >>> Thanks, >>> Amanpreet Singh. >>> >>> >>> On Thu, Sep 22, 2022 at 12:30 PM Arun Tagare <arun.taga...@gmail.com> >>> wrote: >>> >>> > Thanks Ranjit & Amanpreet, for your response >>> > >>> > But my question is >>> > >>> > MT <===== Call Established ===========> MO >>> > MT <===> Voice RTP Packets flow <=====> MO >>> > MT <======Hold ===================> MO >>> > MT <==== HOLD Tone RTP packets ====== NW >>> > >>> > Both Voice RTP packets and Hold RTP packets come to the same port >>> right ? >>> > How to differentiate these RTP packets >>> > >>> > On Thu, Sep 22, 2022 at 11:06 AM Amanpreet Singh < >>> > amanpreeet.si...@gmail.com> wrote: >>> > >>> >> Probably you can think of looking into the signaling messages(SDP in >>> case >>> >> of SIP) to differentiate when the call is on hold and when not i.e. >>> normal >>> >> audio RTP. >>> >> >>> >> BTW what is the use case to differentiate call hold vs audio RTP? >>> >> >>> >> >>> >> Regards, >>> >> Amanpreet Singh. >>> >> >>> >> >>> >> On Wed, Sep 21, 2022 at 9:51 PM Arun Tagare <arun.taga...@gmail.com> >>> >> wrote: >>> >> >>> >>> Hi All, >>> >>> >>> >>> I have a doubt on the Hold call tone or music on hold tone RTP v/s >>> actual >>> >>> voice RTP before hold >>> >>> >>> >>> Can these RTP packets be able to differentiate? >>> >>> If yes how? >>> >>> if not why? >>> >>> >>> >>> Thanks a lot to everyone in advance >>> >>> >>> >>> -- >>> >>> >>> >>> With Regards >>> >>> >>> >>> Arun A. Tagare >>> >>> +91 9449 029729 >>> >>> _______________________________________________ >>> >>> Sip-implementors mailing list >>> >>> Sip-implementors@lists.cs.columbia.edu >>> >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >>> >>> >> >>> > >>> > -- >>> > >>> > With Regards >>> > >>> > Arun A. Tagare >>> > +91 9449 029729 >>> > >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> -- > > With Regards > > Arun A. Tagare > +91 9449 029729 > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
