Re: [Sip-implementors] Media Port change during Hold/resume
Hi Praveen, I think it is fine to change the media flow direction, and the port for another media stream in the same Re-INVITE. Section 14 of RFC 3261 allows this (RFC 6131/RFC 6337 also don't prohibit this). Regards, Swami. Sensitivity: Internal & Restricted -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Parveen Aggarwal Sent: Friday, June 8, 2018 9:00 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Media Port change during Hold/resume ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** 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 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Media Port change during Hold/resume
Parveen Aggarwal writes: > 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) There are few limitations regarding the changes that a new offer can propose. Mostly, the number of m- lines may not decrease and the media type of each m- line must remain the same. If the update to the audio m- line is valid when done alone and the update to the video m- line is valid when done alone, both can be done together. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Media Port change during Hold/resume
On 6/8/18 11:29 AM, 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) I don't see anything particularly wrong in anything above, to the extent that I understand what you mean. It isn't clear to me who initiated the downgrade to audio only. If that was the network, rather than the caller, and if the caller still desires video, then in (4) I would expect it to offer a non-zero video port again. But there is a lot of local discretion in that. It isn't clear to me what it is that you are questioning. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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
[Sip-implementors] Media Port change during Hold/resume
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
