Subject: RE: [Sipping] Re: RFC 3262 and Offer Answer Model.

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Mar 2005 16:00:08 +0100

> -----Original Message-----
> From: Venkatesh [mailto:[email-masked]] 
> Sent: 29 March 2005 15:24
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: RFC 3262 and Offer Answer Model.
> 
> There are a couple of reasons I can think of as to why I want 
> to do this.
> 
> 1. In cases like 3PCC call control, where a 3PCC controller has sent
> an INVITE w/o SDP on behalf of a user, the 3PCC call controller would
> want to wait for the destination to answer the call before initiating
> any SDP exchange.
[JRE] I assume in this case the B2BUA would be sending the PRACK, rather
than letting it come from the other UA. Maybe in this case the B2BUA would
need to respond with a dummy answer (using port 0 for each medium) in the
PRACK, and then somehow trigger the one of the UAs to initiate another
offer-answer exchange later using re-INVITE or UPDATE. But it seems rather
ugly, and I don't know how it would work out if key management for payload
encryption is required. It would seem far better to let the reliable
provisional response penetrate through to the peer UA and let that send the
PRACK and the SDP answer. Or maybe, for 3PCC the B2BUA should not indicate
support for 100rel in the INVITE, in which case the problem will not arise.

> 
> 2. I want to avoid processing of media from multiple sources before
> call answer? In cases like forking, what if I receive 1xx responses
> with SDP from multiple branches?
[JRE] You would normally only get media from multiple sources if multiple
UASs answer of if some of them send early media. It would, of course, be
beneficial if the UAs all supported RFC 3959 and RFC 3960, which would give
the UAC proper control over early media. In the absence of that, yes,
multiple early media streams may occur, but that is no different from the
case where the UAC includes an SDP offer in the INVITE request.

> 
> Venkatesh
> 
> On Tue, 29 Mar 2005 11:27:00 +0100, Elwell, John
> <[email-masked]> wrote:
> > Venkatesh,
> > 
> > I am not sure why the UAC would wish to delay sending the 
> SDP answer, even
> > in a forking situation. If the UAC were to delay until 
> answer, the UAS would
> > be unable to start sending media until ACK is received. 
> This might result in
> > the phenomenon known as clipping.
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Venkatesh [mailto:[email-masked]]
> > > Sent: 28 March 2005 19:01
> > > To: [email-masked]
> > > Subject: [Sipping] Re: RFC 3262 and Offer Answer Model.
> > >
> > > Hi:
> > >
> > > Reposting query....
> > >
> > > Per section 5 of RFC 3262, a UA MUST generate an 'answer' 
> in a PRACK
> > > request if it received an offer in a reliable provisional 
> response.
> > > This is kind of limiting from the UA's perspective in 
> scenarios where
> > > it is not ready to issue an answer until the far end 
> actually answers
> > > the call (for example in cases where a request got forked 
> and the UA
> > > is receiving multiple 1xx responses with SDP, it might 
> want to delay
> > > providing an answer until one of the branches answer the call). Is
> > > there any rational as to why this is a MUST requirement
> > > ??
> > >
> > > Regards,
> > > Venkatesh
> > >
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments of core SIP
> > >
> >
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Venkatesh <[email-masked]>
Date: Tue, 29 Mar 2005 07:50:34 -0800

Like you said not indicating support for 100rel would be one solution
for 3pcc initiated calls; which brings me back to my initial question:
why does RFC 3262 mandate a UA to send an 'answer' in a PRACK instead
of qualifying it as a MAY strength? From what I understand, the main
intent of PRACK was to provide a reliability mechanism for the
provisional responses...... However, tie'ing this in with having to
provide SDP seems to affect such scenarios and making this extension
un-useable in such scenarios?

And as regards forking, the reason not to send SDP in the INVITE was
to avoid having to handle multiple media streams without expecting
support for RFC 3858 and 3960 from UA's. The solution works ok as long
as the UA does not advertise support for 100rel.

Venkatesh

---

From: Malleswara Rao Ankem <[email-masked]>
Date: Wed, 30 Mar 2005 10:33:49 +0530

Some thoughts inline below..

> un-useable in such scenarios?
 Dont you think by having the answer in a PRACK a round trip of messages is 
 eliminated ? (Moreover, I dont think UPDATE request can be sent with an answer)

> as the UA does not advertise support for 100rel.
 I think INVITE without SDP is normally used in 3pcc type scenarios. 
 If the UA is definitely not capable of handling the forked responses
(reliable  especially) it can try to have  caller preferences for
non-forking proxies?