Hi all,
Had doubts regarding the refresh methodology of a
session as described in the session-timer draft:
draft-ietf-sip-session-timer-08.txt. Request someone
to clarify and/or give pointers to prior discussions.
The draft states the text:
"A re-INVITE generated to refresh the session is a normal
re-INVITE. It SHOULD contain SDP that describes the
session, even if that SDP has not changed. In that case,
the session description MUST somehow indicate that it
has not changed. In the case of SDP, this is accomplished
by including the same value for the origin field as
previous messages to its peer."
My doubts are:
1. How does this work with QoS negotiation?
If the COMET went out with a line indicating succesful
QoS negotiation, should the INVITE for the refresh
contain:
(a) This last sent SDP of the COMET or
(b) Should it contain the original INVITE's SDP
with all the preconditions that were sent
in the original INVITE?
Approach 'b' looks correct to me because if the UAS
had crashed and is come up again, it allows a call
with same QoS as before to be set up again. The
disadvantage seems to be that a separate COMET indicating
that resources are still available needs to be sent
for every refresh request. Comments?
2. How does this work with UAS not accepting some streams
of the answer?
This is more of a query on the popular practices...
What SDP do implementations send in the refresh if the UAS
had rejected one or more of the streams offered in the
original INVITE? Let me elaborate with an example:
If the original INVITE's SDP is:
v=0
o=user1 23456 56789 IN IP4 139.95.209.190
......
m=audio 3456 RTP/AVP 0
a=sendrecv
m=audio 6789 RTP/AVP 4
and SDP recd in 200 OK for the original INVITE is:
v=0
o=user2 56809 54329 IN IP4 139.95.209.191
.......
m=audio 6666 RTP/AVP 0
a=sendrecv
m=audio 0 RTP/AVP 4
(a) Should the re-INVITE for refresh contain the same version
as before and the second 'm' line's port number as zero
or
(b) Should it give the same SDP as before and allow stream
with codec '4' to get rejected again?
The second approach (not giving port number as zero) looks
correct to me as this allows correct re-establishment of
the session in case the UAS had crashed and come up (or the
call reached a backup UA, either ways). Comments?
Thanks for your time.
Regards,
Siddharth.
-----------------------
Siddharth Toshniwal @ Hughes Software Systems
http://www.hssworld.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
