Terry L Anderson wrote:
> Sorry I didn't read this answer before replying to previous message.
>
> Jonathan Rosenberg wrote:
>
> > Terry L Anderson wrote:
> > >
> > > Perhaps I wasn't clear enough. I certainly see the statements that 1xx
> > > responses may contain bodies. But I do NOT any longer see the implication
> > > that existance of the body terminates any local ringtone (which was explicit
> > > before). I know that a body can setup a media path for inband tones, but if
> > > the originating UAC initiated ringtone from a 180 that did NOT contain a
> > > body, is it still clear that a 183 with a body stops the locally generated
> > > tone?
> >
> > This is pretty close to the "specify how to build a UI" border. SIP
> > conveys what is happening - estbalishment of sessions, progress codes,
> > etc. How the UI renders these, is its own choice. If an implementation
> > is dumb enough to think that playing local ringback while the session is
> > in progress is a sensible thing, well, what can we do.
>
> Ok, so you believe the same as before, that a media body establishing a session
> should probably stop any local tone generation, but that SIP shouldn't specify
> this interworking behavior. I can live with less specification I just wanted to
> know if this was an intended change in behavior as opposed to less specifically
> specified behavior.
There is one issue here. I may receive an INVITE without an offer, and then I send a
reliable 180 with an offer.
Now, the 180 does include a SDP, but I still want the caller to generate a local
ringback tone (I can't generate one, since I don't have his SDP).
Now, there are a few possibilities:
1. The caller is smart enough. Since he knows he never sent me his SDP, he knows he
must generate a local ringback tone - even if there was an SDP in the 180. I assume
this is what Jonathan has in mind.
2. I set the mode to "inactive" in the 180 SDP, and again the caller is smart enough
to realise he must generate a local ringback tone. I may not want to do that,
however, because if I don't receive an answer before the ACK I won't be able to set
the mode to "sendrecv" in the 200 (I must receive the answer in the ACK, and then
generate a new offer, where I set the mode to "sendrecv" using re-INVITE/UPDATE). I
assume this is what Jonathan also has in mind.
3. Define some header value indicating if a local- and/or remote ringback tone shall
be generated. Then the ringback would be separate from the codec negoatiation
itself, which I think would be a good idea...
Regards,
Christer Holmberg
Ericsson Finland
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
