Hi Dale, >I don't know if this has been mentioned, but I skimmed draft-ietf-sip-199-06 and couldn't find it: > >One thing that I've always felt was a weakness of the "199" proposal was that it was not possible to associate the early dialog of the 199 with the particular media streams of that early dialog, which >makes it difficult for a UAC to use a 199 response to free media-processing resources.
It is true that the 199 spec doesn't define mechanisms how to do the association. I think we a long time ago agreed that it is outside the scope of the document. But, as indicated in the draft, even if the UAC is not able to associate the dialog with a particular strem, when it receives 199 it can e.g. remove media resources (codecs etc) which have only been reserved for that particular dialgo. >However, if the UAS that creates an early media stream sends a 1xx (e.g., 183) *reliably*, then the UAC is certain to be able to associate the to-tag of the 1xx (which is the same as the to-tag of the >199) with the early media source address/port. > >Why isn't this fact put in the draft? I suppose it isn't a *requirement* for 199, but it seems like a very strong suggestion for UAS behavior to enable the UAC to take advantage of 199. Are you saying that if the UAS sends a reliable 18x with SDP, the UAC will then be able to use the SDP information to associate the media with the dialog? That works with the following assumptions: 1. The UAS uses symmetric media, ie it sends media from the same port/address where it wants to receive media (keep in mind that SDP only indicates where you want to receive media). 2. There are no NATs in the media path. Also, the draft doesn't say anything about whether to send 18x responses reliably or not. If the UAS wants to make sure the UAC gets the SDP, it should send the 18x reliably - no matter if he supports 199 or not. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
