Correct me if I'm wrong, but even if the remote endpoint understands Q.850 headers, receiving one in anything but a BYE would not cause the device to react any differently, unless the device was specifically programmed to do so, correct?
And in addition to this, if early media is being setup with an SDP body in a message, I would think an endpoint would react based upon the media stream negotiated instead of a Q.850 header, even if it was programmed to handle these, as the presence of media should be regarded as the authoritative source of user presentation rather than the metadata included within the headers. Joel Gerber Network Operations Specialist - Telephone Telephone Eastlink [email protected] T: 519.786.1241 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat Sent: May-28-15 10:29 AM To: [email protected] Subject: Re: [Sip-implementors] Q.850 includes in Proviosional response You don't say what happens *after* they send this 183. That doesn't terminate the dialog - there still must be some final response. Does the final response accurately reflect the distinction between busy, invalid, etc.? AFAICT this doesn't violate anything, so it is *technically* valid. But, if the final response isn't clear, this usage is not well conceived for interoperability. Recipients are explicitly allowed to ignore reason values they don't understand. So recipients that don't understand Q.850 responses will treat this as just a 183 and won't understand the true status of the call. If this approach is used to signal *ringing*, and there is no in-band alerting, then this is likely to result in the caller experiencing a long period of silence. Again that is not a good situation. Basically this seems to be a quality of implementation issue rather than a formal violation of standards. Thanks, Paul On 5/27/15 9:13 PM, NK wrote: > Dear All, > > I have a scenario where our vendor includes Q.850 in proviosnal > response > (183 w/sDP) in every call scenerio, doesnt matter whether number is > invalid, busy, unlocatted. > > In other words if they want to give us busy they will send 183 w/SDP > and in that they will add "reason header" and will specify that > "user-busy". like as below (there was no annoncement). > > *IP/2.0 183 Session Progress* > Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK07Baab30f0ac4907e59 > Record-Route: <sip:2.2.2.2:9131;transport=udp;lr> > Call-ID: [email protected] > From: <sip:[email protected]:5060;cpc=ordinary>;tag=gK072fb580 > To: <sip:[email protected]:5060>;tag=sbc040328yrzaa3-CC-1021 > CSeq: 17205 INVITE > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,UPDATE > Contact: <sip:2.2.2.2:9131> > P-Early-Media: sendrecv > *Reason: Q.850;cause=17;text="User busy"* > Content-Length: 0 > > Can you please advise if this is the correct behavior. Is there any > draft or document is there which i can go through it? > > Regards, > Nitin Kapoor > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
