Marcus, responses inline...
Marcus Better wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 2010-07-01 19:35, Paul Kyzivat skrev: >> Marcus Better wrote: >>> I'm considering to apply SIP in an application, but using a custom >>> session description format that is not SDP. The endpoints must be able >>> to exchange longer sequences of offers before reaching an agreement, > >> Yes, its possible. >> >> But I suggest you think long and hard before abandoning SDP in favor of >> a different session description format. > > I'm not setting up a media session, but some more general type of > "session". Interoperability with SIP/RTP is not a goal. But I would like > to have some other features of SIP: > * user initiating a session setup with other user(s), > * answering or cancelling a session. > * forking and parallel search. > * conference (multi-party, adding and removing participants). > > By using SIP we hope to gain ability to reuse existing protocol and > network elements (routers, proxies, app servers) with minimum effort. > > Unfortunately I'm not able to give full details here. ok. >>> I'm considering to use a sequence of reliable provisional responses and >>> PRACKs, each carrying a session description, and repeating until the >>> session parameters are agreed. > >> You don't spell out in the above which messages have offers and answers, > > To be more precise: > * both sides take turns in sending offers, > * there is at least one offer, > * the sequence ends with an answer, which means the most recent offer > was accepted. sip o/a requires a sequence (one or more) o/a *pairs*. So its always oaoaoa.... and cannot ever be ...ooa... or ...oaa... I can't tell from the above if you are compliant with that or not. (It is IMO a defect in sip that there is nothing about a message that distinguishes an offer from an answer. It can only be determined from history - a session description is an answer if it was preceded by an offer, and visa versa.) > There is another important restriction: there is user interaction after > each offer, so there might be an extended waiting time before each > message (not just the INVITE). > I guess this rules out carrying messages in a PRACK. So it would seem. > I could still use > reliable provisional responses in the UAS-->UAC direction. Not sure > about the UAC-->UAS though. Maybe an UPDATE could carry an offer, its > 200 OK response would not carry an offer, and a further provisional > response would carry the next offer from the UAS. The latter isn't permitted. >> There are limited ways you can insert offers and answers into these. >> Take a look at: >> >> http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt > > I did, but the different scenarios it describes are all restricted to > one round-trip for the offer/answer. I think you will find some of the scenarios actually mention 2 or 3 o/a exchanges. And certainly it is intended to cover cases involving more than one exchange. Its just that what it focuses on only addresses more than one for context. The key thing for you in that document is Table 1, because it summarizes the constraints under which you may operate. I never considered a use case such as yours. It seems that the constraints don't in fact permit you to do the o/a exchanges as you wish. After the first exchange, there is no way to put a large delay between an offer and an answer. (Unless of course you want to use a sequence of reINVITEs. But I presume that is off the table.) > SDPng is interesting, but only considers a two-step offer/answer when > used with SIP. > >> Also, look at RFCs 3312, > > Ok, here they use UPDATE along the same lines. This looks promising... I suggest you look at this carefully. Preconditions have some of the constraints you do - it may take time to resolve them. But they put the delays between the o/a pairs rather than between the o and a of a pair. Thanks, Paul > Thanks a lot for you comments, this is very helpful! > > Cheers, > > Marcus > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwt91AACgkQXjXn6TzcAQnJ5QCg3xFhnskuZlEkGpwuoTDx3aqu > GD8AoO0taGAU0y+vxSMvLY0WNUUCfvX0 > =lZxO > -----END PGP SIGNATURE----- > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
