Hi,
Considering B may want to connect A to some other resources in this way
(like 3PCC), and the new media connection may be bi-directional or
uni-directional.
It better for A to provide the full capability in 200 OK SDP(ie,
a=sendrecv), and leave the flexibility of making final decision to B or some
other service logic behind him.
Peili
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Retesh
Chadha
Sent: Wednesday, August 24, 2005 12:55 PM
To: [EMAIL PROTECTED]
Cc: SIP IETF; SIP Implementors; [EMAIL PROTECTED]
Subject: Re: [Sip] Reinvite query
I think here A will make a new offer, and the attribute mode in A's offer
should be sendrecv, but sending recvonly is also not wrong.
Rgds
Retesh
[EMAIL PROTECTED]
om
Sent by: To
[EMAIL PROTECTED] "SIP Implementors"
org <[email protected]>
cc
SIP IETF <[email protected]>
08/24/2005 09:02 Subject
AM [Sip] Reinvite query
Hi,
Suppose party A and B are talking, and B put A on hold. If there is no Music
on hold, party A will not hear an media. If B sends Reinvite to party A (in
hold state) with no sdp, what should be the behaviour of A?
Will it make a new offer ? As it is asking A to make offer when he is in
hold state.
Thanks,
Udit
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip Use
[email protected] for new developments on the application of sip
*********************** FSS-Private ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the individual to whom
it is addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering,
or disclosing the contents of this message. FSS accepts no responsibility
for loss or damage arising from the use of the information transmitted by
this email including damage from virus."
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip Use
[email protected] for new developments on the application of sip
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
