first, if B switchs to G.711 when sending INVITE to C is an internal design decision, but it has to be ready to get early media in any codec it supports.
About refresh/re-invite. Refresh is a "normal" re-invite to A. In a re-invite you can change the media parameters ( SDP ) if the other side (A) doesn't support the new parameters it can reject the re-invite. This doesn't mean that the call goes down. The call remains with the same state as before the re-invite. If B then wants to close the session with A ( so he can use G.711 with C), it can send BYE to A.
Regards Diego B
Uttam Kumar Sarkar wrote:
Rule for session timer re-Invite is not change SDP. So, B has to sent G.729 to 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! <http://us.rd.yahoo.com/mail_us/taglines/security/*http://promotions.yahoo.c om/new_mail/static/protection.html> 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. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
begin:vcard fn:Diego B n:B;Diego org:MailVision Ltd. adr:;;10A Haganim Str.;Haifa;;;Israel email;internet:[EMAIL PROTECTED] tel;work:+972-4-8500505 x 102 tel;fax:+972-4-8508025 url:http://www.mailvision.com version:2.1 end:vcard
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
