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
