-----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. >> 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. 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. 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. > 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. 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... 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
