Paul,
Hold has been initiated from the 3pcc for both the parties ..
So both the parties are on hold by 3pcc, and now it want to reconnect both
of them,
If the behaviour of UA to send SDP(sendrecv) in response to offerelss
invite is not specified in rfc, then 3pcc might have to do the same
technique I proposed earlier.
otherwise, if UA behaviour is to respond with the SDP (sendrecv), then
3pcc can send reinvite to both parties with no offer and when it receives
200 OK from both side, it respond with the SDP of the other party in ACK
message.
Udit
Paul Kyzivat <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/03/2004 08:24 PM
To
[EMAIL PROTECTED]
cc
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject
Re: [Sip-implementors] Rconnecting SIP UAC and UAS
Udit,
You never answered my question of whether the hold was initiated by one
of the endpoints, or by the 3pcc controller itself. That makes a big
difference. More comments below.
Paul
[EMAIL PROTECTED] wrote:
> Paul,
>
> So you mean to say that simply sending Re-invite with no offer to B will
> fetch the SDP of B with mode=sendrecv (no matter if B has been
forcefully
> put on hold by 3pcc). I was having impression, that since B is in hold
> state, if we send Re-invite to B with no offer, it will respond back
with
> the SDP with a=recvonly,
>
> Is this behaviour mentioned somewhere in RFC.
To the best of my knowledge, this is not specified anywhere, and the
behavior certainly isn't required. (When sent an offerless reinvite, the
UAS may respond with any offer that conforms to RFC3264. It could drop
all the existing media and offer entirely new ones.)
But IMO this is the way a reasonable UA would work in the absence of
some other special needs on its part. Doing otherwise (sending an offer
with a=recvonly) would imply that it *wants* to be on hold.
If the UA responds with a=recvonly simply because it thinks that is what
it is expected to do until told otherwise, then it will be necessary for
the 3pcc controller to do more ugly and complex things. For instance
(assuming C is the 3pcc controller between A & B):
original setup:
- C->A: offerless invite
- A->C: 200 w/offer of sdpA1 (sendrecv)
- C->B: invite w/offer of sdpA1
- B->C: 200 w/answer of sdpB1 (sendrecv)
- C->B: ACK
- C->A: ACK w/answer of sdpB1
then the question of how to get on hold in the first place,
assuming it is C that wants this:
- C->B: offerless reinvite
- B->C: 200 w/offer of sdpB1 (still sendrecv)
- C->A: reinvite w/offer of sdpB2 (sdpB1 changed to sendonly)
- A->C: 200 w/answer of sdpA2 (sdpA1 changed to recvonly)
- C->A: ACK
- C->B: ACK w/answer of sdpA2
then to get off hold:
- C->A: offerless reinvite
if A acts as I suggest it should:
- A->C: 200 w/offer of sdpA1 (going back to sendrecv)
- C->B: reinvite w/offer of sdpA1
- B->C: 200 w/answer of sdpB1 (going back to sendrecv)
- C->B: ACK
- C->A: ACK w/answer of sdpB1
OR, if a sticks to recvonly:
- A->C: 200 w/offer of sdpA2 (recvonly)
- C->B: reinvite w/offer of sdpA1 (sdpA2 changed to sendrecv)
- B->C: 200 w/answer of sdpB1 (sendrecv)
- C->B: ACK
- C->A: ACK w/answer of sdpB2 (sdpB1 changed to sendonly)
(this change required to conform to 3264)
(At this time B is off hold, but A still on hold)
- C->B: offerless reinvite
- B->C: 200 w/answer of sdpB1 (sendrecv)
- C->A: reinvite w/offer of sdpB1
- A->C: 200 w/answer of sdpA1 (sendrecv)
- C->A: ACK
- C->B: ACK w/answer of sdpA1
In the above I have taken the liberty of using the same name for two sdp
bodies if their contents are the same other than the o-line. In some
cases these are independently derived and so will have differing o-lines.
Many of the more complex 3pcc call flows have convoluted sequences like
this to avoid the possibility of an infinite series of reinvites.
Paul
> Thanks,
> Udit
>
>
>
> Paul Kyzivat <[EMAIL PROTECTED]>
> 11/02/2004 07:55 PM
>
> To
> [EMAIL PROTECTED]
> cc
> Tsram <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Subject
> Re: [Sip-implementors] Rconnecting SIP UAC and UAS
>
>
>
>
>
>
> Udit,
>
> Your original scenario was a little unclear about why A and B are on
> hold, and this may affect the scenario. Are they on hold because the
> 3pcc controller forced them to be, or because A or B requested the hold?
>
> If an endpoint wants to be on hold (e.g. pushed the hold button on the
> phone), then there is really nothing the other party can do to force it
> go off hold. All you can do is provide the opportunity to go off hold.
>
> In a two party scenario between A and B, if A requests hold by offering
> a=sendonly, then B is forced to respond with a=recvonly (or a=inactive).
> If B wants to get off hold, it can send a reinvite with a=sendrecv,
> but as long as the hold button is still pressed, A will probably still
> respond with a=sendonly. You can insert a B2BUA in the middle of this
> call, but it doesn't really change anything - it still can't force A to
> go off hold.
>
> But if you had a B2BUA in the middle, and *it* was the initiator of
> hold, while A and B *want* to talk to one another, then the B2BUA can
> easily change the situation. All it has to do is the usual B2BUA trick
> of sending an *offerless* reinvite to one of the parties (say A), use
> the answer from A as an offer in a reinvite to B, and then use the
> answer from B to send an answer to A.
>
> This will work because A doesn't want to be on hold. When given the
> opportunity to generate its own offer, it should generate an offer with
> a=sendrecv. And since B doesn't want to be on hold either, when it
> receives an offer with a=sendrecv it should answer with a=sendrecv.
>
> Paul
>
> [EMAIL PROTECTED] wrote:
>
>>Hi,
>>
>>I think the way to avoid checkign for all scenarios is :
>>
>>i) Send Invite to party B with A's stored SDP (a=sendrecv) so that it
>
> will
>
>>become offhold
>>ii) Recevies 200 OK and send ACK.
>>iii) Send INVITE (no sdp) to B
>>iv) Receives 200 OK (sdp of B)
>>v) Send INVITE (sdp B) to A (a=sendrecv)
>>vi) Receives 200 OK (sdp of A) and send ACK
>>vii) Send 200 OK (sdp of A) to B.
>>viii) Receives ACK from B.
>>
>>In this way, both parties will be off-hold and knows each other SDP,
>
> only
>
>>problem is it requires one extra INVITE interaction to change the state
>
> to
>
>>sendrecv mode.
>>
>>Because if we send first INVITE with no SDP, B will respond back with
>
> its
>
>>own SDP with mode=recvonly.
>>
>>-Udit
>>
>>
>>
>>"Tsram" <[EMAIL PROTECTED]>
>>11/02/2004 03:03 PM
>>Please respond to
>>"Tsram" <[EMAIL PROTECTED]>
>>
>>
>>To
>>"Chowdhury, Sayan Sayan" <[EMAIL PROTECTED]>, "Udit"
>><[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"
>><[EMAIL PROTECTED]>
>>cc
>>
>>Subject
>>RE: [Sip-implementors] Rconnecting SIP UAC and UAS
>>
>>
>>
>>
>>
>>
>>Hi,
>>If there's a media change in the 200 OK from B, you sense it in your
>
> app.
>
>>and initiate a mid-call invite with new media to B only.I think you
>
> can't
>
>>avoid this.
>>
>>Srinivasan.
>>
>>--------- Original Message --------
>>From: "Chowdhury, Sayan Sayan" <[EMAIL PROTECTED]>
>>To: "Udit" <[EMAIL PROTECTED]>,
>
> "[EMAIL PROTECTED]"
>
>><[EMAIL PROTECTED]>
>>Subject: RE: [Sip-implementors] Rconnecting SIP UAC and UAS
>>Date: Mon 11/01/04 03:42 PM
>>
>>
>>Hello Udit ,
>>I think you will have to re-negotiate by sending an INVITE with an SDP
>>when
>>you decide to re-connect . You will have to use the SDP received in the
>>200
>>OK for the new RTP streams.
>>You can check out this link for an example call hold flow
>>
>
>
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-07.t
>
>
>>xt
>>
>>Regards ,
>>Sayan
>>
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] Behalf Of Udit
>>Sent: Friday, October 29, 2004 10:52 AM
>>To: [EMAIL PROTECTED]
>>Subject: [Sip-implementors] Rconnecting SIP UAC and UAS
>>
>>
>>Hi,
>>
>>We are developing a third party call control application where we have
>
> to
>
>>reconnect two parties A and B which are in the hold state
>>i.e. party A and B had received IVITE with a=sendonly in SDP,
>>
>>We know the SDP of both the parties A and B (i.e the RTP ports where
>
> they
>
>>are receivign the media streams), my reqmt is to connect parties A and
>
> B.
>
>>One method is :
>>i) Send INVITE (with B sdp, a=sendrecv) to party A
>>ii) Recv 200OK with SDP of A
>>iii) Send INVITE (with A sdp, a =sendrecv) to party B
>>
>>But problem will be that the SDP recvd in 200 OK frm party B can be
>>diferent
>>from the earlier one, so I need to reconnect them again.
>>
>>I want to knwo by which we can we can reconnect both the parties and
>
> they
>
>>know the SDP of each other also.
>>
>>Regards,
>>
>>Udit Kumar Goyal
>>Mars Telecom Systems
>>(Dedicated IDC for 3Com)
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[EMAIL PROTECTED]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>_______________________________________________
>>Sip-implementors mailing list
>>[EMAIL PROTECTED]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>>
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[EMAIL PROTECTED]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
