RE: [Sipping] Question on RFC 3725 (3PCC)

["Elwell, John" <john.elwell at siemens.com>]

Paul,

Thanks for your answer. I had looked into preconditions, in particular the
examples given in section 9 of RFC 3725, but I had difficulties working out
how to use it to get around this particular problem. I guess once the two
UAs have reached the point in signalling that they can then send UPDATE
requests to each other through the controller, then one could send an UPDATE
request asking for media with security, say, and if that results in a 488 it
could try again asking for media without security. Preconditions would play
a role only in that it would delay alerting until this stage is reached. We
get to this stage roughly as shown in the example in 9.2, but the SDP offer
in the 183 from would need to be for no media.

I need to work it through a bit more to see which UA takes which role and if
it works when one of the UAs drives it in this way even though the other UA
and/or the controller are unaware of this procedure.

Of course, Cullen's proposal for multipart MIME alternatives would avoid
these problems, but that didn't progress too far at the last IETF.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
> Sent: 05 May 2005 14:18
> To: Elwell, John
> Cc: Jonathan Rosenberg; Peterson, Jon; 
> Gonzalo.Camarillo at ericsson.com; schulzrinne at cs.columbia.edu; 
> sipping at ietf.org; Hammer Bernhard; Schmidt Christian
> Subject: Re: [Sipping] Question on RFC 3725 (3PCC)
> 
> 
> 
> Elwell, John wrote:
> > I have a concern about the working of 3PCC when an SDP 
> offer is rejected.
> > 
> > In flow 1, what if the SDP offer from A is rejected by B? B 
> will send a 
> > 488 response to the controller, but this cannot be relayed 
> back to A. 
> > Presumably the only action that the controller can do is to 
> send an ACK 
> > to A (but that should contain an SDP answer, so how is it 
> populated?) 
> 
> Lacking something better, I think the controller simply 
> derives an SDP 
> answer from the offer, rejecting (with port=0) each offered 
> media line.
> 
> > and then a BYE to A. A will never receive the reason for 
> failure. In 
> 
> Well, I think a Reason header in the BYE is a way to convey this. But 
> I'm not sure if there is a good reason for this purpose.
> 
> > particular, if the reasons for failure was the rejection of key 
> > management for payload encryption, A cannot retry (e.g., 
> without payload 
> > encryption). Of course, the controller can retry, but it 
> will probably 
> > yield the same result.
> 
> After ACKing the first invite it could try again with a reinvite. For 
> instance it might flip sides and first send an offerless invite to B, 
> and use the result to reinvite A. That might yield better results.
> 
> This whole thing would work better with preconditions - 
> perhaps the new 
> conn precondition. Then there would be no alerting of either 
> side until 
> all these details were sorted out.
> 
> > I won't discuss flow 2, because that is not recommended.
> > 
> > For flows 3 and 4 considerations are similar to flow 1, 
> except that A 
> > rejects the offer from B and B does not get to find out why 
> the call failed.
> > 
> > Has this been discussed and has any solution been identified?
> 
> I don't recall this having been discussed.
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP