Your last point is something I overlooked mentioning. Yes, even with media negotiated, if it's not sent then intent should be derived from something else (previous 180 Ringing for example).
Joel Gerber Network Operations Specialist - Telephone Telephone Eastlink joel.ger...@corp.eastlink.ca T: 519.786.1241 -----Original Message----- From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] Sent: May-28-15 11:42 AM To: Joel Gerber Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Q.850 includes in Proviosional response On 5/28/15 10:33 AM, Joel Gerber wrote: > 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? Yes. that is my point. > 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. It is a poor implementation that thinks the negotiation of the media stream in SDP means it can count of early media substituting for local ringback. It should only make that determination based on the actual receipt of media. Thanks, Paul > Joel Gerber > Network Operations Specialist - Telephone Telephone Eastlink > joel.ger...@corp.eastlink.ca T: 519.786.1241 > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Paul Kyzivat > Sent: May-28-15 10:29 AM > To: sip-implementors@lists.cs.columbia.edu > 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: 285680242_96347916@1.1.1.1 >> From: <sip:7038805449@1.1.1.1:5060;cpc=ordinary>;tag=gK072fb580 >> To: <sip:1234568745@2.2.2.2: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 >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
