Paul Kyzivat <[EMAIL PROTECTED]> writes:
>> In our case we have to get announcements via a PSTN gateway before answer.
>> There is a regulatory requirement in Austria to render announcements in
>> certain cases (value added numbers) explaining the expected charges before
>> the caller answers. Therefore we cannot wait for 200 OK, because 200 OK
>> comes only after the announcement.
>> Without any 183 session progress we either hear nothing or a local
>> generated
>> ringing tone. I understand, that to trigger the rendering of the RTP-stream
>> in the User Agent an 183 is a good response.
>> But why should I nee any SDP inside this 183?
>
>Devices use a bunch of schemes in practice to decide when to start
>rendering received media. But the only robust scheme that I have seen
>discussed requires the UAC to start rendering media as soon as it begins
>receiving media.
>
>OTOH, in practice you will have to do what works with the devices you
>have. But that isn't a standards issue.
183 needs SDP to define (among other things) the RTCP port
it's using (and for NAT traversal, the source port), and what codecs
it _might_ use. Some (many) devices don't really like switching codecs,
so using SDP can lock down the media to a codec (and the associated
parameters).
In theory, since 200 OK can be lost, a sender has to be ready to
"receive" media on the offered ports as soon as it sends the INVITE.
In practice, it may not be able to do so until it sees a 200 OK or
183 due to NAT issues, etc. Also, receiving the media and actually
doing something with it are again separate issues.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
