Re: [Sip-implementors] Media Port change during Hold/resume
Hi Praveen, AFAIK Unhold + Video Upgrade in a same INVITE is valid usecase. Searching for Spec reference. will update once I get it. Could think of one use case. 1. MO make VT call to MT. 2. Call held, Network support only audio announcement. 3. Network downgrades call to audio only and audio direction recvonly at MT. 4. After MO unhold call. Its Upgrade + unhold to MT. Regards, Venkat Ramana On Fri, Jun 8, 2018 at 8:59 PM, Parveen Aggarwal wrote: > Dear Experts, > > I am facing one scenario: > > 1. Make video call: Audio and video port non-zero > 2. downgrade video call: audio port non-zero and video port 0 > 3. Network hold the call: audio:sendonly , video port 0 > 4. network sending re-invite without SDP, User agent sending offer in 200 > OK but with video port 0 > 5. Network sending ACK with audio: sendonly, video port: 0 > === > after this Network is resuming the call with re-invite but at the same time > it is sending video port as non-zero. > > Is it a correct behavior to update audio media direction from recvonly to > sendrecv and updating the Video port in same re-INVITE? (Any spec > reference) > > Thanks for your advice. > > Regards, > Parveen > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Call failure after ReInvite
How media will be established without sdp in ack? Offer answer is not complete. I think session cannot be established here. Is it possible to attach working tcpdump for understanding. Regards, Venkat Ramana On Thu 24 May, 2018, 1:55 AM Abhishek, wrote: > Hello Paul, > Thank you very much for response. > > We could see with some of the peer nodes that Call is continuing even if > ACK message does not carry SDP. > > Best Regards, > Abhishek Phadke > > > On 23-May-2018, at 22:38, Paul Kyzivat wrote: > > > > Abhishek, > > > >> On 5/23/18 7:15 AM, Abhishek wrote: > >> Hello, > >>> SS7 Switch —> Gateway Switch —> SIP SBC > >>> > >>> Call flow is as mentioned. > >>> > >>> SIP call gets established between Gateway Switch node and SIP SBC node. > >>> > >>> > >>> Gateway Switch node initiates Re Invite without SDP. > >>> > >>> SIP SBC node responds with 200 OK along with SDP keeping all fields > same as previous 200 OK including ‘sess-version’ field. > >>> > >>> Gateway Switch node acknowledge this message with ACK without SDP. > >>> > >>> SIP SBC node sends BYE to this response and mentions Reason as > cause=488, No answer to offer. > >>> > >>> > >>> Would like to understand way forward for resolution of this issue. > > > > While the details are sketchy, IIUC then the Gateway Switch is clearly > in error - it is required to include answer SDP in the ACK. > > > >Thanks, > >Paul > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Dividing the AS, RR and RS values from NW allocated DL_MBR
Hi Bharat, Thank you for the feedback. Yes, overall RTCP bandwidth is 5% of AS value. But this RTCP bandwidth is in addition to AS value or part of AS value. If AS 41, bandwidth available for RTP 41 and 2.05 for RTCP or Bandwidth available for RTP is 38.95 and RTCP 2.05? Regards, Venkat Ramana On 05-Sep-2017 9:26 PM, "Ranganatha, Bharath (Nokia - IN/Bangalore)" < bharath.rangana...@nokia.com> wrote: Hi Arun, You need to look in the SDP body for the bandwidth allocated in to the respective video codec.. Based on that you can calculate the RR and RS with below logic. If UE indicates AS parameter 41 mbps, then RS Parameter = 1.25% of AS parameter = 512 kbps RR Parameter = 3.75% of AS Parameter = 1537 kbps Same logic applies in your case too... Reg, -Bharath -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Arun Tagare Sent: Saturday, September 02, 2017 11:27 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Dividing the AS, RR and RS values from NW allocated DL_MBR Hi All, Need one clarification on dividing/allocating the AS, RR and RS bit rates, from the received value in the bearer modification [incoming OTA message from the NW] Scenario: If DUT A and DUT B are in VT call. After some operation DUT A receives bearer modification from the NW with DL MBR say (400) [In the incoming OTA message] How this DL MBR should be divided among the AS, RR and RS Example 1: AS: 400 RS: 5000 RR: 6000 Example 2: AS: 389 [400 - (5000+6000)] RS: 5000 RR: 6000 I am not clear with this calculation please help to share the inputs *RFC 3550:* Appendix B - Changes from RFC 1889 - The description of the session bandwidth parameter is expanded in Section 6.2, including a clarification that the control traffic bandwidth is in addition to the session bandwidth for the data traffic. -- 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 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
