> Rule for session timer re-Invite is not change SDP. So, B has to sent G.729 to
Can you tell me which rfc/doc along with section you are referring to here, which mandates such a requirement on refresh re-invite ? Uttam Kumar Sarkar <[EMAIL PROTECTED]> wrote: A. Otherwise it's not following the protocol. That's it. -----Original Message----- From: Manish [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 3:06 AM To: Uttam Kumar Sarkar; Samuel Osorio Calvo; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Session Timer and Transfer usarkar wrote : --------------------- >It should sent G.729 to A. Codec between B and C should not influence >Codec >between A and B. >These two are separate calls. Agreed that they are two seperate calls. But note that B has already sent a G.711 request to C, which means that its DSP should be ready to receive any G.711 voice it might be receiving from C. At this instant, it doesn't look clean to send G.729 to phone A, because DSP is internally programmed for G.711. This is all assuming, there is only one DSP in the system. -Manish Uttam Kumar Sarkar <[EMAIL PROTECTED]> wrote: See inline.. Hi All, I have a query about way session timer is implemented with call transfer: Lets say: Phone A - Transferor Phone B - Transferee Phone C - Transfer Target A SIP call is up between A and B with G.729, though preferred codec on Phone B is G.711. Phone A does'nt support G.711. Phone B is SIP session refresher and perodically sends a RE-INVITE to referesh session timer. At this point Phone A initiates a transfer by sending REFER to B, which sends an INVITE to Phone C with G.711 and hence switches internally to G.711 codec. While phone C is ringing, session refresh timer for original call fires on B and hence it has to send a REINVITE to A. Here is a doubt: - What are the media parameters phone B should send to A at this moment. It cant send G.729 and change internal codec setting since it has already sent G.711 to Phone C. It should sent G.729 to A. Codec between B and C should not influence Codec between A and B. These two are separate calls. And if it sends G.711 to A, that INVITE would be rejected may be with 488 which will cause first call to go down, which we dont want at this moment. - This leads me to think that Ideally for just session refreshing SDP should not be considered at all.. But AFAIK, SDP should be negotiated as part of INVITE transaction. Any info on how this or similar scenarios usually handled ? Is there a way of session timer refreshing without any media negotiation after call is UP ? Regards, M. --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we. NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
