Hi, I arrive late to this topic. In fact I couldn't spent enough time
reading the existing thread and tracker entry due to my current
temporary and poor Internet connection :)

Well, I would just like to add that UPDATE for SS can be used just if
the following occurs:

- For the caller: The initial INVITE request must contain "Allow: UPDATE".

- For the called: A provisional or 2XX response must contain "Allow:
UPDATE". But a non reliable response (1XX without 100rel) could omit
such "Allow" value and still be present in the final 2XX.

In the other hand I've checked that UPDATE can also be used after
dialog is established.

Also, I've asked in sip-implementors about how correct would be
sending an UPDATE with no SDP after dialog is established and
fortunatelly it seems it is valid. In fact, it's the recommended
approach for SS:
 https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-June/025199.html

RFC 4028 section 7.4:

   A re-INVITE generated to refresh the session is a normal re-INVITE,
   and an UPDATE generated to refresh a session is a normal UPDATE.  If
   a UAC knows that its peer supports the UPDATE method, it is
   RECOMMENDED that UPDATE be used instead of a re-INVITE.  A UA can
   make this determination if it has seen an Allow header field from its
   peer with the value 'UPDATE', or through a mid-dialog OPTIONS
   request.  It is RECOMMENDED that the UPDATE request not contain an
   offer [4], but a re-INVITE SHOULD contain one, even if the details of
   the session have not changed.  In that case, the offer MUST indicate
   that it has not changed.  In the case of SDP, this is accomplished by
   including the same value for the origin field as did previous SDP
   messages to its peer.  The same is true for an answer exchanged as a
   result of a session refresh request; if it has not changed, that MUST


I will go deep into this subject in the next weeks. Best regards.


-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev

Reply via email to