On 10/29/12 10:24 AM, [email protected] wrote:
> Hi *,
>
> During the SDP negotiation, in case a offer is made with more than 1 payload
> type (say 2), for which, if the answer also contains 2 payload types (as it
> supports both payload types), I presume it should be possible to
> change/switch the payload type "on the fly" at RTP level. If a Media Gateway
> is involved in either offer or answer side, this is normally supported using
> ReserveValue at Megaco level.
>
> So, my assumption was that payload type change "on the fly" should be
> possible at RTP level, if either side reserves the resources accordingly.
>
> But, in RFC 3264, Section 10.2 seems to contradict this.
>
> Could you please clarify the same or whether I am interpreting it in a wrong
> way.
A special case of this happens all the time - using telephone-events for
DTMF.
*In principle* you can use any of the mutually negotiated codecs and
switch among them at will. But *in practice* you may have mixed success
with this.
For "common" sip use the practice has been that an RTP session will
contain only a single RTP stream. But that has never been a requirement.
And of late there is much more talk and interest in multiplexing
multiple RTP streams over a single RTP session.
Once you do that, then it makes much more sense that you might make
independent codec choices per stream.
Thanks,
Paul
> Thanks,
> kumar
>
> Please do not print this email unless it is absolutely necessary.
>
> 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
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
