[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sip] Question about Q-SIP



Dear all,

I have a couple of questions regarding the internet draft: "SIP extensions
for QoS support" (draft-veltri-sip-qsip-01.txt) and I was wondering if
somebody in the mailing list could answer them.

Question 1:
I am trying to understand the requirements for a UA to implement the Q-SIP
"QoS assured" mode of operation. I know that the draft explicitly says that
no enhancements/modifications are  needed in the SIP UA applications to
implement these mechanisms. But it also mentions (Appendix A) that, a UA
must be "preconfigured" to rely on the Q-SIP proxy for QoS handling. I would
like to understand what that "pre-configuration" means in terms of the UA's
SIP behaviour. 

Is there any difference in the way that an UA interprets the precondition
parameters for the Q-SIP QoS-assured mode and the mechanisms described in
RFC 3312 ?

In the Q-SIP example A.1.1, the UA seems to interpret the curr:qos e2e
sendrecv in the 183 message (SDP 4) as the result of the reservation for its
own side of the network (UA(A)) (because it is assuming that the Q-SIP
server reserved it on its behalf) and it responds with an UPDATE to confirm
to the other end that the reservation in UA(A)'s send direction was
successful (confirmation was requested by the UA(B) in SDP 2, 3 and 4 :
conf:recv).

But according to RFC 3312, any curr: header in a message recevied should be
interpreted as the current QoS reserved by the other end of the network. It
seems to me that the two interpretations of SDP preconditions at the UA are
different. 

I would appreciate if somebody could comment on this, maybe I am wrong, the
two interpretations are exactly the same and I just can't see it.

Question 2.

My second question is much shorter: Is the QoS-Info header needed in the
scenario described in A.1.1 ? 
It seems to me that the information carried in the SDP is enough to convey
the QoS mechanisms required when using preconditions and unidirectional QoS
reservation (using RSVP end-to-end for example) for e2e bidirectional
reservation.

Thank you very much in advance
Regards
Maria 


Maria Cuevas                                                       
BTexact Technologies i a trademark of British Telecommunications plc 
Registered office: 81 Newgate Street London EC1A 7AJ Registered in England
no. 1800000 
This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.
Activity and use of the British Telecommunications plc E-mail system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes. 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip