Iñaki Baz Castillo wrote:
> El Miércoles, 17 de Septiembre de 2008, [EMAIL PROTECTED] escribió:
>> I've got an Internet-Draft that describes the best way that we (the
>> sipX PBX project) have found to implement music-on-hold.  I'd like
>> feedback from the implementor community.
> 
> Hi, it seems really interesting. Just a question:
> 
> Why so strange parameter name in Contact?:
>   +sip.rendering="no"
> Is it usual a parameter name begining with "+" and containing a dot "." in 
> other parameters?

You obviously haven't yet found callerprefs. Check out RFCs 3840 and 
3841. (I predict that you will hate them. Everybody does, including the 
authors.)

> Also, isn't there a better way to indicate that the UA is putting the call on 
> hold? I mean in SIP headers, of course, since there is not SDP.

There is a philosophy of describing behavior rather than named features.
"Hold" is a feature which can be implemented with many different 
behaviors. The basic approach to hold uses a=sendonly/recvonly/inactive 
to adjust how media flows, but the use for hold is not unique.

I didn't remember this parameter. :-(
It is technically a "callee-capability". IMO using it for rendering is a 
bit of an abuse, since it is trying to describe what it is doing rather 
than what it is capable of doing. Even so, it doesn't mean "hold". I'm 
not certain that it really provides any value in this case.

> Is the Contact header the best place to indicate it? (maybe yes, I just ask).

I doubt you want to know all the history. But it starts with 3840/3841.

        Paul

> Best regards.
> 
> 
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to