[EMAIL PROTECTED] wrote:
> From: <[EMAIL PROTECTED]>
>
> I want to connect to a useragent i.e, put him on hold from my
> application. The useragent is not on any call initially .For this iam
> creating an invite request and sending it to the useragent as below:
>
> Not to take away from anything Paul K. said, but my opinion is that if
> the UAS phone is generating directionality attributes
> (a=sendrecv/etc.), it should treat c=0.0.0.0 in incoming SDP as
> a=sendonly (unless there was other information), and so it should
> respond a=recvonly or a=inactive only. Or, if it is unwilling to
> start a call in that state, it should reject the INVITE.
I am inclined to disagree here. C=0 is not an alias for a=inactive.
The c=0 and the a=sendonly/inactive are two different expressions of
desire to have less that a full duplex communication session. They are
independent mechanisms, so there is no reason to couple them.
The use of c=0 could arise for at least two reasons:
- a really old UA that doesn't implement the a= mechanisms for hold
- a UA that for some reason doesn't want to, or is unable to
establish a media path at all, but still wants to negotiate the
parameters of one.
In neither case with responding with a=inactive do anything useful. But
it could do something unuseful, because it is expressing a state that
the sender doesn't mean or desire.
If a UAS receives an offer with c=0 and no a= directionality attribute,
IMO the best thing it could do is take the parameters of the m-line at
face value, and respond to them with an answer that includes a valid c=
address, and a=sendrecv (which can be omitted because it is default). So
then it will be able to receive media, but of course can't actually send
any as long as the c=0 address is in effect.
> However, it is inadvisable for a UAS to reject an INVITE because the
> dialog it establishes is paradoxical or useless -- the UAC may be
> planning on sending a re-INVITE very soon, soon enough to provide
> value to the users. Under some circumstances, SIP requires
> establishing short-term intermediate states in order to accomplish
> call manipulations.
I agree. Certainly if the UAS is normally attended by a human it is
probably advisable to leave it to the human to decide what to do if
there continues to be no media. There may be more argument for automata
to be picky, depending on their function.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
